ZIP or TAR: Which One, and Why It Matters
Published 8/21/2026 · 12 min read · File tools
Daniel Okonkwo — Front-end developer and tech writer at OneKitly
Web performance · File formats
Checked against 4 sources
Send a ZIP if you do not know what the recipient runs. Use a .tar.gz if the files are many, small and alike, or if permissions and symlinks have to survive. Everything else follows from one structural fact: TAR does not compress at all — it concatenates files behind 512-byte headers — while ZIP compresses each member separately. Compression is then applied to the whole TAR as one stream, which is why the double extension exists. Here is what that is worth, measured. Sixty near-identical JavaScript files, 193 bytes each, 11,604 bytes of source in total. As a plain .tar: 63,488 bytes — five and a half times the source, because every member is padded up to a whole 512-byte block. As a .tar.gz: 1,809 bytes. As a .zip: 14,686 bytes. The .tar.gz is eight times smaller than the .zip holding exactly the same files, and turning the ZIP compression dial up changes nothing at all — the archive comes out at 14,490 bytes at every level from 1 to 9, because each member is 193 bytes and there is nothing for the compressor to find inside one file. Gzip sees all sixty at once and spots that they repeat each other. The price is the mirror image: a ZIP carries a central directory, so a reader can jump straight to one member; a .tar.gz has no index at all, so pulling one file out means inflating the stream from the beginning. That is the trade, and neither side wins it outright.
One structural difference explains everything else: TAR does not compress, it only stacks; ZIP compresses each file on its own. Measured on 60 small source files, that is the difference between 1,809 bytes and 14,686.
The structural difference, in one paragraph
A TAR file is a stack. For each member it writes a 512-byte header — the name, the mode, the owner, the size in octal, the modification time, a checksum, a type flag — then the file's bytes, then padding up to the next whole 512-byte block. Two blocks of zeroes mark the end. There is no index, no compression and no clever bookkeeping: that is the entire format, and it has barely changed since it was designed for tape drives, which is where the name comes from.
A ZIP is a filing cabinet. Each member is compressed on its own with deflate and written with its own local header; at the end of the file comes a central directory listing every member, its size, its compressed size and where in the file it starts. A reader opens the last few kilobytes, reads the directory, and knows the whole contents without touching a byte of the data. That design is why a mail client can show you what is inside an attachment before you extract it.
Everything else in this article is a consequence of those two paragraphs. Size, single-file extraction, permissions, symlinks, corruption behaviour — none of it is arbitrary, and none of it requires memorising a comparison chart once you can picture a stack on one side and a filing cabinet on the other.
Why .tar.gz wins on many small similar files
Deflate works by finding repeats inside a sliding window and replacing the second copy with a short reference. In a ZIP that window is reset at the start of every member, so a compressor looking at a 193-byte JavaScript file has almost nothing to work with: the imports, the boilerplate and the closing brace are all present in the other fifty-nine files, and it will never see them. In a .tar.gz the compressor is handed one continuous 63,488-byte stream in which those fifty-nine copies are right there, a few hundred bytes apart.
The measurement makes it concrete. The same sixty files: 1,809 bytes as .tar.gz against 14,686 as .zip. That is not a tuning difference. Running the same sixty through a ZIP writer at every compression level from 1 to 9 produced byte-for-byte the same 14,490-byte archive nine times — the dial is connected to nothing, because there is nothing inside a 193-byte file for the highest setting to work harder on. At level 0, which stores rather than compresses, the ZIP came to 18,328 bytes, so the compression is doing something; it is simply doing it in the wrong place.
Turn the corpus around and the advantage evaporates. Compress one 92 KB text file: 33,202 bytes as a single-member ZIP, 33,110 bytes as a gzip — a difference of 92 bytes, three parts in a thousand. There is no redundancy across files when there is only one file. So the rule is not "tar.gz is better", it is: the more members, the smaller and the more alike they are, the bigger the gap; one large file, no gap at all.
The cost: no index, and no way to grab one file
Solid compression is exactly why a .tar.gz cannot be opened in the middle. The compressed stream is one long chain in which byte a million depends on everything before it, so a program asked for the last of sixty files has to inflate the first fifty-nine to get there. A ZIP does the opposite: the archives built for this article carry a central directory record for every member, and a reader jumps to it, finds the offset, and inflates 193 bytes.
The same asymmetry decides what happens when an archive is damaged. Corrupt a few bytes in a ZIP and you usually lose the member they belong to; the central directory still lists the rest and a repair tool can often recover them. Corrupt a few bytes near the start of a .tar.gz and everything after the damage is unreachable, because the decompressor's state is gone. If you are writing to unreliable media, or transferring over a link that drops, that difference is not academic.
Permissions and symlinks: what this converter actually dropped
The test tree was not only sixty files. It also held a directory, one file marked executable, and a symbolic link pointing at another file. Packed by the system tools, both formats kept all of it. The .tar carried a mode of 000755 on the executable and a type flag of 2 on the link. The .zip carried 62 central-directory entries: the sixty files, the directory as 040755, the executable as 0100755, and latest.js as 0120755 — a symlink, seventeen bytes long, those bytes being the path it points at.
That last fact is worth pausing on, because the folklore says ZIP cannot hold Unix metadata. It can. The format reserves a field for exactly this, and the standard Unix zip tool fills it. What is true is that the field is optional, that the writer decides whether to fill it, and that a great many writers do not.
The converter on this page is one of them, and running it made that visible. Its TAR reader keeps only entries whose type flag says "regular file", so the directory and the symbolic link were both discarded with no message: sixty members went in, sixty came out, and two objects vanished. Its internal record of a member is a path and a block of bytes with no field for a mode, so the 000755 in the tar header has nowhere to go. Inspecting the ZIP it produced confirms it: 60 entries, all declared as coming from a DOS-style system, every permission field zero. No directory, no link, no executable bit.
For the job this page is for — a .tar.gz someone sent you, and you want its contents on a machine that will not open it — none of that matters. For repacking a release, a backup or anything with scripts in it, all of it matters, and you should repack with the system tools instead. Knowing which of those two you are doing is the whole skill.
Which one can the recipient open without installing anything
This is usually what decides it, and the honest answer has changed. ZIP has been readable in Windows Explorer since 2001 and in the macOS Archive Utility since the beginning; there has never been a machine where sending a ZIP was the wrong bet. TAR was the reverse: outside Unix you needed a third-party program, which meant asking a colleague to install software before they could read your attachment.
That gap closed. Windows 11 added native reading of .tar, .tar.gz, .tgz, .tar.bz2, .tar.xz, .tar.zst, .rar and .7z to File Explorer, announced in 2023 and shipped through the following releases. So on a current Windows 11, a .tar.gz opens on a double-click with nothing installed. The catch is everything that is not a current Windows 11: Windows 10 machines, locked-down corporate images, the web preview in a mail client, a document management system, a phone. ZIP works in all of them.
So the practical rule is asymmetric, and it is not about which format is better. If you are storing, deploying or moving files between machines you control, .tar.gz — smaller on source trees, and it keeps the metadata. If you are sending to a person, ZIP, unless you know what they run. Converting between the two takes seconds, which is what the tool on this page is for; just do the conversion in the direction that loses nothing you care about.
| Criterion | TAR alone | ZIP | TAR + gzip (.tar.gz) |
|---|---|---|---|
| Size of the test tree | 63,488 bytes — bigger than the source | 14,686 bytes | 1,809 bytes |
| Where compression happens | Nowhere — it only concatenates | Per member, window reset each time | Once, over the whole stream |
| Extract one file without reading the rest | Partly — headers are inline, but you walk them | Yes — central directory at the end of the file | No — inflate from the beginning |
| Unix permissions and symlinks | Native — mode, owner and type flag in every header | Optional — the system zip stores them, many writers do not | Native — the gzip layer changes nothing |
| Opens with nothing installed | Windows 11 and Unix; not Windows 10 | Everywhere, for twenty-five years | Windows 11 and Unix; not Windows 10 |
| Damage in the middle costs you | One member, roughly | One member; the directory still lists the rest | Everything after the damage |
Frequently asked questions
- Is a .tgz the same thing as a .tar.gz?
- Yes, byte for byte. .tgz is a contraction that exists because MS-DOS allowed only three characters after the dot, and it has outlived the reason for it. Anything that reads one reads the other. The same goes for .tbz2 and .tar.bz2, .txz and .tar.xz, .tzst and .tar.zst. The converter here sniffs the bytes rather than the extension, so it accepts any of these spellings — and it also accepts a file whose name is wrong, which is more often the real situation.
- Why is my .tar bigger than the files inside it?
- Because TAR does not compress and because it rounds. Every member costs a 512-byte header plus its own bytes padded up to a whole 512-byte block, and the archive ends with 1,024 bytes of zeroes. On the test tree that turned 11,604 bytes of source into a 63,488-byte .tar — five and a half times larger, because sixty 193-byte files each occupy a full kilobyte of header and padding. This is not a defect: it is what a format designed to be written to a tape in fixed blocks looks like. Compress it and the padding, being zeroes, all but disappears.
- Will converting a .tar.gz to ZIP make it bigger?
- Often, yes, and sometimes by a lot. The direction of the conversion undoes the thing that made the .tar.gz small: the archive is unpacked into individual files, then each file is compressed on its own. On the sixty-file test tree the output ZIP was 14,490 bytes against an input of 1,809 — eight times larger for the same contents. If the archive holds a few large, already-compressed files (photographs, video, a database dump that was gzipped before it went in), the difference will be nearly nothing. If it holds a source tree, expect the number to jump.
- Does the compression level in the tool do anything?
- Between "none" and the other two, yes: storing rather than compressing gave 18,328 bytes against 14,490 on the test tree. Between "normal" and "maximum", on that same tree, no — the two produced identical files, and so did every level in between. On a single 92 KB document the highest setting saved 39 bytes over the default. Compression levels earn their keep on large, text-heavy members; on a pile of small ones they are a dial connected to nothing. Use "none" when the contents are already compressed and you only want a container, and leave it on normal otherwise.
- Can I keep file permissions when I convert TAR to ZIP here?
- No, and the tool does not say so. Its internal record of an archive member is a path and a block of bytes, with no field for a mode, so the permissions in the tar headers are read past and never written out; the ZIP it produced for this article had a zero permission field on all sixty members. Symbolic links and directory entries are dropped for the same reason — only members flagged as ordinary files are kept. If any of that matters, repack with tar and zip on the command line, where both formats carry the metadata natively. If you are just trying to read someone's archive on a machine that will not open it, none of this affects you.
Articles you may find interesting
All guides →Related tools
This describes what these converters do today, checked by running their own code on real files, not what they ought to do. Format behaviour depends on the version of Excel, LibreOffice or Numbers that wrote the file and on the one that will open it, so keep the original until you have opened the converted copy and looked at it. Anything that matters — a workbook with macros, a model full of formulas, a file someone else will rely on — should be checked cell by cell after conversion rather than trusted because a progress bar finished.
Sources
Spotted a mistake in this article?