How browsers got good enough to edit a PDF without a server

Why the server was there in the first place

Around 2008, a web page could not open a file off your disk. There was one way to get bytes from your machine into a program: a form with a file input, pointed at a server. So every tool that did anything to a document was a server tool, not because that was the right architecture but because it was the only one available.

That constraint outlived itself. The upload-process-download shape got baked into how these sites are built, how they are funded and how people expect them to work, and it stayed long after the browser stopped needing it. Most PDF converters online today are still that 2008 diagram with a nicer font.

The four pieces that changed it

Editing a PDF locally needs four separate things, and they landed years apart.

Reading the file. The File API gave pages a way to read a file the user picked, without sending it anywhere. Drag a PDF onto the page, and JavaScript gets the actual bytes. This is the piece people are most surprised by, because the mental model of “the page” as something remote is hard to shake, but the file input has been able to hand its contents straight to local code for well over a decade.

Holding it efficiently. Typed arrays arrived alongside WebGL, which needed to push vertex data to a graphics card without the overhead of ordinary JavaScript arrays. A side effect was that the language finally had a real byte buffer. A PDF is a byte format, so this is the difference between parsing one and merely thinking about it.

Drawing it. Canvas gave pages a surface to rasterise onto, and eventually a way to export that surface as a PNG or JPEG. Every “PDF to image” conversion is that: parse the page description, execute the drawing operations onto a canvas, read the pixels back.

Handing it back. Blobs plus object URLs plus the download attribute on a link. The browser can build a file in memory and save it to your downloads folder with no round trip. Small, unglamorous, and the reason the output does not have to come from a URL on somebody's server.

The stubborn part

Those four give you the plumbing. They do not give you a PDF parser, and a PDF parser is a serious piece of work: cross-reference tables, object streams, a dozen compression filters, embedded font programs in several formats, an operator language for the page content, and thirty years of files that do not quite follow the specification.

Mozilla started pdf.js as an experiment in 2011, partly a demo of what the platform could do, partly a way to stop shipping a plugin. It became Firefox's built-in PDF viewer in early 2013. That means the parser most of this depends on has been running in production, on the whole web's supply of malformed PDFs, for more than a decade.

🧩This is the load-bearing detail. Every browser-based PDF tool leans on the same handful of libraries, and the reason they can be trusted with real documents is boring: they have been hit by an enormous number of strange files already.

Reading versus rewriting

Viewing a PDF and changing one are different problems. Rendering means turning the document into pixels; rewriting means producing a new, valid PDF that other software will open. Different libraries, different failure modes.

The important thing about rewriting is what you should refuse to do. Merging two documents is not a matter of drawing both and re-exporting. It copies the page objects across and fixes up the references, so the text stays text and the file stays roughly the same size. Rotating a page changes one number in the page dictionary. Rotate PDF does exactly that and nothing more, because the alternative is turning a searchable page into a photograph of itself.

• Merge, split, delete and reorder: page objects are copied, nothing is re-encoded.
• Rotate: a single value on the page is set. Byte-identical content underneath.
• PDF to image: this one genuinely rasterises, because the output is an image.
• Image to PDF: JPEG and PNG go in as-is; other formats get re-encoded once on the way in.

The part that is still awkward

None of this makes the browser a perfect place to work. JavaScript on a page runs on the same thread that draws the interface, so a long rendering loop over a 300-page document will freeze the tab while it works. Web Workers solve that by moving the job to a background thread, and WebAssembly, cross-browser since 2017, makes it possible to run C libraries at close to native speed. Both are available. Neither is free to adopt: moving image work into a worker means moving the canvas too, and browser support for that took years to line up.

So the honest current state is that a browser tool can be as correct as a server tool and, for anything under a few dozen pages, about as fast, while being slower and hungrier on very large files. That is the actual trade, and it is a good one when the alternative is mailing your documents to a stranger.

And the part that is not close

Converting a Word document to PDF with the layout intact effectively means running LibreOffice. It is a large native application, and no, it is not going in a tab. Some aggressive compression relies on tools nobody has ported. Good OCR is heavy in a different way, and it was on this list until October 2026, when it moved into the browser here as OCR PDF: a few megabytes of engine and language data, downloaded once, and the scan never leaves your device.

Those need a server, and there is nothing wrong with a site that has one for them. The waste is running a server for merging and splitting, which your laptop has been able to do since roughly 2013.

What this looks like here

Every tool on this site is those pieces assembled: read the file locally, parse it, rebuild it, hand it back. There is no upload endpoint to point at, which is why how it works can describe the whole data path in a paragraph, and why the security page is unusually short.

If you want to check rather than take our word for it: load a tool, turn off your wi-fi, and use it. It still works. That is not a clever demo, it is just what happens when the server was never part of the job.