Why You Should Never Upload Sensitive ZIP Files to Online Tools

Most "unzip online" sites work the same way: you drop a file, it uploads, a server does the work, you download a result. That pipeline is fine for a public photo. It is not fine for anything you would hesitate to email to a stranger.

This post is about what actually goes wrong when you hand a sensitive archive to a random web tool, and how to tell which tools avoid the problem.

The moment you upload, you lose control

An upload is a copy. Your file is now on a machine you do not own, running software you cannot read, operated by a company whose identity is often just a domain name and a contact form.

Even in the best-case scenario — honest operator, correct TLS, well-intentioned code — the file exists on their disk or in their RAM long enough to be processed. During that window it is subject to:

• Their logging. Web servers and application frameworks log filenames, sizes, IPs, and timestamps by default. A developer has to actively turn that off. Most do not.
• Their backups. Disk snapshots, memory dumps during debugging, and crash reports can preserve "deleted" files long after the UI says they are gone.
• Their retention policy. "We delete files after 24 hours" is a promise, not a mechanism. You cannot verify it.
• Their third parties. The server itself often sits behind a CDN, a cloud hosting provider, and an object store — each one is another party with nominal access.

None of this requires malice. It is the default behavior of standard infrastructure.

Password-protected ZIPs get the worst of this

If you upload a password-protected archive and then type the password into the same page, the server now holds both the ciphertext and the key. The encryption protects nothing at that point — it just formalizes that you handed over a decryptable copy.

Worse, many conversion tools strip the encryption as a side effect. You upload contract.zip encrypted, ask it to convert to 7z, and you get back contract.7z unencrypted. The server now has a plaintext copy sitting on disk until their cleanup job runs.

Filenames and directory structure leak plenty on their own

Say you believe a service really does delete the file contents immediately. The metadata trail usually survives:

• 2024_tax_return_jsmith.zip — the filename alone tells an attacker who and what.
• project_northstar_specs.zip — the codename leaks strategy.
• client_acme_nda_draft_v3.zip — the version and party leak negotiation state.
• Internal file paths inside the archive frequently appear in debug logs and reveal your folder structure.

Combine that with the IP address (often your employer's) and the timestamp, and you have a searchable record of who was working on what, when, without needing a single byte of file content.

The server is a target whether the operator is honest or not

A service that accepts file uploads is a high-value target by design. There is a continuous supply of files flowing in, sometimes from users who will not notice a breach for months. Breaches happen. In 2023 an online PDF conversion service disclosed that an attacker had persistent access to their processing servers for weeks and told users to "assume any file uploaded during this period may have been accessed." The service had millions of monthly users.

If the file never leaves your browser, there is nothing on the server to steal.

If your files fall under any compliance regime, this is already a violation

GDPR, HIPAA, SOC 2, and most internal data-handling policies require you to know who is processing personal or confidential data and to have a written agreement with them. Dragging a customer CSV onto an unknown web tool satisfies neither. You cannot name the processor, you have no DPA, and the tool's privacy page — if it exists — almost certainly does not mention you.

This is also true for the things companies do not label "personal data" but absolutely would not want leaked: source code, financial projections, M&A docs, HR records, unreleased marketing assets.

The alternative: run the algorithm in your browser

Archive formats are not proprietary. ZIP, 7z, TAR, and GZ are all well-specified, and browsers can run the same code that servers run. The modern approach is to ship the compression library to the user as WebAssembly so the whole operation happens locally. No upload, no server-side processing, no copy leaving your machine.

MakeMyZip is built this way. Extracting, creating, converting, merging, splitting, encrypting, and inspecting archives all run inside your browser tab. There is no upload endpoint on the site — not hidden, not "only for large files," not any. The tool cannot read your files because it has no infrastructure that would let it.

How to tell whether a tool actually runs locally

Marketing copy is not evidence. Here is how to check for yourself, in order of effort:

1. Watch the Network tab. Open DevTools (F12), go to Network, then drop a small file onto the tool. If you see a POST request whose size matches your file, it uploaded. If you only see the initial page load and maybe a few small XHRs, it did not.
2. Disconnect and retry. Load the page, then kill your Wi-Fi or block the site in DevTools. Try the operation. A genuinely local tool still works. A server-based tool errors out.
3. Read the privacy policy for specifics. Look for concrete claims: "files are not transmitted," "processing happens in your browser via WebAssembly," "we do not retain uploads because there are no uploads." Vague phrasing like "we may temporarily store files to provide the service" means uploads.
4. Check whether the source is public. Open-source tools let you verify the claims. You do not have to audit the code yourself — you just have to know that someone could.

Step 1 alone catches most of the bad actors. A tool that claims "client-side" but fires off a 40 MB POST when you drop a 40 MB file is lying, and the Network tab makes that obvious in under ten seconds.

A simple decision rule

If you would not email the file to an acquaintance, do not upload it to an unknown archive tool. The trust relationship is the same — you are handing a copy to a stranger and hoping they behave — except you usually know less about the website than about the acquaintance.

For anything sensitive, use a desktop tool (7-Zip, Keka, The Unarchiver) or a browser-based tool that provably runs locally. MakeMyZip handles ZIP, 7z, RAR, TAR, and GZ entirely in-browser. Your file never leaves the tab.