Why Client-Side ZIP Viewers are Safer

Two websites offer to open your ZIP file. Both are free. Both look professional. One uploads your archive to a server; the other reads it inside your browser.

From the outside they are indistinguishable. The difference only shows up in what happens to your file — and it is a large difference.

What “client-side” actually means

When you use an upload-based tool, this happens:

1. Your browser reads the file and sends every byte over the network.
2. A server receives it and writes it to disk.
3. The server decompresses it, creating more files on that disk.
4. You get links to download the results.
5. At some point, on a schedule you cannot see or verify, the files are deleted.

When you use a client-side tool, this happens:

1. Your browser reads the file into memory.
2. JavaScript running in that tab decompresses it.
3. The results are displayed.

That is the whole list. There is no step where the file crosses a network, because there is no server involved in the work at all. The website delivered some code to your browser, and your browser did the job.

The capability is not new. Browsers have been able to read local files and decompress data for well over a decade. Almost nobody built the tool this way because uploading is easier to engineer and creates a business with metered tiers to sell.

The privacy difference is categorical, not incremental

The important part is not that a client-side tool has a better privacy policy. It is that there is nothing for a policy to be about.

An upload service can promise it deletes files after an hour. Maybe it does. You cannot verify it, and the promise depends on:

• the operator’s honesty, now and after any change of ownership
• their actual retention behaviour matching their stated one
• their backups, which may retain data long after the “original” is deleted
• their logs, error reports and monitoring, which routinely capture more than intended
• their infrastructure not being breached
• every subprocessor in their stack behaving the same way

None of that applies when the file never leaves your machine. There is no copy to retain, no backup to forget about, no breach that could expose it. The guarantee is structural rather than promised.

You can check this yourself, on any tool. Open your browser’s developer tools, switch to the Network tab, and open an archive. If you see a large upload request, the file left your computer. If you see nothing, it did not.

What you are actually risking

It is easy to be relaxed about this until you look at what ZIP files usually contain. In practice, archives hold exactly the things you would never paste into an unknown website:

• Tax documents and financial records
• Exports of your own data from a service — often including message history and location data
• Client work under confidentiality agreements
• Source code that is not public yet
• Scans of identity documents
• Photos, including of other people who did not agree to any of this

Uploading these to an extraction service is the same act as pasting them into a random website. It just does not feel like it, because the interface frames it as a file operation rather than a disclosure.

The compliance angle people forget

If you handle other people’s personal data — customers, employees, patients, users — sending it to a third party is a transfer to a processor, and it does not stop being one because it was brief or convenient.

Under GDPR and comparable regimes, that transfer carries obligations: a lawful basis, usually a data processing agreement, due diligence on the processor, and possibly a record of processing activities. If the server is in another jurisdiction, cross-border transfer rules may apply too.

Almost nobody doing this at 4pm on a Tuesday, trying to open one file, has considered any of it. The exposure is real regardless.

A client-side viewer removes the question entirely. No transfer occurred, so there is no transfer to justify, document, or explain to anyone later.

The same reasoning applies to NDAs. “I uploaded the confidential archive to a free website to look at it” is not a defence anyone wants to be constructing.

Security: reading versus executing

There is a second dimension, distinct from privacy.

Archives are a long-standing delivery mechanism for malicious content, for a simple reason: compression obscures what is inside, and extraction is a step where things can go wrong.

A viewer that reads an archive without extracting it is doing something fundamentally safer than an extractor. Specifically:

Nothing is written to your filesystem. Files stay in browser memory. Nothing lands in a folder where it might later be double-clicked.

Nothing executes. The viewer decompresses bytes and renders them as an image, as text, or as a hex dump. It does not run them. An executable inside an archive is just an entry in a list.

Path traversal is defused. “Zip Slip” is an attack where an entry is named something like ../../../etc/passwd, so a careless extractor writes it outside the folder you chose. It has affected a long list of real tools. A viewer that never writes to disk cannot be exploited this way at all — and ours goes further and flags those entries, so you learn the archive is hostile. Most desktop extractors show you nothing.

The browser sandbox is doing real work. Page JavaScript cannot read your filesystem, cannot write to it, and cannot execute programs. It is the same boundary that lets you visit unknown websites at all. Handing a ZIP to code running inside that sandbox is meaningfully safer than handing it to a program running with your full user privileges.

This is not a claim that a viewer replaces antivirus. If you extract and run something malicious, a viewer will not save you. The claim is narrower and solid: inspecting an archive should be safe, and in a client-side viewer it is.

The same principle applies to media

Playing a video out of an archive is the clearest illustration of why the architecture matters.

An upload-based tool has to receive the whole archive, unpack it, and serve you the video from its own disk — which means your footage has existed in full on someone else’s machine before you watched a second of it.

Reading the archive locally, none of that happens. Media is stored uncompressed inside a ZIP, so the player reads the bytes it needs directly from the file, whether that file is on your disk or on the origin server. Nothing is extracted, nothing is uploaded, and for a remote archive nothing beyond the part you are actually watching is even transferred.

Speed, as a side effect

Privacy is the headline, but the architecture also just performs better.

There is no upload, so there is no upload wait. A 200MB archive that would spend several minutes crawling up a domestic connection opens in about the time your disk takes to read it.

There is no server cost either, which is why there are no size tiers, no daily quotas, and no premium plan. The work happens on hardware you already own.

Done properly, parsing runs on a background thread, so the page stays responsive even on very large archives — where many browser-based tools freeze the tab because they do the work on the main thread.

Where client-side genuinely loses

Being honest about the trade-offs:

Password-protected archives. Encrypted ZIP entries are not supported by the decompression library we use, so those archives cannot be opened here. A desktop tool will handle them.

Very large archives. The ceiling is your device’s memory rather than a server’s. Hundreds of megabytes are fine on a desktop, multi-gigabyte archives often work, phones have less room. A server with 64GB of RAM has more headroom.

Older browsers. The required APIs are widely supported now, but something genuinely ancient will struggle.

Other formats. RAR, 7z and TAR are different formats and are not supported yet.

None of these are reasons to prefer uploading. They are reasons to keep 7-Zip installed for the rare cases that need it.

How to tell which kind you are using

Before you trust any online archive tool:

1. Watch the Network tab. Open developer tools, load an archive, and look for a large upload. This is the definitive test.
2. Try it offline. Disconnect and load an archive. A genuinely client-side tool still works.
3. Read the wording carefully. “Your files are deleted after one hour” confirms they were uploaded. “Your files never leave your browser” is the claim you want.
4. Watch for size limits. Caps and daily quotas exist because bandwidth and storage cost money — which is to say, because there is a server.

The short version

Client-side viewers are safer because the risky steps are not skipped carefully; they are absent. No upload, so no transfer, no retention, no breach exposure, no compliance question. No extraction to disk, so no path-traversal risk and nothing sitting in a folder waiting to be run.

The convenience is identical. The exposure is not.

Open a ZIP file in your browser — nothing you choose from your device is uploaded. Or read how to open ZIP files online without software and the five most useful things to do with an online ZIP viewer.