Why PDF tools can now run in the browser instead of on a server

For most of the web's history, "convert a PDF online" necessarily meant uploading. The browser could not parse the format, so a server had to. That constraint is gone, and it is worth understanding why, because it changes what you should expect from a document tool.

What changed technically

Three developments did the work.

WebAssembly gave browsers a compilation target for existing C and C++ libraries running at close to native speed. The mature PDF and OCR codebases — decades of work in rendering, font handling and character recognition — could be compiled and shipped to a browser instead of rewritten.

Web Workers let that computation run off the main thread. Without them, rendering a 200-page document would freeze the interface; with them the page stays responsive while a worker grinds through pages.

Modern file APIs made it practical to read multi-hundred-megabyte files from disk into typed arrays without the copy-everything-into-a-string overhead that earlier approaches involved.

Together these mean that operations that used to require a server — parsing the cross-reference table, rasterising a page, re-encoding an embedded image, recognising characters — now execute acceptably on a mid-range laptop, and often on a phone.

What this changes about privacy

The interesting property is not a promise; it is the absence of a transfer. If a document is opened, transformed and saved without a network request carrying its contents, then a whole category of questions stops applying: what the retention period is, who has administrative access to the processing server, which jurisdiction the temporary file sat in, whether the deletion job actually ran.

That is the architecture every tool on this site uses. Your file is read with the browser's File API, transformed in memory by a library running in the page, and handed back as a download.

To be precise about the boundaries, because vague privacy claims are worth less than specific ones:

• Your document's contents are not sent to us. There is no upload endpoint and no server-side processing step.
• Loading the page itself is an ordinary web request, so our host sees standard request data — IP address, user agent, the URL requested.
• The site loads third-party resources: web fonts, analytics, and advertising code. Those see page views, not file contents.
• OCR downloads an open-source language model on first use. That request tells the CDN which language file you asked for. It does not carry your document.

The privacy policy states this in full, including what is and is not collected.

Where client-side processing is genuinely limited

Being honest about this is more useful than pretending otherwise.

Memory. Everything happens in your device's RAM, and a browser tab has a ceiling. A 500 MB scanned archive can exhaust it where a server with 32 GB would not blink. The practical workaround is to process in batches.

Throughput. OCR runs at roughly a few seconds per page. That is fine for a twenty-page contract and painful for a two-thousand-page archive, where a dedicated pipeline is the right tool.

Fidelity of office conversion. High-quality Word or Excel to PDF rendering, matching Microsoft's pagination exactly, requires a full layout engine — realistically LibreOffice or Word itself. Browser conversion reconstructs content and basic styling faithfully but will not reproduce every layout decision. Our conversion guides go into what survives.

Certificate-based signatures. Stamping a drawn signature onto a page is a visual act. A cryptographically verifiable signature requires a certificate and a trust chain, which is a different problem with different tooling.

Deep redaction with audit trails. Removing underlying objects and producing a defensible record of what was removed is a specialist requirement; see redaction versus covering.

How to choose

For everyday work — merging, splitting, rotating, compressing, converting images, extracting pages, moderate OCR — the browser is now simply the better default: no upload wait, no queue, no copy of your file elsewhere.

For industrial volume, exact office-layout fidelity, or legally weighty redaction and signing, use a desktop or server tool. Preferring a local desktop application to a cloud upload keeps the same privacy property.