Private zip file viewer for confidential archives

When a private zip viewer is the right call

The common pattern is the same every time: someone hands you an archive you are obligated to protect, and you need to inspect it before you do anything else with it.

Concrete situations where a client-side viewer fits:

• Auditing a vendor's delivered zip before deploying it — reading its manifest, configs, or bundled scripts without sending the package to a third-party unzip site.
• Inspecting an .apk or .epub received under NDA — checking the package structure, embedded assets, or metadata before it ever touches a network service.
• An HR or finance team that needs to open an archive of sensitive documents (contracts, payroll, candidate data) and preview individual files without a server round-trip.
• A developer reviewing a client's source drop — reading the code, searching the tree, and opening nested jars or wheels (.jar, .whl, .war) without uploading the codebase.
• Anyone with medical records, legal discovery, or other regulated files who wants to minimize the number of systems that ever see the bytes.

Why server-based viewers are a confidentiality risk

Most "online unzip" tools work the way they look like they work: you upload the file, the server extracts it, and sends the listing back. From a confidentiality standpoint that is a real problem, and it is worth stating plainly what you are trusting the vendor with.

When you upload an archive, the data leaves your device and you lose control over the handling chain. Specifically: the file contents sit on a server you do not own; the vendor's data-handling, retention, and access controls are usually undisclosed; and for a free service there is a reasonable chance the contents are scanned, indexed, or used for model training, because that is how free services tend to be funded.

For an IT or compliance reader, the issue is not just trust in a single vendor — it is the absence of an assurance. You cannot produce a data-flow diagram, you cannot name the processor, and you cannot bound the retention period. "We used a website" is a hard thing to put in a breach postmortem or a DPIA. A client-side viewer sidesteps the question by not creating the data flow in the first place: there is no upload, so there is no third-party processing to assess.

How client-side processing keeps data local

In a private zip file viewer, the entire parse-and-render loop runs inside your browser tab. The archive bytes are read from disk (or fetched once, if you loaded it via URL) and handed to zip.js, which runs as ordinary JavaScript in the page. The file tree, the search, and every preview — code with syntax highlighting, images, audio, video, PDFs, and nested zips — are produced locally from those in-memory bytes.

Nothing about the archive's contents is transmitted over the network. This lines up cleanly with two principles IT and compliance teams already care about. Data minimization: the only place the data exists is the device that already had it. No third-party processing: because there is no server-side step, there is no subprocessor to enumerate, no data processing agreement to chase, and no cross-border transfer to reason about.

Verify the privacy claim yourself

You should not take "client-side" on faith. The claim is checkable in a few seconds against your own browser.

First, open DevTools (the Network tab), then load or drop an archive. You will see the page's own scripts load, and — if you used a URL — a single fetch for the archive itself. You will not see the file's contents posted back anywhere. Second, after the page is loaded, disconnect your network (turn off Wi-Fi or pull the cable). Browsing the tree, searching, and previewing files keep working, because nothing about those operations touches the network. Third, note that the page loads its scripts from the same origin (ziptool.app) over HTTPS; there is no hidden upload endpoint pointed at another domain.

If any of those three checks ever failed, the privacy claim would be false — which is exactly why they are worth running.

Honest caveats: what client-side does and does not protect

Client-side processing is a genuine privacy improvement: your file contents are not uploaded, not stored on a server, and not handed to a third party. It is not a guarantee that nothing bad can happen, and overselling it helps no one.

Things to keep in mind:

• A malicious archive is still malicious. Parsing runs JavaScript in a sandboxed browser tab, which limits the blast radius, but browser or library bugs are theoretically exploitable. Do not treat "opens in a browser" as "safe to open from an untrusted source."
• A browser extension with page access can read the in-page data the same way the viewer can. If you have a screenshot, coupon, or AI-helper extension with broad page-reading permissions, it could in principle see your archive's contents. Disable such extensions before opening truly sensitive files, or use a clean browser profile.
• Do not use a shared or public machine for genuinely sensitive files. A keylogger, a device-management agent, or the next user of the kiosk can defeat any in-browser privacy guarantee.
• Files you later extract and run are your responsibility. The privacy guarantee is about the network and the server — it does not extend to whatever you do with the extracted bytes afterward.

Compliance framing, without overpromising

Data that never leaves the device is simply easier to reason about. If you are working under a GDPR lens, the absence of a transfer to a third party removes a category of risk you would otherwise have to document. If your contract has a "no third-party processing" or "no subcontractor disclosure" clause, a client-side viewer means there is no processing step to violate.

These are practical observations, not legal guarantees. Whether client-side processing satisfies a specific obligation depends on your context — what the files are, what jurisdiction applies, and what your agreements actually say. The honest pitch is narrower: it removes the server from the data flow, so you have one less thing to assess. For a fuller treatment, see the security and privacy overview and the privacy policy.

Frequently asked questions