Building a Better Way to Work With PDFs

We wanted a set of PDF tools we’d actually reach for — fast enough to use for a two-minute task, and built so that using one tool doesn’t mean abandoning the page to go find the next one.

That shaped two decisions early. First, the product would cover a defined, common set of operations rather than trying to be a full document authoring suite. Second, it would treat privacy as part of the product decision, not a policy page bolted on afterward — visible in how directly the product describes itself: “Edit PDFs Faster. Completely Local.”

The toolkit that came out of that: Merge, Edit, Split, Compress, Rotate, Delete Pages, Extract Pages, Extract Text (OCR), Watermark, Organize, Crop, Page Numbers, and View. Thirteen tools, each scoped narrowly enough to be simple, sitting inside one interface so they don’t have to be.

Looked at individually, the thirteen tools are simple enough to explain in one line each. Looked at together, they cluster into a smaller number of real document problems — which is a more useful way to understand why they’re built the way they are.

Merge, Split, Delete Pages, Extract Pages, Organize, and Rotate all operate on the same underlying idea: a PDF is a sequence of pages, and most real editing work is rearranging that sequence rather than changing what’s on any single page. Merge combines separate documents into one ordered file. Split does the reverse, breaking one document into several. Delete Pages and Extract Pages both work by selection — removing pages you don’t want, or pulling out the ones you do. Rotate corrects orientation page by page.

Organize is where this idea is most explicit. The product describes it as letting you reorder, rotate, duplicate, delete, and insert pages — essentially the full set of structural operations in one place, rather than requiring a separate tool for each. It’s the clearest example in the toolkit of treating a PDF as a structured, editable object instead of a flat file you either keep or replace. The product doesn’t currently describe a way to chain these page-structure operations into one automated sequence — each tool is used on its own — but having them share the same interface and page model means moving from one to the next doesn’t mean starting over on a different site.

Compress and Extract Text solve two different but equally practical problems. A finished PDF is often too large to email or upload somewhere with a size limit — Compress addresses that directly, reducing file size while, per the product’s own description, keeping quality intact. The product doesn’t publish specific compression ratios or size limits, and none should be assumed.

Extract Text (OCR) solves a different problem: a PDF that’s readable to a person isn’t automatically usable as data. A scanned contract or an image-based form has no text a computer can search or copy — OCR is what turns that into text you can actually reuse. The tool’s own page is specific about how it works: scanned pages are processed with OCR directly in the browser, with nothing uploaded for that particular operation. The product doesn’t claim perfect recognition, handwriting support, or a specific list of supported languages, so none of that should be assumed either.

Privacy isn’t mentioned once and left behind — it’s stated on the homepage, repeated on individual tool pages, and built into the product’s badge line: “100% local · private by design.” The stated model is direct: no uploads to the cloud, no accounts, and files that stay on the user’s device.

Individual tool pages reinforce this in tool-specific language. Edit PDF’s page states the file “never leaves your device.” Organize’s page repeats the same line. The Extract Text (OCR) tool goes further with a specific technical detail: scanned pages are processed with OCR directly in the browser, and nothing is uploaded for that operation.

Worth being precise about, in the interest of accuracy: the same website also describes a backend processing model elsewhere, under its “Built for speed and privacy” section — stating that PDF tools run through a backend API, with a unified NestJS backend and server-side pdf-lib pipelines handling operations like merge, split, and edit, and large files moving through streamed uploads to that API. That’s a different architecture than “never leaves your device,” at least for those specific operations, and the two descriptions sit on the same site without being reconciled in the public copy.

We’re stating both here rather than picking whichever one reads better, because that’s what the source material actually shows. What’s consistent across every section of the site is the absence of an account system and the absence of any described persistent cloud storage or document library — regardless of exactly where processing happens for a given tool, nothing on the product suggests files are being retained, indexed, or stored beyond completing the requested operation. Claims beyond that — encryption specifics, automatic deletion guarantees, or compliance certifications — aren’t stated anywhere on the site and shouldn’t be assumed.

The interface itself is minimal almost to the point of being unremarkable — which is closer to the goal than a more elaborate design would have been. A PDF tool that requires its own onboarding has already failed at the one thing it’s supposed to do: get out of the way of a task the person already understands.

The homepage puts the file drop zone directly under the value proposition, not behind a second click. Each tool has its own dedicated page rather than being buried in a settings panel inside one monolithic editor — so a link to “Compress PDF” goes straight to compression, with nothing else competing for attention on the same screen. The tone across every tool page is nearly identical: a short description of what the tool does, and a file drop target. That consistency is itself a design decision — once someone has used one tool, the shape of every other tool is already familiar.

These are directions worth naming, not commitments — nothing here exists in the product today. A toolkit built around page-level and document-level operations is a reasonable foundation for deeper document understanding down the line — richer text and form handling, more advanced editing controls, or tighter integration between tools so that a multi-step task like merge-then-compress could run as one action instead of two. None of that is built yet, and this isn’t a roadmap — just a plausible direction given the shape of what exists now.