ZIP file check: verify a delivery against its expected list

A ZIP file check should compare the extracted delivery with an expected list and open every required file, not merely confirm that the archive exists. With five ready harmless files and a working desktop, this fifteen-minute exercise produces a small manifest, a clean extraction folder and a saved acceptance decision.

Last updated: 2026-10-18

What should a ZIP file check establish?

An archive is a container for files and folders. Creating that container is not the same as accepting its contents for delivery. A designer can send a ZIP that opens normally yet lacks the final image, includes a working draft or places the right document in an unexpected folder. A successful extraction message does not settle those questions.

Begin with an expected list. A manifest, in this guide, simply means a written list of the files you intend to include. It need not be generated by software. For a small practice package, a table with a relative path, purpose and observable content detail is enough to make the review concrete.

Anar Rüstəmli's document analysis guide recommends starting with known material and checking the output against the source. This exercise applies that published method to an archive. It is not an account of him testing ZIP tools or delivering a particular client's files. The sample package below is deliberately fictional.

The attachment and shared-link guide addresses delivery routes and recipient access. This article answers a narrower question: what did your particular archive actually produce when extracted? It does not establish that someone else received it, has the required applications or has approved the business content.

Write the expected paths before inspecting the archive

Choose five harmless files you already have permission to use. Avoid real customer material for a training task. The following sample is an invented handoff for a small creative studio; substitute your own non-sensitive files rather than spending the exercise creating exactly these assets.

A relative path describes a file's position within the package, without your computer's drive name or personal home folder. “front.jpg” alone does not distinguish an image at the top level from one in the images folder. Write the intended structure so that a reviewer can identify misplaced items as well as missing names.

Decide whether the manifest itself belongs inside the archive. If you include it, add it to the expected list as another file. If the exercise is defined as five content files with a separate checklist, retain the checklist outside. Otherwise you may manufacture a count mismatch by changing what the count includes halfway through the review.

Resolve uncertainty about the required content version before packaging. A perfectly assembled archive can still contain the wrong approved text. This checklist assesses whether the package matches its stated input requirements; it does not invent those requirements or authorize an unapproved deliverable.

Create the archive and extract it into a clean test folder

On Windows, the documented route is a right-click on the prepared folder, then Show more options > Send to > Compressed (zipped) folder. Use Extract All on the archive to extract it. On Mac, Control-click the folder and choose Compress; double-click the ZIP to expand it. These are the basic Microsoft and Apple procedures linked below.

Use an archive you created from your own known practice files. This is not an inspection method for deciding whether an unknown download is safe. Encrypted archive support and application compatibility are separate issues. If a password prompt or unsupported format prevents the exercise, record the obstacle and keep the acceptance decision pending.

Create a new empty test folder. On Mac, placing a copy of the ZIP inside that folder before expansion makes the destination easier to distinguish. On Windows, choose the clean folder as the extraction destination. The purpose is to prevent files left from an earlier trial from hiding an omission in the archive being reviewed.

After extraction, open the output folder rather than the original source folder. Compare paths relative to the clean test folder, retaining delivery/ in the sample paths. On Mac, exclude the ZIP container you copied there from the extracted-file count and unexpected-path list. Similar names can make two windows easy to confuse. Record which location is the source and which contains extracted copies. Merely browsing names inside the archive is not the same as opening the files that a recipient would use after extraction.

The expected result of this step is an identifiable set of extracted files. Do not mark content acceptance yet. You have prepared the material for the next comparison, not proved that it matches the manifest. Keeping those two stages distinct makes it easier to diagnose a later failure.

Compare paths, then open every expected file

Work down the expected list and mark whether each relative path exists in the extraction. Next inspect the extraction for paths not present on the list. Finally open every required file from the extracted folder and check the particular detail you chose beforehand. For this small exercise, there is no need to sample just one file.

Counts are useful as a warning, not as the complete acceptance rule. Imagine that the five-file sample contains “draft.jpg” instead of “back.jpg”. Five files still exist. The path comparison should report one missing path and one unexpected path. A note saying “five files extracted” would miss the actual handoff error.

Opening is also different from matching. A text file may open normally but contain an empty draft instead of the three intended menu items. A JPEG may display correctly but show the wrong product. Record the observable mismatch rather than equating any readable file with the required deliverable.

• Missing: an expected path is absent from the extraction.
• Unexpected: an extracted path is not part of the expected delivery.
• Unreadable: the extracted file cannot be opened with the intended available application.
• Content mismatch: it opens but does not show the stated required detail.
• Passed: the path and the stated content check both match.

Do not silently ignore support files merely because they look unimportant. Record them as unexpected and decide whether the intended delivery should include them. If you change the package, create a new archive and repeat the review in another clean folder. The old acceptance record does not automatically cover the changed archive.

Save an acceptance note that preserves unresolved issues

On Windows, open Notepad from Start and create a new document. On Mac, open TextEdit from Finder > Applications, choose File > New and, if needed, Format > Make Plain Text. Copy the template below into that document. Each statement should describe something you actually checked. For five files, a line beside each manifest entry is usually enough; a lengthy report does not compensate for an unopened file.

Archive filename and location:
Expected manifest reference:
Expected content-file count:
Clean extraction folder:
Actual extracted file count:
Missing relative paths:
Unexpected relative paths:
Unreadable files:
Content mismatches:
Every required file opened: yes / no
Decision: ready / revise / pending
Checked by and date:

After completing the note, choose File > Save and save as zip-check.txt in Documents. Close the document, then reopen that file from Documents in File Explorer or Finder. Confirm that the archive name, manifest reference and results for all five files remain present.

In the invented wrong-image example, the correct decision is “revise”. Repair the source delivery folder, create another archive and extract it into another empty location. Repeat the whole small manifest, not just the image you added. That provides an acceptance record for the new package rather than a patchwork of observations about different versions.

If a required application is unavailable, avoid declaring the file corrupt without evidence. The narrower observation is that it could not be opened in the current environment. Identify the needed viewer or ask the responsible colleague to perform that check later. Until then, the affected line remains unresolved.

The fifteen-minute exercise assumes ready practice files and working tools. Installing applications, purchasing licenses and waiting for a recipient are outside that condition. You can still finish a useful manifest and a pending issue record when execution is blocked; you should not call the package accepted.

Keep packaging, confidentiality and approval separate

This review shows whether the archive produced the expected files and whether those files passed the stated local opening checks. It does not prove encryption, authenticity, unchanged transmission or compatibility with every recipient's device. An ordinary ZIP workflow here is not a confidentiality control. Treat those requirements as separate work rather than reading them into the word “compressed”.

Nor should you require a dramatic size reduction. Microsoft notes that already compressed JPEG images may produce little difference when placed in a ZIP. If image preparation is the actual problem, the image optimization guide covers that different task. The container's job in this exercise is to group the intended material, not choose its visual quality.

For recurring work, place the short acceptance sequence in your standard operating procedure, meaning the written instructions for repeating the task. Keep content-version approval separate through the document version approval check. Matching a manifest is useful evidence about packaging; it is not authorization to publish or distribute business content that still needs approval.