The original choice
When we scoped this project, the default pattern for an online tools site was obvious: upload the file to a server, process it there, stream the result back. That is what every successful competitor does. It is faster for large files, it can use server-only libraries, and it scales linearly with cheap cloud compute.
It also means every user has to trust you with their files. And that is the part we could not get comfortable with. Tax forms, contracts, ID scans, internal product shots, leaked screenshots — the long tail of what people actually process is more private than anyone admits.
What changed when the browser caught up
Five years ago, "run a PDF editor in the browser" would have meant a 2 MB JavaScript bundle and a user experience nobody would tolerate. Today, three things make the client-side path practical:
- WebAssembly. Tesseract.js (OCR), pdfjs-dist (PDF rendering), and modern image codecs all ship as WASM. They are essentially desktop-speed for most file sizes.
- Route-level code splitting. Next.js lazy-loads each tool's library only when that route is hit, so the shared bundle stays under 90 KB.
- Worker APIs. Canvas off the main thread, OffscreenCanvas, SharedArrayBuffer. The browser is finally a serious runtime for image and PDF work.
What we gave up
There are real trade-offs. We are honest about them on every comparison page:
- Maximum file size is limited by browser memory. 100 MB PDFs work; 5 GB videos do not.
- Some compression techniques that cloud providers use (especially server-side Ghostscript for PDF) are not available client-side. Smallpdf and iLovePDF will often shrink an image-heavy PDF more aggressively than we can.
- No desktop-only libraries. ImageMagick, Ghostscript, ffmpeg — all server-side. For features that genuinely require them (video transcoding, advanced OCR), we either ship a Wasm port or skip the feature.
- First load of heavy tools (OCR, text compare) downloads a one-off asset (~10 MB for Tesseract). After that, everything is cached.
What we kept
The things that matter for the long tail of "private documents I would rather not upload":
- Zero file retention. There is no server to retain files on.
- Works offline after first load. Useful on planes, in sensitive environments, on corporate networks that block external services.
- Verifiable. Open DevTools, watch the Network tab, drop a file — you will see zero outbound requests.
- No account. No email required. Close the tab and the session is gone.
Who this is for
Most users most of the time do not care whether their PDF went to a server. They care whether the tool works. The privacy story is not a marketing angle; it is the reason the small percentage of users who do care show up in the first place — and stay.
If you are a student converting a thesis, a lawyer redacting a contract, a designer resizing client assets, or anyone whose files are not yours to upload: we built this for you.
The best privacy feature is the one you can verify in five seconds with DevTools.— StuHub engineering note