How to check if a zip file is safe

"Is this zip safe?" is really two questions, and they have different answers. Is it safe to preview — to look at the file tree and peek at a few entries? Almost always yes, because previewing does not execute anything. Is it safe to extract and run whatever is inside? That depends entirely on what is inside and where it came from. This page gives concrete, in-browser steps to answer both before you commit to extracting.

The guiding idea is look before you extract, and never let a tool auto-extract recursively into something important. You can do every check here in ZipTool without uploading the file, then decide. For the underlying attacks these checks defend against, see what is a zip bomb and security and privacy.

Step 1 — Preview the file tree first

Before extracting anything to disk, drop the archive into ZipTool and read the file list. Building the tree reads only the archive's index — the central directory at the end of a zip, or the equivalent for other formats — so it triggers no decompression of the actual payloads and no execution. It is low-risk and takes a second.

You are looking for anything that does not belong: an executable next to an invoice, a file name designed to look harmless, a deeply nested structure, or suspiciously large declared sizes. Seeing the structure is the cheapest, fastest signal you will get, and it costs you nothing because nothing is unpacked.

Drop the archive into a no-upload viewer and read the tree before extracting.
Building the tree reads only the archive index — no payloads are decompressed.
Look for files that do not belong: executables, scripts, macro-laden Office docs, nested archives.

Step 2 — Check the size and entry-count ratio

A zip keeps a small index that lists every entry's declared uncompressed size. Comparing the archive size on disk to the sum of those declared sizes is the single most telling number, and you can read it straight from the tree without decompressing a single payload byte. A 40 KB file whose contents declare hundreds of gigabytes is not a normal archive — it is a bomb or a corrupt file.

This is the classic signature of a zip bomb: tiny on disk, enormous when unpacked. None of these signs is proof on its own — a legitimate game asset pack or backup can also be large — but an extreme ratio, or a handful of files each claiming gigabytes inside a kilobyte-scale archive, is a strong reason to close the file and not extract.

Compare the archive size on disk to the sum of the declared uncompressed sizes.
A disk-to-declared ratio in the thousands or more is the classic bomb signature.
A few files each claiming gigabytes inside a tiny archive is a red flag.
An extreme ratio is a reason to not extract — better to discard than to find out the hard way.

Step 3 — Watch the file extensions inside

The extension of each entry tells you what it would do if extracted and opened. Executables (.exe, .scr, .com, .bat, .cmd, .vbs, .ps1), macro-enabled Office documents (.docm, .xlsm), and shared libraries (.dll, .so, .dylib) are the high-risk categories. A zip that claims to be an invoice but contains an .exe is not an invoice.

Also watch for double extensions and lookalike names — invoice.pdf.exe, report.txt.scr, or names using Unicode characters that resemble others. These rely on an operating system that hides known extensions, so the victim thinks they are opening a PDF when they are launching a program. The tree shows the real full name.

High-risk extensions: .exe, .scr, .com, .bat, .cmd, .vbs, .ps1, .dll, .so, .dylib, .docm, .xlsm.
Beware double extensions like invoice.pdf.exe that masquerade as documents.
Watch for lookalike names using characters that imitate common file types.
A document archive that contains executables is suspicious by definition.

Step 4 — Consider where it came from

Provenance is a strong prior. An archive you built yourself, or downloaded from an official source over HTTPS, carries little delivery risk. An archive that arrived as an email attachment from an unknown sender, or from a download site of uncertain reputation, is exactly where zip-delivered phishing and malware concentrate. The arrival channel itself is a mild warning sign.

When the source is untrusted, apply every check above and then default to caution. Preview the tree, scan any executable you genuinely intend to run with up-to-date local antivirus, and do not extract-and-double-click reflexively. For sensitive material, also make sure the tool you use does not upload the file — see why client-side is safer than uploading.

Self-made or official HTTPS downloads carry little delivery risk.
Email attachments and sketchy download sites are where archive malware concentrates.
Scan executables with up-to-date antivirus before running them.
Do not extract and then reflexively double-click an unknown file.

Step 5 — Use a no-upload tool, and verify it

Checking a zip is only private if the checker itself does not upload your file to a server. A no-upload, client-side tool parses the archive in your browser so nothing leaves your device — which matters when the archive is the very thing you are suspicious of. ZipTool works that way.

You can confirm any no-upload claim in about ten seconds. Open DevTools (F12), go to the Network tab, and open the file: no request carrying the file's contents should fire. Or load the page, disable Wi-Fi, and confirm the tool still opens and previews the file. The full method is in security and privacy.

A checker that uploads your file defeats the privacy of inspecting it.
Use a client-side tool so the suspicious archive never leaves your device.
Confirm the claim with DevTools (Network tab) and the offline test.

What checking cannot tell you

These checks dramatically reduce your risk, but they are not a verdict of "safe." A well-crafted payload can hide behind a plausible file name and a normal-looking tree, and no amount of previewing makes a malicious file benign once you extract and run it. The checks tell you when something is obviously wrong; they cannot prove something is perfectly right.

The honest summary: preview before you extract, treat obvious red flags as reasons to stop, scan executables before running them, and keep your browser updated so the sandbox and parser stay patched. For the specific attacks — bombs and path traversal during extraction — read what is a zip bomb and what is Zip Slip.

Checks reveal obvious red flags; they cannot prove a file is perfectly safe.
A plausible-looking tree does not guarantee the contents are benign.
Preview, then extract cautiously, scan executables, and keep your browser updated.

Frequently asked questions

How can I check if a zip file is safe before opening it?

Preview the file tree in a no-upload viewer before extracting anything to disk — building the tree reads only the archive index, so nothing is decompressed or executed. Then check the size and entry-count ratio (a tiny archive declaring huge sizes is a bomb signature), watch for high-risk extensions like .exe and .scr, and weigh where the file came from. None of this executes the file, so it is low-risk.

Can I tell if a zip contains a virus?

You can spot strong warning signs from the tree — executables or macro-laden Office documents inside an archive that claims to be something else, double extensions like invoice.pdf.exe, and lookalike names. But you cannot prove a file is safe from the tree alone; a well-crafted payload can look plausible. Treat obvious red flags as reasons to stop, and scan any executable with up-to-date antivirus before running it.

Is it safe to open a zip to preview it?

Almost always. Previewing a zip — listing its file tree and peeking at an entry in a viewer — does not decompress the payloads or execute anything, so it does not trigger malware or a zip bomb. The risk appears when you extract files to disk and then run them, which is a separate operation you control.

What is a zip bomb, and how do I spot one?

A zip bomb is a tiny archive engineered to decompress into an enormous size, meant to exhaust disk or memory. You spot it from the index: the archive is tiny on disk but its entries declare huge uncompressed sizes, with a disk-to-declared ratio in the thousands or more. If you see that, close the file and do not extract. See what is a zip bomb for the full mechanism.

Should I extract a zip from an unknown email sender?

With caution. Email attachments from unknown senders are a primary channel for archive-delivered malware and phishing. Preview the tree first, treat any executable or macro-laden document as highly suspicious, and do not extract-and-double-click reflexively. If you were not expecting the file, the safest action is often to delete it.

Does checking a zip upload it somewhere?

Not if you use a client-side tool. A no-upload viewer parses the archive in your browser so nothing is sent to a server — which matters when the file is the thing you do not trust. Confirm the no-upload claim with DevTools (open F12, Network tab, load the file, watch for any upload-sized request) or by disabling Wi-Fi after the page loads and verifying the file still opens.