What is a TAR file?

TAR is a container: a wrapper that holds streams encoded by something else. It is used for archiving and moving data between programs.

The extension is .tar, and the full name is Tape Archive. Both matter less than what the file can hold, which is what the rest of this page is about.

It dates from 1979. The specification is POSIX.1-2001 ustar.

A format that has been readable for that long is a format worth trusting with something you want back in ten years.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

TAR stores its content exactly. Saving it again changes nothing, so it can be opened, edited and re-saved as often as you like without accumulating damage — which is what makes it a working format rather than a delivery one.

TAR stores a directory: names, folders and the structure between them. That is what lets it stand in for a folder in an email attachment.

TAR carries a checksum, so a damaged file is detected rather than silently mis-read.

A checksum will not repair anything. It tells you the file is wrong, which is the difference between finding out now and finding out from whoever you sent it to.

tar, 7-Zip and Keka read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

TAR is meant to be opened and changed. Keep the file in this format for as long as the work is going on, and export from it whenever a finished copy is needed.

The recurring complaints: the files are large for what they contain.

None of these is a reason to avoid the format. They are the things worth knowing before you are surprised by one, which is a different claim and a more useful one.

TAR bundles files into one file. It does not make them smaller. The name is short for tape archive, and it was designed in 1979 to write a directory tree onto a magnetic tape in a single continuous stream — a job where compression was somebody else’s problem and often the tape drive’s.

Nearly every confusing thing about TAR follows from this. A `.tar` of a folder is very slightly larger than the folder was, because it adds a header before each file and pads everything to a fixed block size. If you were expecting a smaller file, nothing has gone wrong; you have used the tool that bundles rather than the tool that shrinks.

Because two separate programs ran. `archive.tar.gz` was bundled by tar and then the single resulting file was compressed by gzip. `.tar.bz2` used bzip2, `.tar.xz` used xz, `.tar.zst` used zstd. The chain reads right to left: unwrap the compression, then unwrap the bundle.

The short forms `.tgz` and `.txz` mean the same thing and exist because some filesystems once objected to more than one dot. This composition of small tools doing one job each is deliberate rather than accidental, and it is also why TAR outlived the tape drives it was written for.

This ordering is the reason `.tar.gz` frequently beats ZIP on the same content. ZIP compresses each file separately, so a thousand similar text files are each squeezed in isolation. Tar-then-gzip presents the compressor with one continuous stream, letting it find repetition that spans file boundaries.

On source code, log files or anything with many similar small files the difference is substantial. On a folder of photographs it is close to nothing, because JPEGs are already compressed and there is no cross-file repetition to find. The advantage is real and it is specific to a kind of content.

That same continuous stream is why extracting a single file from a large `.tar.gz` is slow. There is no index, and the compression means byte positions cannot be calculated in advance, so the only way to reach a file near the end is to decompress everything before it.

ZIP made the opposite trade. Its index sits at the end of the archive and each file is compressed independently, so any single item can be extracted immediately. That is the whole comparison: TAR for archives read from the beginning, ZIP for archives dipped into.

Unix file permissions, ownership, symbolic links and hard links, plus timestamps with more precision than ZIP records. This is why software is distributed as `.tar.gz` rather than ZIP: unpacking must produce a tree where the executable is still executable and the links still point where they did.

On Windows most of that has nowhere to go and is quietly discarded. Nothing breaks, but a `.tar.gz` unpacked on Windows and repacked has lost the permissions it existed to carry — which matters if the archive is going back to a server.

gzip is fast, universal and the safe default; it is what almost everything produces and everything reads. xz compresses noticeably harder and takes considerably longer, which suits something written once and downloaded many times. bzip2 sits between them and is largely a legacy choice now. zstd is the modern entrant and compresses close to xz at speeds near gzip.

For a file being handed to someone else, `.tar.gz` remains the right answer, because the ceiling is what the recipient can open rather than what compresses best. The others are worth choosing when you know the other end.

The original design fixed file names at 100 characters and had no room for large files or long paths. Two extensions solved that independently — GNU tar’s and the POSIX pax format — and they solved it differently, so an archive written by one can confuse a strict reader expecting the other.

In practice modern tools read all of them and this rarely surfaces. Where it does, the symptom is distinctive: truncated file names, or an error about a path being too long, on an archive that is otherwise fine.

Source code releases, Linux and macOS software distribution, Docker image layers, server backups, and the export files that hosting control panels and databases produce. If you have downloaded something to run on a server, it very probably arrived this way.

It also turns up on Windows more than it used to. Windows has unpacked `.tar.gz` natively since 2023 and the built-in tar command has been there since 2018, so the era of needing a third-party tool just to open one has largely passed.

Convert when the archive is going to a person rather than a machine — a colleague on Windows, a web upload form, an email attachment. ZIP is the format every operating system opens without thought, and sending anything else is quietly asking the recipient to solve a problem.

Do not convert when the archive is going back to a Unix system. Repacking as ZIP discards the permissions, ownership and symbolic links the format existed to carry, and the extracted result may not work at all. For a server backup or a source release, `.tar.gz` is not an obstacle to route around; it is the reason the archive functions.