The upload you didn't notice
Here is an audit anyone can replicate in ten minutes. Search "unzip files online." Open the first five results. On each, drag in a test zip and watch the network tab. The pattern repeats: the file leaves — POST after POST, your archive traveling to infrastructure whose owner, jurisdiction, logging policy and retention schedule are collectively answered by a shrug and a cartoon mascot.
What travels in zips
Think about when a person reaches for a web-based opener: they're on a machine without tools — a work laptop under IT lockdown, a borrowed computer, a Chromebook. And what needs opening in those moments is rarely wallpaper: it's the client handover, the payroll export, the legal discovery bundle, the university records dump — files zipped precisely because they're a package of something that matters. The moment of least tooling is the moment of highest stakes, and the top search results monetize exactly that squeeze. Most say "files deleted after N hours." All require believing it. None can prove it, structurally, because their architecture is the thing you're being asked to trust.
Trust the architecture, not the promise
The alternative isn't a better promise — it's an architecture where the promise is unnecessary. A static page that ships its decompressor to your browser has no upload endpoint; the archive is opened by code running on your machine, and "we never see your files" stops being a policy and becomes a property, checkable in the network tab (which stays silent) or by flipping on airplane mode (which changes nothing). This is unzippr's whole argument, and it generalizes: for any tool handling sensitive files, the first audit question isn't "do they seem trustworthy?" but "does their design make trust irrelevant?" A promise can break on one bad quarter or one subpoena. A missing server can't.