Building tools for a while gives you a habit: every "process a file" request, first ask whether it actually needs an upload. A lot of processing that defaults to a server runs fine in the browser, and when it's just you, that difference decides whether you keep a backend alive and whether you carry the privacy liability of users' files.
Why this matters extra for solo devs: once a file is uploaded, you own it — how long it's stored, who can read it, whether it's really deleted, and the liability if something leaks. And the files users least want to upload — contracts, IDs, unreleased material, private screenshots — are exactly the common inputs to "document processing". What can be done locally shouldn't leave the device; you save not just the server bill but a whole pile of trouble you didn't have to carry.
Over time I've moved these into the browser, all running locally with files never leaving:
OCR — recognition, layout reconstruction, export to TXT / Markdown / coordinate JSON, all local; PDF compression — per-image re-encoding plus structural optimisation, with a read-back check after; PDF to HTML — rebuilt by coordinates into a single file with selectable text; PDF image extraction — pulling the real images out of page resources instead of screenshotting whole pages; DOCX and PPTX to HTML — Office documents into inlined single files. What they share: the processing logic itself doesn't need server compute, it's pure parsing and re-encoding, and the browser's WASM and Canvas handle it fine.
I verify each of these myself in ten seconds, crude but effective: open the Network panel, process an image, check there's no request POSTing the image out, and that the preview URL starts with blob:. A model-download request is normal — that's pulling the model local; as long as there's no upload of the image, the processing really is on-device. Worth doing especially as a solo dev — if you're copying someone's on-device approach, confirm it's actually on-device, don't take the word "local" on faith.
The counter: not every "document task" suits local. Anything that aggregates across files, needs server-only fonts or compute, or has multiple people collaborating on the same data — can't or shouldn't be local, keep it on the server. And some formats are just heavy: certain conversions need a dedicated engine the browser can't reliably match, and forcing them local only spawns edge-case bugs.
So my one test: is this processing a self-contained "parse + re-encode" job? If yes, prefer local — save the server, skip the upload, and solve privacy as a side effect. If no, leave it server-side. The tasks above moved because they all sit on the self-contained side. ImgIng packages them as a set that all run locally; I've used it as a ready-made checklist for what can be pushed on-device.
Top comments (0)