Why client-side PDF tools matter
Every major free PDF tool you have used in the past decade — iLovePDF, Smallpdf, PDF24, Adobe's online editor — uses the same architecture: you upload the file, their server processes it, they email or stream the result back. The model dates from when browsers were too weak to handle anything non-trivial. The model is obsolete.
What the architecture actually costs
Three costs travel together with every upload, and they are consistently understated:
- Bandwidth. A 50 MB PDF takes ~8 seconds to upload on a typical home connection and 60+ seconds on a mobile hotspot. The result then has to come back. The actual processing — say a JPEG-recompression pass — would take under two seconds on the user's laptop.
- Retention. "Files are deleted after 2 hours" is the standard line. It is a policy promise, not a technical guarantee. The operator's logs typically retain filenames, sizes, IPs, and processing metadata for far longer. A breach exposes all of it.
- Trust transfer. The operator now has your document. You must trust their employees, their subcontractors, their cloud provider's employees, and every system administrator in the chain. This is fine for a printable coupon and not fine for a will, a contract, or a medical record.
What changed
Web browsers gained three capabilities in the 2020s that closed the gap with server-side processing for almost every PDF task:
- WASM-compiled libraries. pdf-lib, PDF.js, and the HuggingFace transformers runtime now ship browser builds that match native performance to within a small constant factor.
- Web Workers and OffscreenCanvas. Heavy CPU work no longer blocks the UI. Multi-threaded WASM lets browser apps use every core on the device.
- File System Access API and large-blob handling. Browsers can read multi-gigabyte files without crashing and write results directly to disk.
The new default should be: do it on the device that owns the file
The device that owns the file already has the file in memory. It has a CPU. It has a screen. It has the user's full trust, by definition. Asking it to also do the processing is, in 2026, the lower-cost, lower-risk option for almost every PDF operation that does not require a model larger than 1 GB.
The operations that still need a server are narrow: training a custom OCR model, querying a 200-page contract with an LLM that does not fit on a phone, or running an OCR pipeline against scanned documents at volume. Even those are getting smaller every year.
Concrete suggestions
For a tool that handles documents the user considers sensitive:
- Default to in-browser processing for everything that fits.
- Make the network panel a feature. If a user opens DevTools and sees no request body containing their file, they have a stronger privacy guarantee than any retention-policy paragraph can give.
- When server work is genuinely required (large OCR, AI summarisation of large documents), say so and explain the deletion guarantees in technical detail.
Where we put our money
Merge Everything builds InstantFileTools on this thesis. Every PDF, image, document, and creation tool in the suite runs in the browser. The marketing site has no upload endpoint. The model works at zero marginal cost per user, because the user's device does the work. It is the architecture every browser-era document tool should adopt.
If this resonates, try InstantFileTools — the privacy-first tools described in this article, available free in your browser.