Check a ZIP File Before Extracting It

A ZIP file is a container, not a safety certificate. Before extracting it, confirm why you received it, review its contents without launching members, and check it with an approved security tool. If the archive is unexpected, encrypted without explanation, or contains suspicious paths or executables, stop and ask for review.

The useful question is not “Can my computer open this ZIP?” It is “Can I unpack these particular files in this particular location without taking an unnecessary risk?” A routine diligence download and an unsolicited invoice archive deserve different handling. This guide focuses on screening before extraction, rather than repairing a corrupt download or fixing a missing file.

Start with the delivery context

Check whether the sender and delivery channel match a request you made. An archive arriving from a familiar display name still needs scrutiny when its subject, timing, or content is unusual. Verify an unexpected delivery through an established contact route rather than replying to the message that supplied it.

Ask for a short manifest: expected filenames, approximate size, and the business purpose. A supplier sending three contract PDFs should not need an executable installer or a nested archive full of unrelated material. A mismatch is a reason to pause, not proof of wrongdoing.

Keep the original message and download location available for a reviewer. Do not circulate the attachment to several colleagues asking whether it looks suspicious. That multiplies exposure and can spread confidential material. Send the security team the approved reference or ticket instead.

Treat the extension as a clue, not a verdict. A file called documents.zip might be a valid archive, a misleading file, or a container holding dangerous members. Use the current approved archive application to inspect it, and avoid software obtained through adverts or prompts inside the delivery email.

Review names and sizes without opening the members

Use the archive application's list view first. Reviewing a listing does not make an untrusted parser risk-free, so keep the application updated and follow your organization’s handling policy. Do not double-click individual files during this first pass.

Look for unexpected file types, duplicate-looking names, and unusually deep folder structures. Make file extensions visible where your operating system supports it. A filename ending in .pdf.exe should not be handled as a normal PDF simply because the familiar part is visible first.

Check the expanded size as well as the downloaded size. An archive that expands beyond the device’s available capacity should not be unpacked on that device. Large expansion is sometimes legitimate, but a small download that predicts an enormous output needs explanation before processing.

A plausible list is one check, not permission to ignore the remaining checks. A malicious file can have an ordinary name and a realistic size.

Protect the extraction destination

Extraction writes files. That makes the destination an important boundary. Do not unpack an unfamiliar archive into a folder containing active project files, system files, scripts that run automatically, or the only copy of a document collection.

Use an empty destination approved for review. Keep it outside your production document tree until the files have been assessed. Avoid a shared folder that automatically syncs newly extracted material to clients or an entire team. A convenient downloads folder may also be synchronized, so check its behavior rather than assuming it is private.

Suspicious archive paths can try to write outside the intended location. This is often called path traversal. Technical staff should use extraction tooling that validates the final destination of every member and handles links and unusual paths safely. Python’s archive documentation warns about untrusted extraction. Python ZIP archive documentation

For a nontechnical reviewer, the practical rule is simpler: do not try to repair suspicious paths by renaming them yourself and extracting anyway. Ask the sender for a clean package or have the security team review the archive in an appropriate environment. A filename beginning with an unexpected absolute path or containing repeated parent-directory segments is not a normal document delivery requirement.

Do not overwrite existing files as part of screening. If the application proposes an overwrite, cancel and use a new empty location. Overwrite prompts may be ordinary when extracting twice, but they still defeat the clean separation you need for a reliable review.

Scan and interpret the result carefully

Run the approved scanner against the saved archive before extraction. On a supported Windows device, the file’s context menu can offer a Microsoft Defender scan; managed systems may provide a different approved route. Microsoft: Scan an item with Windows Security Follow the interface and policies available on your device instead of installing a second antivirus product for this task.

Record what the scanner actually reports. “No threats detected,” “password protected,” “scan failed,” and “unsupported format” are different outcomes. Do not summarize all four as passed. If the archive is encrypted, the scanner may not have inspected its members; follow the separate process for unscannable encrypted files.

After approved extraction, screen the resulting folder too, if your workflow requires it. That gives the scanner access to individual files, but it still does not verify business legitimacy or guarantee that every threat is known. Review the files against the manifest before opening them.

Never disable protections because a message says the archive is urgent. If a legitimate package conflicts with your controls, its owner and security team can agree on an authorized route.

A worked example: a supplier evidence pack

Consider a fictional operations team expecting four PDFs from a supplier. The supplier sends a 12 MB ZIP. In list view, the reviewer sees the four expected filenames, an additional script, and a second archive named attachments-final.zip. The sender’s manifest mentions neither extra item.

The reviewer leaves the ZIP unopened, records the two discrepancies, and contacts the supplier using the number already stored in the vendor record. The supplier confirms that its automated export included a troubleshooting script and offers a replacement containing only the approved documents. The first ZIP remains held while the security team decides whether any further investigation is necessary.

This example does not show that all scripts are malicious. It shows that unnecessary executable content should not be accepted merely because useful documents are present too. The corrected delivery reduces both uncertainty and the work required to review it.

When the new archive arrives, the reviewer repeats the process rather than treating the earlier conversation as permanent clearance. The new manifest matches, the expanded size is reasonable, and the local scan completes without detection. The reviewer extracts into an empty, nonsynchronized review folder, checks the members, and then moves approved files into the working collection.

The release record includes the package version, manifest, screening result, reviewer, and final destination. It does not include a claim that the files are guaranteed safe. The recipient still opens them with updated applications and observes any warning presented by the document viewer.

What to do when a check fails

If the sender cannot explain the contents, request another delivery method. For example, individual approved PDFs may be easier to inspect than a complex collection of nested archives. Do not upload confidential material to a public analysis website to make the uncertainty disappear.

If storage requirements are excessive, do not test the expansion on your normal laptop. The technical reviewer can decide whether the size is expected and where processing is suitable. If the archive application crashes or behaves unexpectedly, stop experimenting and preserve the information needed for support.

A security hold should have an owner and a next action. “Waiting for IT” is not enough when the package blocks a transaction. Record whether you need a manifest, a clean replacement, an authorized review environment, or confirmation of the delivery channel. That keeps the business moving without reducing the standard of inspection.

If a member was already launched before the concern was identified, report that fact promptly. The situation has changed from pre-extraction review to possible exposure. Do not quietly delete the files and describe the package as rejected before use. Accurate timing lets the response team assess the right scope.

Use a short release checklist

Before moving extracted documents into a working folder, answer six questions: Was the delivery expected? Did the sender’s manifest match? Were names, paths, and expanded sizes plausible? Did the approved screening finish? Was extraction isolated from active files? Were unexpected members resolved?

Keep those answers proportionate to the sensitivity of the content. A public brochure and a client evidence pack do not need identical records, but neither benefits from a vague assumption that ZIP means safe. Teams processing archives repeatedly should define the review location and escalation owner in advance.

Avoid turning the checklist into a ritual that nobody can explain. Each check addresses a different failure: wrong delivery, concealed members, unsafe writes, limited malware visibility, uncontrolled propagation, or unresolved exceptions. If the workflow skips a check, record why and who accepted the remaining uncertainty.

Frequently asked questions

Does scanning a ZIP guarantee it is safe?+

No. A scan is one screening result within a defined scope. Sender legitimacy, file behavior, encrypted members, and extraction paths still need consideration.

Should I extract a suspicious ZIP to see what is inside?+

Use a listing view and your approved review process first. Do not extract or launch members just to satisfy curiosity.

Can I use a public scanning website for a confidential archive?+

Only if your organization explicitly approves that disclosure. Prefer an authorized local or internal analysis route for private material.

Before you proceed

A good ZIP review ends with a documented decision: release the expected files, request a corrected package, or hold the archive for technical assessment. Do not confuse successful extraction with successful security review.

Parent guide

• Check Whether a Document Request Is Genuine

Related articles

• Scan a Confidential PDF Without Uploading It

• Handle Encrypted Files Your Scanner Cannot Check

• Encrypt a ZIP File Before Sending Documents

Sources and editorial disclosure

Primary documentation reviewed October 13, 2026. Worked examples are fictional illustrations. Checklists and decision frameworks are editorial recommendations; product-specific facts are linked to official documentation. These guides do not claim that signed-in product tests or customer projects were performed.

• Python ZIP archive documentation

• Microsoft: Scan an item with Windows Security

VDR Directory is published by the team behind SendNow. This ownership is relevant when evaluating any product mention. Stock photos illustrate general context; they do not demonstrate software features or identify actual affected people. Controls and tool availability depend on the provider, edition, version, device and configuration. No guide guarantees confidentiality, regulatory compliance, acceptance of altered documents, or search rankings.