Archive extractor — open ZIP / gzip / tar / tar.gz in your browser

“Opening an archive” means handling everything someone packed into it

When you drop a ZIP / gzip / tar / tar.gz into an extractor, the payload is, on average, “a bundle of files someone made for a specific purpose”. Concrete examples include source code releases or Python wheels, log archives pulled out of a server, transcripts and meeting minutes packed together, foreign vendors’ specs and sample data, “here’s everything zipped up” attachments from Slack or email, designer asset bundles exported from Figma, and database dumps such as .sql.gz. The set spans business and personal use.

Their contents tend to carry more sensitive payload than the filenames suggest. Source headers carry author names and licence headers; package.json files leak organisation names and internal registry URLs; log archives can contain auth tokens, IPs, user IDs; database dumps are literally the user data; specs and sample data sometimes include unreleased pricing or working accounts. An operation that feels like “I just want to see what’s inside” turns into “I handed every file over to a third party” the moment it goes through an upload-style service.

What an “online unzip / tar.gz extractor” actually gets

Queries like “online unzip”, “tar.gz extract online”, “open .gz mac” have high search volume and feed upload-style SaaS that does not advertise in-browser processing. Unlike single-file format converters, the entire archive — every nested file — lives on the operator’s servers as soon as it is uploaded.

Terms of service typically cover archive contents under “uploaded content may be used to improve the service”, so log archives, SQL dumps, and internal specs end up subject to that clause. For organisations with a data-handling policy, sending such archives off for “just decompression” is a clear grey area, and is often an outright policy breach. “Deleted after N hours” promises do not guarantee that backups or log servers retained no trace before deletion, and the burden of proof falls on the user if anything goes wrong.

fflate (pure JS) plus an in-tool tar parser, all in the browser

This tool uses fflate (MIT) to decompress archives. fflate is a pure-JavaScript compression library (no WebAssembly required) covering ZIP Stored / Deflate, gzip streams, and zlib streams. tar is not natively supported by fflate, so this tool includes a hand-rolled tar parser (POSIX ustar format) of roughly 200 lines. .tar.gz runs as a two-stage pipeline: gunzipSync first, then the tar parser.

The flow after a file is dropped is (1) detect the format from magic bytes (PK = ZIP, 1f 8b = gzip, ustar at offset 257 = tar), (2) decompress through the matching routine, (3) classify each entry as text / image / binary from its extension and content, (4) decode text via TextDecoder("utf-8", { fatal: true }) for a UTF-8 attempt, hand images to URL.createObjectURL(Blob) for an <img> element. The decompressed bytes, the decoded text strings, the image blobs, and the rebuilt ZIP all stay in browser page memory — there is no networking code in this tool. The implementation is open source on GitHub for third-party audit.

Filling the “macOS / Windows can’t open this” gap as a daily-use tool

macOS Finder only extracts .zip out of the box; .gz and .tar.gz do not respond, even though gunzip and tar ship with the OS, because Finder is not wired to them. Windows Explorer behaves the same way. The choices are then “open a terminal and run gunzip / tar xzf”, “install 7-Zip / The Unarchiver”, or “use an online tar.gz extractor”. The first two cost a tool install, the third costs handing the contents to the operator — none of them are a good trade when the archive contents are at all sensitive. Keeping an in-browser extractor bookmarked saves you that decision every time.

If you only need a fast listing without decompression (works even on huge ZIPs), the archive-info tool in the same category reads the Central Directory only. This tool (archive-extract) is the complementary operation — actually expand the contents and preview them.

POSIX tar / ustar / pax structure and what this tool covers

A tar archive is a sequence of (512-byte header + body padded to 512 bytes) records. The header carries name in the first 100 bytes, size as a 12-byte octal string at offset 124, typeflag at offset 156 ('0' = regular file, '5' = directory, '1' = hard link, '2' = symlink, etc.), and the ustar\0 magic at offset 257. This tool processes '0' and '5'; links are ignored.

The GNU long-link extension (L typeflag), pax extended headers (x typeflag), sparse files, and ACL entries are not currently supported. File names beyond 100 bytes are reconstructed by joining the optional prefix field (155 bytes at offset 345), giving up to 255 characters. Anything longer, or non-ASCII edge cases, should be handled with GNU tar xzf. bz2 / xz / 7z are intentionally left out for bundle-size reasons; reach for The Unarchiver / 7-Zip / Keka if you need them.

ZIP encryption and what this tool intentionally does not support

ZIP supports two encryption schemes: legacy ZipCrypto (weak, 1990s) and AES (used by WinZip / 7-Zip, strong). This tool supports neither. The reason is design, not a missing API: (a) the desired UX for opening encrypted ZIPs is “type the password and see the contents”, and (b) doing that in a browser surfaces every file on screen, where it then sits in page memory and the GPU compositor cache, giving plenty of room for accidents.

If you have the password, unzip -P <password> on macOS or Keka / 7-Zip on the desktop is the safer route. Recovering an unknown ZIP password is a separate problem with no in-browser solution short of brute force. For workflows like “extract an image and sanitise it before sharing”, combine this tool with image-side cleaners such as image-exif-strip to strip EXIF / GPS metadata right after extraction.