UnpackForge

Archive viewer

Sometimes the question is not “extract this” but “what is this”. What is actually inside, how big does it get, is it encrypted, is anything in it trying to write to a path it should not, and is the file even the format its name claims?

This answers those questions without extracting anything. Format comes from the file's own signature. The listing comes from the container's own metadata — for ZIP that means the real central directory, with stored CRC-32 values and per-entry compression methods, not a guess.

The archive is read by code running in this tab. It is not uploaded, not queued on a server, and not seen by anyone but you — which also means there is no size limit imposed from outside, only what your own device can hold.

  1. Step 1Drop any archive. ZIP, RAR 4/5, 7z, TAR and TAR.GZ are all read.
  2. Step 2Read the summary: detected format, which engine read it, entry counts, expanded size, compression ratio and the archive's own SHA-256.
  3. Step 3Expand the tree for per-entry detail, then extract or convert from the same screen if you want to.

Drag archives here

.zip, .rar, .7z, .tar, .tar.gz— or anything else, and the format will be identified from the file’s own bytes. Files stay on this device.

What this page will not do

Every limit below is a real one, checked against real archives. None of them are upsells — there is no paid tier, and nothing here gets better by signing in.

  • Files inside the archive are not previewed — there is no image or text viewer here.
  • Per-entry compressed sizes are only shown where the container records them. ZIP does; libarchive's streaming reader does not expose them for RAR and 7z, so those show an archive-level ratio instead of a fabricated per-entry one.
  • Entry timestamps are shown for ZIP and TAR and blank for RAR and 7z, because this decoder does not provide them.
  • Encrypted archives are identified, but a 7z or RAR with encrypted headers cannot be listed at all — not a limitation of the viewer but of not having the key.

If it did not work

“Named .zip but its contents are RAR”

Why: The extension disagrees with the bytes.

Do this: The bytes win, which is what any correct tool does. Be careful about where the file came from, and note this is exactly how misleading downloads are packaged.

The ratio column is empty for a RAR

Why: The streaming decoder does not report per-entry compressed sizes.

Do this: Use the archive-level ratio in the summary. Nothing is being hidden; the number simply is not available and is left blank rather than estimated.

Only some entries are listed on a very large archive

Why: The entry cap for this device stopped the listing.

Do this: The banner says how many were listed and what the cap is. It exists so a file claiming four billion entries cannot lock up the tab.

Questions

Which formats can it read?

ZIP (including Zip64 and encrypted entries), RAR 4 and RAR 5, 7z, TAR (v7, USTAR, PAX and GNU extensions) and gzip-wrapped TAR. Formats that are recognised but not readable — bzip2, xz and Zstandard on their own — are named as such rather than reported as corrupt.

What does the SHA-256 refer to?

The archive file itself, so you can compare it against a published checksum. Extracted files each get their own SHA-256 as well.

Why does it say which engine read the archive?

Because it changes what you can expect. The JavaScript ZIP reader gives per-entry compressed sizes and CRCs; the WebAssembly engine gives neither but reads formats the JavaScript path cannot. Knowing which one ran explains the difference.