Archive File Extractor
Inspect a local ZIP, TAR or GZIP archive and download selected safe files as a normalized ZIP package with blocked paths clearly excluded.{{ summaryTitle }}
{{ summaryLine }}
| Path | Expanded | CRC-32 | Decision | Copy |
|---|---|---|---|---|
| {{ row.path }} | {{ row.sizeDisplay }} | {{ row.crc32 }} | Included |
Introduction:
An archive combines stored names with file data so a set of files can travel as one object. ZIP normally combines packaging and compression. TAR records a directory tree and file data in fixed-size blocks, while GZIP is a compressed stream that usually represents one file. A .tar.gz or .tgz file applies GZIP compression to a TAR archive.
Extraction is a write operation, not merely decompression. Every member name can become an output path, so a hostile archive may try to write outside the intended directory with an absolute path or .. segment. Links, device nodes, colliding normalized names, and ambiguous legacy filename encodings can also make the restored tree differ from the list a person reviewed.
| Hazard | What can happen | Useful control |
|---|---|---|
| Path traversal | A member targets a parent or absolute directory | Require normalized relative paths |
| Path collision | Different stored names resolve to one output name | Block every colliding entry |
| Link or special entry | Extraction creates an indirect or non-regular filesystem object | Package regular files only |
| Expansion bomb | A small archive expands to excessive memory or storage | Limit per-entry ratio and total expanded bytes |
| Corrupt data | Decompressed bytes do not match the stored integrity value | Verify size and CRC before packaging |
Selective extraction reduces exposure because only reviewed regular files are decompressed and repackaged. It does not make their contents trustworthy. A valid CRC confirms accidental corruption was not detected; it does not identify the author, prove authenticity, or scan documents and programs for malware.
A safe handoff keeps the stored path visible, explains why blocked entries were excluded, and writes accepted files under a fresh destination or package. Permissions, owners, executable bits, extended attributes, and links should not be assumed to survive a safety-focused rewrite.
How to Use This Tool:
Inspect the archive first, choose only entries marked safe, and treat the generated ZIP as a new reviewed package.
- Choose one ZIP, TAR, TAR.GZ, TGZ, or single-file GZIP archive no larger than 16 MiB.
- Review the normalized paths and blocked reasons. Sorting paths alphabetically changes review order only; archive order preserves the original listing order.
- Select one or more safe regular files. At most 200 files and 64 MiB of selected expanded content can enter one output package.
- Start extraction. If a selected ZIP member fails size or CRC-32 verification, discard the stale result and choose a valid source or different reviewed entries.
- Check the package name, included paths, expanded sizes, and CRC-32 values before downloading the generated ZIP.
Interpreting Results:
Safe file means an entry passed the tool's path, type, encoding, encryption, method, size, ratio, collision, and integrity rules. It does not mean the content is harmless or appropriate to open. Scan or inspect unfamiliar output with controls suitable for the file type.
Blocked entries remain outside the generated package. A mixed archive can still produce a reviewed ZIP from accepted files, but the omitted paths should be noted when completeness matters. Directory markers are not packaged separately; accepted file paths recreate the necessary directory structure inside the ZIP.
The expansion ratio compares selected expanded bytes with the source archive size. It helps describe the job but should not be read as a compression-quality score because unselected members and archive headers are still part of the source size.
Technical Details:
The archive is parsed into bounded entry records before selected content is packaged. ZIP uses its central directory, TAR uses checksum-verified 512-byte headers and end markers, and GZIP exposes one decompressed member name. Format detection follows the byte signature rather than trusting the filename alone.
Rule Core:
| Check | Accepted rule | Blocked case |
|---|---|---|
| Path | Relative, normalized, 1 to 240 characters, at most 20 segments | Absolute paths, drive paths, control characters, .., or excessive depth |
| Entry type | Regular file | Symbolic links, hard links, and special entries |
| ZIP name | Safely normalized filename | Unsupported non-UTF-8 legacy filename |
| ZIP method | Stored or Deflate, unencrypted | Encryption or another compression method |
| Expanded file | At most 32 MiB and expansion ratio no greater than 100:1 | Oversized or unusually expanding member |
| Normalized identity | One stored entry per normalized path | Two names resolving to the same output path |
| Selection | 1 to 200 files; total expanded size at most 64 MiB | Empty, duplicated, oversized, or blocked selection |
Formula Core:
The displayed selection ratio divides the total expanded bytes of the selected files by the complete source archive size.
Ei is the expanded byte count for selected file i, and S is the source archive size in bytes. Entry safety uses a separate ratio, expanded bytes divided by compressed bytes; values above 100 are blocked, while exactly 100 is accepted.
Transformation Core:
Accepted paths are normalized to forward-slash relative names. Only selected data is decompressed, and every selected ZIP file must match its declared expanded size and CRC-32 value. The files are then written into a new ZIP package with a fixed timestamp and a bounded output size of 72 MiB. The generated package is reopened and compared with the reviewed path, size, and CRC list before it is offered for download.
ZIP64 and split or multi-disk ZIP archives are rejected. TAR owners, modes, link semantics, and extended attributes are not carried into the reviewed ZIP, and a standalone GZIP input becomes one regular file.
Privacy and Safety Notes:
The archive bytes, entry names, decompressed content, and generated ZIP stay in memory in the active browser tab. They are not uploaded or stored by the service.
- Path and expansion checks reduce extraction risk but do not scan for malware or unsafe document content.
- CRC-32 verifies accidental corruption, not authorship or cryptographic authenticity.
- Encrypted ZIP, RAR, 7z, split archives, sparse TAR, links, and special filesystem entries are not supported.
- Use a dedicated destination when unpacking the downloaded ZIP, especially when the source came from an untrusted sender.
Worked Examples:
TAR with one traversal path
Suppose a TAR contains ../outside.txt, a symbolic link, and folder/report.csv. The traversal path and link are blocked, while the regular CSV can be selected and written to the new ZIP as folder/report.csv. The result is a reviewed subset, not a complete restoration of the TAR.
References:
- ZIP File Format Specification, PKWARE.
- RFC 1952: GZIP File Format Specification version 4.3, RFC Editor, May 1996.
- Testing Upload of Malicious Files, OWASP Web Security Testing Guide.
- How to extract .tar.gz files in Linux, Simplified Guide.