It would have been genuinely easier, in some ways, to build this site with a normal backend. A server-side Node or Python application processing PDFs with mature, battle-tested libraries would have sidestepped a whole category of browser-compatibility puzzles, made certain heavier operations faster on underpowered devices, and avoided the WebAssembly compilation work that a tool like Protect PDF required. The decision to build minipdftoosz with no backend at all — no server-side application, no database, no login system — was made anyway, deliberately, because the trade-off runs the other way for a tool site whose core promise is about what happens to your files.
The most direct benefit of having no backend is the simplest one to state and the hardest one to fake: there is no server anywhere in this project's production deployment that could receive, log, cache, or accidentally retain a copy of a file you process. This is not a policy decision that a future team could quietly change, or a retention setting that defaults to something unfavorable and requires you to opt out — it is architecturally impossible for a file to end up on a server this project runs, because that server does not exist. A privacy promise enforced by the absence of the thing that would violate it is a stronger promise than a privacy promise enforced by a policy document.
The second, less obvious benefit is what having no login and no accounts removes from the experience entirely: there is no password to forget, no email address to hand over, no account-recovery flow, and nothing tying your usage of any tool to an identity at all. For a genuinely large share of PDF tasks — a one-off merge before an email, compressing a single scanned form, signing a document once — the entire concept of "creating an account" for the task is disproportionate to the task itself, and every account you create somewhere is one more password to manage and one more entity that now has a record that you exist and use PDF tools.
The trade-offs are real and worth stating plainly rather than glossing over. A backend server can throw more raw compute at a heavy operation than a browser tab running on someone's phone can. It is why very large or very complex PDF processing jobs are sometimes genuinely faster on a server-side tool, and why minipdftoosz is upfront on tool pages where client-side processing has a real ceiling — extremely large scanned-image compression being one honest example. A backend can also persist state between sessions, offer collaborative multi-user workflows, or run scheduled batch jobs — none of which a static, no-backend site is architecturally capable of, and none of which this project claims to offer.
The bet underlying this whole design is that, for the specific category of task this site targets — individual people doing individual, one-off PDF operations — the privacy and simplicity gained by having no server at all outweighs the raw performance ceiling and feature surface a backend would have unlocked. It also means every tool that does ship has to actually be implementable in a browser, which is a genuine constraint that shaped which 31 tools ended up on this site and, occasionally, which stated limitations appear plainly on a tool's own page rather than being hidden. That constraint is treated here as a feature of the promise, not an inconvenience to work around quietly.