TAR file format
A POSIX tape archive — an uncompressed sequential-file container.
- MIME type
- application/x-tar
- Extensions
- .tar
- Category
- Archives & compression
Magic-number signature
| 0x00000101 | 7573746172 | ustar | 'ustar' marker in the first header |
About the TAR format
TAR is a stream of 512-byte blocks: one header block per member, then the member's bytes padded up to the next 512-byte boundary, repeated until two consecutive all-zero blocks end the archive. There is no compression, no index and no directory — which is why a .tar is almost always wrapped in gzip, xz or zstd, and why listing a .tar.gz means decompressing the whole thing. Every numeric field in the header is written as ASCII octal digits rather than binary, a decision from 1979 that makes a tar header readable in a hex dump with no tooling at all.
Header layout, byte by byte
| Offset | Length | Field | Meaning |
|---|---|---|---|
| 0 | 100 | name | The member's path as NUL-padded ASCII, relative and with forward slashes. A directory is stored with a trailing slash. Paths longer than 100 bytes have to be split across the prefix field at offset 345, or escaped entirely by a GNU 'L' or pax 'x' extension record. |
| 100 | 8 | mode | Permission bits as six octal digits followed by a space and a NUL, for example '000644\0' with a space before the terminator. Only the low twelve bits are portable; setuid and sticky survive but Linux capabilities and ACLs do not. |
| 108 | 8 | uid | Owner's numeric user id in octal ASCII. Ids above 2097151 do not fit in seven octal digits, which is why the GNU and pax variants exist at all. The matching name is stored separately at offset 265. |
| 116 | 8 | gid | Owning group's numeric id, same encoding, same overflow limit. Extracting as a non-root user silently ignores both this and the uid field. |
| 124 | 12 | size | Member size in bytes as eleven octal digits and a space or NUL — so 8 GiB minus one is the ceiling for a plain ustar member. This is the field the reader adds to the current position, rounded up to a multiple of 512, to find the next header. A directory entry stores zero. |
| 136 | 12 | mtime | Modification time as octal seconds since 1970. There is exactly one timestamp per member: no creation time, no access time, one-second resolution and no time zone. Sub-second times need a pax extended header. |
| 148 | 8 | chksum | Unsigned sum of all 512 header bytes with this field itself treated as eight spaces, written as six octal digits, a NUL and a space. It is the only integrity check tar has — no CRC, no hash — and it covers the header alone, never the file data. |
| 156 | 1 | typeflag | '0' or NUL for a regular file, '1' hard link, '2' symbolic link, '3' and '4' character and block devices, '5' directory, '6' FIFO, '7' contiguous file. 'x' and 'g' introduce pax extended headers; 'L' and 'K' are GNU's long-name and long-link records. |
| 157 | 100 | linkname | Target path for typeflag '1' and '2', NUL-padded, empty otherwise. A symlink target that escapes the extraction root is the classic tar path-traversal vector, so this run deserves a look on any untrusted archive. |
| 257 | 6 | magic | 'ustar' followed by a NUL in POSIX ustar, or 'ustar' followed by two spaces in GNU tar's older variant. This is the only fixed-position signature the format has, and it sits 257 bytes into the file, which is why a tool that only reads the first sixteen bytes cannot identify a tar at all. |
| 263 | 2 | version | '00' for POSIX ustar. GNU's variant leaves the two spaces from the magic field running through here instead, so bytes 257 to 264 read 'ustar \0' as one unit — the cheapest way to tell the two dialects apart. |
| 265 | 32 | uname | Owner's login name as NUL-terminated ASCII. Extraction prefers this over the numeric uid when the name resolves on the target system, which is how a tar written by uid 501 lands correctly on a machine where the same person is uid 1000. |
| 297 | 32 | gname | Owning group's name, same rules. On macOS-written archives this commonly reads 'staff' or 'wheel', on Linux the user's own name. |
| 329 | 8 | devmajor | Major device number in octal, meaningful only for typeflag '3' and '4'. Zero-filled for every ordinary file. |
| 337 | 8 | devminor | Minor device number, same encoding and same restriction. Together with devmajor this is how a tar can carry /dev nodes, which no other common archive format does. |
| 345 | 155 | prefix | Leading portion of a long path. The reader joins prefix, a slash and the name field to rebuild the whole path, which raises the ceiling to 255 bytes — but only when the path happens to have a slash in the right place, which is why GNU and pax long-name records exist. |
| 500 | 12 | padding | Zero bytes rounding the header out to exactly 512. Member data starts at offset 512 and is itself padded with zeros to the next 512-byte boundary, so the second header sits at a predictable multiple of 512. |
| -1024 | 1024 | End-of-archive marker | Two consecutive 512-byte blocks of zeros terminate the archive. Many writers pad further, to a 10 KiB or 20 KiB block factor, so the marker is often followed by more zeros — but if the last 1024 bytes are not all zero the archive was cut short. |
Telling it apart from its neighbours
| Easily confused with | How to tell |
|---|---|
| GZIP | A .tar.gz is a tar inside a gzip stream, so offset 0 reads 1F 8B 08 and there is no 'ustar' anywhere until you decompress. The two are so routinely confused that .tgz exists as a single extension for the pair. Decompress one gzip layer and offset 257 of the result should read 'ustar'; if it does not, you had a gzipped something else. |
| ZIP | Both are 'a folder in a file' and neither can be told from the other by extension habit alone, but the bytes are unambiguous: 50 4B 03 04 at offset 0 versus 'ustar' at offset 257. The practical difference is that a ZIP has a central directory and supports random access, while a tar must be read from the front — so listing a large .tar.gz costs a full decompression and listing a .zip costs a seek. |
| cpio | The other Unix streaming archiver, and the one inside every RPM and initramfs. The portable ASCII cpio format opens each member with '070701' or '070707' in ASCII at the member boundary rather than at a fixed offset 257, and it has no 512-byte block alignment at all. |
| GNU tar/pax | All three write 'ustar' at 257 and differ only afterwards. POSIX ustar has 'ustar\0' then '00'; GNU tar has 'ustar' then two spaces running into the version field; pax is a ustar archive that additionally carries typeflag 'x' or 'g' member headers holding key=value records for long names, high uids and sub-second times. A reader that ignores those records silently drops the metadata rather than failing. |
How these files break
- Truncated transfer. Because tar is a forward-chained stream, everything before the cut extracts perfectly and only the final member is lost — GNU tar will even report 'Unexpected EOF' and keep what it already wrote. The check is the last 1024 bytes: two all-zero blocks mean the archive ended on purpose, anything else means it was cut.
- The gzip layer is damaged rather than the tar. A single flipped byte inside the deflate stream destroys everything after it, so a .tar.gz fails at the point of damage and the intact tar underneath is unreachable. This is the practical argument for .tar.zst or for keeping large archives uncompressed: the tar itself degrades gracefully and the compression wrapper does not.
- Header checksum mismatch at offset 148. Tar's only integrity check covers the 512-byte header, so a flipped byte in a name or a size shows up immediately while a flipped byte in the file data does not show up at all. An archive can extract with every checksum passing and still hand you a corrupt file.
- Octal overflow. A file over 8 GiB, or a uid above 2097151, will not fit the octal fields at offsets 124 and 108. Old writers wrapped or wrote garbage; GNU tar sets the high bit of the first byte and switches to base-256 binary, which a strict ustar reader rejects outright. A size field whose first byte is 0x80 is this, not corruption.
- Text-mode transfer. Line-ending translation inside member data leaves every header and every offset intact, so the archive lists correctly and extracts without a single warning — tar has no data checksum to notice. The damage surfaces later, when a binary extracted from the archive refuses to run.
Where the format stands today
TAR is the default archive format on Unix and shows no sign of moving, for one reason: it preserves the things a Unix filesystem cares about. Permissions, ownership, symlinks, hard links, device nodes and sparse files all survive a tar round trip, and none of them survive a ZIP cleanly. That is why source releases, container image layers, backups and every package format built on top of one are tarballs. Its weaknesses are structural and unfixable: no index, so listing means reading everything; no data checksum, so silent corruption is invisible; and compression bolted on outside rather than per member, so one damaged byte in the gzip layer costs the whole archive. Where ZIP wins is random access — pulling one file out of a 4 GB .tar.gz means decompressing up to it — which is exactly why document and application containers chose ZIP instead. The modern move is not away from tar but to a better wrapper: .tar.zst compresses and decompresses several times faster than .tar.gz at a better ratio, and .tar.xz remains the choice where size matters more than time.
Open TAR files on this site
Every one of these runs in your browser — the file never leaves your machine.
Related formats
Formats that are easy to confuse with TAR — compare their leading bytes.