Why browser-local processing matters for everyday tools

To merge two PDFs on most free tools, you upload two PDFs. They travel to a server you know nothing about, are written to a disk somewhere, are processed, and the result comes back. Then, according to a line in a policy you did not read, they are deleted after some number of hours.

For a holiday itinerary that is fine. For a tenancy agreement, a payslip, a medical letter or a signed contract — which is a fair description of what people actually merge and split — you have just handed a complete copy to a stranger to solve a problem that never required them to see it.

The upload is a historical accident

Server-side processing was not a privacy decision. It was the only option. Doing this work in a browser used to be impossible: no real file access, no memory to speak of, no libraries, and JavaScript that was too slow for the job.

All four of those changed, at different times, without any single moment where it became obvious. The browser now has the file APIs, the memory model, mature libraries and, through WebAssembly, performance good enough for exactly this class of work. The architecture that survived is the one from before, kept alive by inertia and by the fact that it is genuinely easier to operate.

In ITISYOU Tools, the PDF and image tools do their work on your device. Merge, split, reorder, extract and remove pages; compress and resize images. The file is not uploaded, which means there is no copy on a server, no retention window to define, no deletion job to get wrong, and no breach involving your document because there is no document of yours to breach.

What this actually removes

The privacy argument gets made a lot and usually vaguely. The concrete version is that a whole category of problems stops existing rather than being managed:

• No retention question. “How long do you keep files?” has no answer because nothing arrives.
• No deletion promise to keep. Deletion promises depend on a scheduled job continuing to work correctly, silently, forever. This is a well-known category of thing that quietly fails.
• No transfer to reason about. No question about where a server sits or whose jurisdiction the file passed through.
• No insider access. Not because the people are untrustworthy, but because access that does not exist cannot be misused or compelled.

The pattern is the one I keep coming back to across this network: a design where the risky thing is impossible beats a policy where the risky thing is prohibited. Policies depend on everyone continuing to behave correctly. Architecture does not ask.

It is worth being careful about the boundary, though. This is a claim about the tools that state it, not a blanket claim about every page on the site. Over-generalising exactly this kind of good design is a mistake I have already made once.

What it costs

Three real costs, none of them trivial.

The device does the work. A large PDF on an older phone is slower than it would be on a server, and can fail outright if memory runs short. Server processing has a floor of capability that client processing does not — the server is always the same server, whereas your users’ devices vary by more than an order of magnitude. I have not measured those limits carefully enough to publish numbers, which is why there are none here.

The code has to arrive first. A PDF library shipped to the browser is a real download before the first click, and it competes directly with the goal of a fast page. This pushes you towards loading it only when a tool is actually used, which is more engineering than calling an API.

You lose the telemetry. Server-side, you would know which operations fail and on what. Client-side, a failure on someone’s phone is invisible unless they tell you. That is the correct trade, and it does make the product harder to improve. I would rather be slightly blind than hold everyone’s documents.

Where it genuinely does not fit

Local-first is not a universal answer, and pretending otherwise would be the same overreach in the other direction. It does not work when the operation needs something the device does not have: a model too large to ship, a dataset that cannot be distributed, or coordination between people. It does not work when the result must be authoritative rather than convenient. And it does not work when a file genuinely has to be stored, because then you are back to retention, deletion, transfer and access, and the honest move is to design those properly rather than to claim a privacy property you no longer have.

ATSYou is the clear example in this network. A CV is processed, structured and stored so it can be confirmed and reused — that is the product. There is no local-first version of it, which is precisely why it needed the data protection work rather than a clever architecture.

The rule I have settled on is narrow enough to be useful: if the job can be done on the device, do it there, and say so specifically. If it cannot, say that plainly too, and do the harder work of handling the data properly. What I try to avoid is the middle position — uploading because it is easier, and describing it as secure because the connection is encrypted.