How to Convert a .tar.gz to a ZIP
Drop the .tar.gz into the tool below and download the .zip — gzip is detected from the file's own bytes, so .tar, .tar.gz and .tgz all work, and nothing is uploaded. Expect the ZIP to be larger than the archive you started with. In a measured test a 24.8 KB tar.gz of 300 small files came back as a 91.1 KB ZIP: 3.6 times bigger, with not one byte of the contents changed. That is the formats working as designed, not the tool failing.
Convert your TAR archive to ZIP
or drag and drop a .tar, .tar.gz or .tgz file here
Processed on your device — files are never uploaded to Filesvo.
gzip compresses the archive once. ZIP compresses every file separately
This single difference explains the size jump. A .tar.gz is made in two steps: tar glues the files into one continuous stream, then gzip compresses that whole stream in one pass. Because it is one pass over everything, gzip can spot that file 200 repeats a pattern it already saw in file 1 and store a short back-reference instead of the bytes.
A ZIP works the opposite way. Every file gets its own local header and its own independently deflated payload, so the compressor starts from nothing 300 times and can never notice that your 300 files look almost the same. All that shared structure gets paid for once per file.
So the more small, similar files an archive holds, the worse ZIP does against tar.gz — and the effect starts far earlier than most people expect. Five files was already 2.2 times bigger in the measurements below. This is not a Filesvo quirk; the same gap appears with command-line tar and zip at the same compression level.
The penalty against the number of files
The same small JSON file, packed 1 to 300 times, as a ustar tar.gz and as a ZIP. Both use deflate at level 6, so the compression algorithm is identical and the only thing changing is whether it runs over the whole archive or over each file on its own. Sizes in bytes.
| Files in the archive | tar.gz → zip |
|---|---|
| 1 | 353 → 407 (1.15×) |
| 5 | 730 → 1,630 (2.23×) |
| 20 | 2,040 → 6,220 (3.05×) |
| 50 | 4,520 → 15,417 (3.41×) |
| 100 | 8,682 → 30,756 (3.54×) |
| 300 | 25,533 → 92,167 (3.61×) |
The curve climbs steeply and then flattens: once gzip has seen enough of your files to learn the pattern, seeing more adds little. That plateau is the worst case for that kind of content, not a number that keeps growing.
What happens with real archives, not a worst case
Three hundred near-identical files is the extreme. Across six very different archives — all built with identical entry lists and identical deflate settings on both sides — the median ZIP was 1.14 times the size of the tar.gz, with a range from no change at all to 3.65 times.
Two of the six showed no difference whatsoever. An archive of 18 already-compressed files (PNGs, fonts, a WebAssembly binary, 37 MB raw) came out at 11,864,321 bytes as tar.gz and 11,908,978 as ZIP — a 0.4% gap, because there was nothing left for either method to squeeze. And a single 2.5 MB text file gave 233,192 against 233,130, with the ZIP marginally smaller.
That second case is the rule stated backwards: with one file there is no cross-file repetition for gzip to exploit, so its advantage disappears entirely. In between sat a tree of 184 source files (1.30×) and 200 server log files (1.20×). If your archive holds a handful of large or already-compressed files, converting it costs you almost nothing.
Convert anyway when the recipient matters more than the bytes
Size is not the only cost worth counting. Windows File Explorer opens a .zip by double-clicking and has done for two decades; a .tar.gz needs a separate tool, and a colleague who cannot open your archive at all is a worse outcome than an archive that is 20% larger.
The same goes for anything that accepts uploads by extension — issue trackers, form fields, some CI artefact stores and plenty of internal tools take .zip and reject .tar.gz without explaining why. Converting is the right call there, and knowing it will grow means you can check the result against an upload limit before you try.
The case for leaving it alone is when the archive is a build artefact, a backup or anything you are storing or transferring in bulk. There the extra bytes are the whole point of having compressed it, and a Linux or macOS recipient opens tar.gz natively.
Going the other way puts the size back
If somebody sends you a bloated ZIP of many small files, the ZIP to TAR tool reverses it, and the recovery is exact. Unpacking that 92,769-byte ZIP and repacking it as a tar.gz gave 25,390 bytes — within three bytes of the 25,393 the original had, the difference being timestamp granularity rather than content.
The contents survive intact in both directions. All 300 files came back byte-for-byte identical to the originals after the round trip, which is what you would expect: both formats store your files losslessly, and only the packaging around them changes.
One thing that does not survive is Unix file permissions, because the ZIP written here does not record them. If the archive contains scripts that need to stay executable, keep it as a tar.gz.
A .tar on its own makes files bigger, which is the other half of the story
Tar is not a compressor and never has been. It is a way of laying files end to end with a 512-byte header before each one, and it pads every file up to the next 512-byte boundary. That is why .tar.gz has two extensions: tar does the gluing, gzip does the shrinking.
The overhead is easy to see when the files are small. The 300 JSON files above are 334,939 bytes on disk; packed as a plain ustar .tar they take 615,936 bytes — 1,203 blocks of 512, and 1.84 times the size of the files themselves. Only after gzip does the archive become smaller than its contents.
On the command line the two steps are one flag apart: tar -czf archive.tar.gz folder/ compresses, tar -cf archive.tar folder/ does not. The tool here reads both, checking the file's actual bytes for the gzip signature rather than trusting the extension.
If you are building an archive from scratch rather than converting one, the TAR creator and the ZIP creator both run in the browser too.
Frequently asked questions
- Why is my ZIP bigger than the .tar.gz it came from?
- Because gzip compresses the whole tar stream in one pass and can reuse patterns across files, while ZIP compresses each file separately and cannot. The more small, similar files the archive holds, the wider the gap: 3.6 times for 300 small JSON files in a measured test, and no difference at all for a single file.
- Does converting lose any data?
- No. Every file's contents are preserved exactly — a full round trip of 300 files came back byte-for-byte identical. Folder paths and modification times carry over as well. Unix permissions do not, because the ZIP written here does not store them.
- Does it handle .tgz as well as .tar.gz?
- Yes. The gzip signature is read from the file's own bytes rather than its name, so .tar, .tar.gz and .tgz all work whatever they are called. .tar.bz2 and .tar.xz do not, because browsers only ship a gzip decompressor.
- How do I convert a tgz to zip on Linux?
- Two commands: tar -xzf archive.tar.gz to unpack it, then zip -r archive.zip on the extracted folder to repack it. The tool on this page does exactly that without unpacking anything to your disk, which is the practical difference on a machine you do not control.
- When should I not convert?
- When you are storing or transferring the archive in bulk and the recipient runs Linux or macOS, both of which open .tar.gz natively. Convert when the recipient is on Windows or when something accepts uploads by extension and rejects .tar.gz.
- Is my archive uploaded anywhere?
- No. It is unpacked and repacked by JavaScript in this page using the browser's built-in compression API. The archive and its contents never leave your device.