Open a .tar.gz, .tgz, .tar or .gz in your browser and download the files inside individually or as one zip. Nothing is uploaded, nothing is installed.
🔒 Private by design: your files are processed locally in your browser and never uploaded to any server.
The reason a tarball confuses people is that the name describes a stack rather than a format. Tar is an archiver with no compression: it concatenates files into one stream, each preceded by a fixed size header block describing the file that follows. Gzip is a compressor with no concept of multiple files: it squeezes one stream of bytes.
Put them together and you get the Unix convention. Tar the directory, gzip the result, and you have a single .tar.gz, usually abbreviated to .tgz. Opening it means undoing the gzip layer to recover the tar stream, then walking the tar stream’s headers to find where each file starts and how long it is.
Zip does both jobs in one format, with an index at the end so any single file can be pulled out without touching the rest. Tar has no index, which is why a tarball has to be read from the beginning.
Opening a tarball
- Drop a .tar.gz, .tgz, .tar or .gz onto the box. One archive at a time.
- Run it. The gzip signature is checked, the stream is decompressed if present, and the tar headers are walked.
- Take the individual files, the zip of everything, or both, depending on how many files were inside.
- Clear the box to open the next one.
Reading tar headers, and what gets skipped
Each entry in a tar stream begins with a 512 byte header. The name sits at the front, the size at offset 124, and the size is written in ASCII octal rather than decimal, which is the classic trap for anyone implementing this from a half remembered spec. There is a checksum field too, computed over the whole header with the checksum field itself treated as spaces.
Not every entry is a file. A tar stream can also contain directories, hard links, symbolic links, device nodes, FIFOs and extended header records that carry metadata for the entry that follows. Those are recognised by their type flag and skipped from the results, since none of them is a file a browser download could represent, and their blocks are stepped over so the scan stays aligned.
One extension is handled specially. When a path is too long for the header’s name fields, GNU tar writes a placeholder entry whose data block contains the real long name and applies it to the next header. That is implemented. The alternative extended header mechanism used by some other tar implementations is not, so a file named that way appears under a truncated name. Its content is still extracted correctly.
Two ceilings, for two different reasons
The size ceiling is about memory. Everything is held uncompressed in the tab at once, so an archive whose entries sum to more than about a gigabyte is refused before extraction rather than being attempted and crashing the tab. The figure that matters is the uncompressed total, which for a tarball of source code is often many times the size of the file you downloaded.
The file count ceiling is about the interface. Results are rendered as a flat list of download links, and two hundred links is already a lot to scroll past. Above that count the individual links are dropped and only the zip bundle is produced, which is the sensible thing to hand someone who has just opened an archive of a thousand files.
Unzip Files handles the zip format and shares this tool’s naming, bundling and size limits directly rather than reimplementing them. Zip Files goes the other way and packs a set of files into an archive, which is the format to choose if the recipient is on Windows.
For the two other formats that also need software on a fresh machine, RAR Extractor covers the proprietary one and 7z Extractor covers the other. The rest are on the dev tools hub.
Frequently asked questions
Why does Windows struggle with a .tar.gz when it opens .zip fine?
Because a tarball is two formats stacked rather than one. The tar layer glues files end to end into a single stream with no compression at all, and the gzip layer compresses that whole stream as one blob. Windows has understood zip for decades and understands neither of these natively, which is why the usual advice is to install a desktop archiver. Here both layers are handled in the page, so no install is needed.
Does it handle a plain .tar or a bare .gz too?
Yes. The file is checked for the gzip signature in its first bytes rather than by its extension, so a compressed file is decompressed first and a plain tar is read directly. That also means a file with the wrong extension still opens correctly. A .gz that turns out to contain something other than a tar stream will not produce a file list, since there is no tar structure inside it to read.
What do I get back after extraction?
It depends on the count. A tarball holding exactly one file gives you that file on its own. Between two and two hundred files you get every file as its own download plus one extra zip containing all of them, so you can take a single file or the whole set. Above two hundred files the individual links would be an unusable wall, so only the zip is produced.
How big an archive can it open?
Roughly one gigabyte of uncompressed content. Everything has to be held in your tab's memory at once, so the limit exists to refuse an oversized archive before it can exhaust the tab. Note that this is the uncompressed total, not the size of the file on disk, which matters for tarballs specifically because a tarball of text or source code routinely expands by a factor of five or more.
Do the directories inside a tarball survive extraction?
Not as directories. A browser download writes a file, never a tree, so each path is converted into one name with the separators replaced. Where that would make two files collide, a numeric suffix goes in before the extension so nothing is silently overwritten. The zip bundle carries the same flattened names, so it is not a route back to the original layout either.
Are symbolic links and hard links extracted?
No. Those entries are recognised and skipped, along with device nodes and extended header records, because none of them carries file content that a browser download could meaningfully represent. Their blocks are still stepped over correctly so the scan stays aligned with the rest of the archive. A tarball that consists mostly of links will therefore produce fewer files than its listing suggests.
Are long file names handled?
The GNU long name extension is, which is the one that matters in practice because GNU tar switches to it automatically whenever a path is too long for the classic header fields. The alternative extended header mechanism that some other tar implementations prefer is not resolved, so a file whose long name was recorded that way appears under its truncated name instead of its full one. The file content is still correct either way.
Is there a file listing before extraction?
No. Extraction is a single action with no preview step, so you receive everything the archive contains rather than picking from a list. That is a real limitation of the shape this tool uses, and it is worth knowing before you open a large archive to retrieve one file.
Does the archive get uploaded anywhere?
No. Decompression and tar parsing both run inside your browser tab on bytes read from your own disk, and no part of the archive or its contents is transmitted. That is worth more here than for most file types, because a tarball is usually an entire source tree, backup or server dump rather than a single document.