TAR Inspector
Read the table of contents of a .tar archive.
Overview
The TAR inspector reads the table of contents of a .tar archive — every file and directory entry, with its name, size, permissions, modification time, and entry type. It works on plain TAR as well as the common compressed variants once decompressed (.tar.gz, .tar.bz2, .tar.xz).
Sysadmins auditing backup archives, developers checking a release tarball, and security teams inspecting a quarantined archive reach for this when a directory listing is enough and full extraction is overkill. Long-tail searches that lead here include "list contents of tar file online", "view tar table of contents", and "inspect .tar without extracting".
How it works
A TAR archive is a stream of 512-byte blocks defined by the POSIX ustar specification (and the GNU and PAX extensions). Each entry begins with a 512-byte header containing the file name (in a 100-byte field, extended via prefix or PAX for longer paths), a numeric mode in octal, owner UID/GID, file size in octal, modification time as a Unix timestamp, a checksum, and a type flag (0 regular file, 5 directory, 2 symlink, L GNU long name, x PAX extended header).
The inspector walks the archive header by header, skipping past the data blocks of each entry without reading them, and emits a structured table of contents. Long file names stored via PAX or GNU LongLink extensions are reconstructed so the listing shows the real path. Symlinks display both the link name and the target.
Examples
- List every file in a 2 GB release tarball without paying the extraction cost.
- Spot oversized files that bloat a backup archive.
- Confirm a directory tree is laid out as expected before deploying.
- Check that permissions and ownership on archived files match expectations.
FAQ
Does it extract files?
No. Only headers are read; data blocks are skipped. Use a dedicated extractor when you need the actual contents.
What about compressed tarballs (.tar.gz, .tar.bz2)?
The inspector reads uncompressed TAR streams. For .tar.gz, decompress first (or feed the gzip output through). The gzip-header decoder is a useful complement here.
Does it support sparse files?
GNU sparse and PAX sparse formats are recognised, and the inspector reports the logical file size correctly.
Why are some filenames showing as ././@LongLink?
That is the GNU extension's marker entry for a long name that follows it. The inspector consumes those markers and uses them to label the next real entry, so the listing should show the proper path rather than the marker.
Can it verify file checksums?
The header checksum is verified to confirm header integrity, but file contents are not read or hashed. Use a dedicated hashing step on extracted contents for content-level integrity.