What Is a .TAR.7Z File? (Why Tar Still Gets Wrapped Inside 7-Zip)
The real, documented reason people wrap a tar archive in 7-Zip's own LZMA2 compression instead of just building a plain .7z — and what actually happens to Unix metadata either way.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
What a .TAR.7Z File Actually Is and Why Two Formats Get Stacked
A .tar.7z file is a tar archive — files bundled using 512-byte header blocks, a Unix format standardized as USTAR in POSIX.1-1988 — that has then been compressed using 7-Zip's own .7z container, released in 1999 by Igor Pavlov and built around the LZMA and LZMA2 compression algorithms. This is an unusual combination compared with .tar.gz or .tar.bz2, because unlike gzip or bzip2, 7-Zip's own .7z format can already hold multiple files directly in one archive without needing tar to bundle them first — 7z has its own internal file listing and doesn't require a separate bundling step the way gzip and bzip2, which only ever compress a single stream, genuinely do.
So a .tar.7z file specifically means someone chose to bundle with tar anyway before compressing with 7-Zip, rather than just pointing 7-Zip at the original folder directly. That choice is deliberate, not redundant, and it comes down to one specific, well-documented gap in what the plain .7z container actually stores.
This convention shows up specifically in Unix and Linux backup and archiving workflows, since that's the environment where the metadata tar preserves — ownership, permission bits, symlinks — actually exists and matters in the first place. On a system where files never carry meaningful Unix permissions or ownership to begin with, there's little reason to bother wrapping tar around anything before compressing it with 7-Zip directly.
The Real Reason Anyone Chains TAR Into 7-Zip's Own Container
The 7z archive format does not store standard Unix file permissions, ownership (UID/GID), or extended file attributes the way tar's own header does natively. Symlinks fare no better by default: 7-Zip only preserves them when the -snl flag is used explicitly, which isn't the default archiving behavior in either the command-line or graphical version of the tool. Practically, that means archiving a Linux directory straight into a plain .7z and then extracting it elsewhere can restore the files themselves correctly while silently losing their original owner, group, and permission bits, and turning symbolic links into plain regular files unless that extra flag was set.
Wrapping the same directory in tar first sidesteps this cleanly, since tar's own header format captures Unix permissions, ownership, and symlink targets as core fields before 7-Zip ever sees the data — at that point, 7-Zip is just compressing an already-complete, metadata-preserving byte stream, the same way it would compress any other single file. The documented command-line approach for this is piping tar's output directly into 7-Zip's archiver without writing an intermediate .tar file to disk at all, for example tar cf - directory | 7za a -si directory.tar.7z, producing the combined format in one step.
What Wrapping TAR Inside 7Z Gains and What It Costs
- Gain — full Unix permission and ownership preservation: tar's header captures UID, GID, and permission-mode fields that 7z's own container has no standard place to store at all.
- Gain — genuine symlink preservation without extra flags: tar records a symlink's target path directly in its header type field, avoiding 7-Zip's non-default
-snlrequirement entirely. - Gain — LZMA2's wider compression reach: LZMA2 supports a dictionary size that can scale into the gigabytes, letting it find repetition across a much larger span of the tar stream than gzip's fixed 32 KB window or bzip2's 900 KB blocks.
- Gain — genuine multithreaded compression: 7-Zip applies full multithreading specifically to LZMA2, unlike the older LZMA method, which is limited to two threads regardless of how many CPU cores are available.
- Lose — a second unpacking step on extraction: recovering the original files means removing the 7z compression layer first and then unpacking the tar layer underneath, rather than reaching the files in one step.
- Lose — some redundancy with 7z's own multi-file capability: since plain .7z can already store many files directly, tar-then-7z only pays off specifically when Unix metadata preservation actually matters for the content involved.
Which Tools Actually Build and Open a TAR.7Z Archive
7-Zip itself, available for Windows with p7zip as its command-line counterpart on Linux and macOS, both creates and extracts TAR.7Z archives, though building one that preserves Unix metadata specifically requires the tar-then-pipe approach described above rather than simply pointing 7-Zip's archiver at a folder of files directly. GNU tar and BSD tar both handle the tar-bundling half of the process natively on Linux and macOS, since both ship by default on those systems, with the 7-Zip or p7zip compression pass run separately afterward.
Windows 11's 24H2 update added native File Explorer extraction support for .7z and .tar files individually, built on the open-source libarchive project, but that native handling covers each format independently — extracting a .tar.7z through File Explorer alone still means separately removing the 7z layer and then the tar layer, rather than the whole combination being recognized and unpacked as one single guided action the way a plain .zip is.
PeaZip, a free graphical archiver available for Windows and Linux, also reads and writes both layers of this combination, and like 7-Zip, generally handles the tar bundling and 7z compression as two distinct configurable steps rather than a single pre-packaged "tar.7z" archive type in its main creation dialog.
macOS's built-in Archive Utility does not create this combination directly through its graphical double-click compression shortcut, since that shortcut only builds plain ZIP archives; producing a .tar.7z on macOS in practice means using the Terminal to run tar and pipe its output into a 7-Zip build such as p7zip, the same command-line approach used on Linux.
Real Problems Reported Extracting TAR Archives Through 7-Zip
A documented bug reported against 7-Zip's own File Manager describes tar archives extracting with missing files, or files showing up with a size of zero, in situations where the command-line tar tool on Unix extracts the exact same archive correctly — a real, tool-specific gap in 7-Zip's own tar-reading logic rather than any flaw in the tar format itself, and a genuine reason to verify extraction results specifically when 7-Zip is the tool unpacking the tar layer of a .tar.7z file.
A second, more serious documented issue involves a path traversal vulnerability in how 7-Zip processed Unix-style symbolic links during extraction, affecting versions 21.02 through 24.09, where absolute symlink paths inside an archive could be treated as relative and used to write files outside the intended extraction folder — fixed in version 25.00 and later. This is a concrete, security-relevant reason to keep 7-Zip current specifically when extracting tar-based archives containing symlinks, exactly the kind of content a .tar.7z file is built to carry faithfully in the first place.
A third recurring complaint involves someone expecting a single "Extract Here" action in a graphical tool to fully unpack both compression layers of a .tar.7z at once, then finding only the 7z layer removed, leaving a plain .tar file still needing a second extraction pass — a genuine two-step reality of this exact format combination, not a malfunction in the tool doing the first pass.
TAR.7Z Measured Against Plain 7Z and Against TAR.GZ
| Feature | TAR.7Z | Plain 7Z | TAR.GZ |
|---|---|---|---|
| Compression algorithm | LZMA2 (over a tar stream) | LZMA2 | Gzip (DEFLATE) |
| Unix permissions/ownership | Preserved via tar header | Not stored by default | Preserved via tar header |
| Symlink preservation | Native, via tar | Only with -snl flag | Native, via tar |
| Compression dictionary | Up to several GB (LZMA2) | Up to several GB (LZMA2) | 32 KB (DEFLATE) |
| Multithreaded compression | Yes, LZMA2 | Yes, LZMA2 | Only via pigz add-on |
| Extraction steps needed | Two (7z, then tar) | One | Two (gzip, then tar) |
Common Questions About the TAR.7Z Archive Combination
Why would anyone wrap a tar archive in 7z when 7z can already hold multiple files?
Because the plain 7z format doesn't store Unix permissions, ownership, or symlinks by default, while tar's own header does. Wrapping tar inside 7z keeps that metadata intact while still getting LZMA2's strong compression.
Does 7-Zip preserve symbolic links automatically?
No, not by default. 7-Zip only preserves symlinks when the -snl command-line flag is used explicitly; without it, symlinks can be converted into regular files during archiving.
Is LZMA2 different from the original LZMA algorithm?
Yes. LZMA2 is a refinement of LZMA specifically built for better multithreaded performance — 7-Zip applies full multithreading to LZMA2, while the older LZMA method is limited to two threads.
Can I open a .tar.7z file with just one extraction step?
Generally no. Extracting a .tar.7z means removing the 7z compression layer first, then unpacking the resulting plain .tar file separately, since the two layers are handled by different mechanisms even when the same tool does both steps.
Is it safe to extract a .tar.7z containing symlinks with any version of 7-Zip?
Not older versions specifically. 7-Zip versions 21.02 through 24.09 had a documented path traversal vulnerability involving symlink handling during extraction, fixed in version 25.00 and later, so keeping the tool updated matters especially for archives built around tar's native symlink support.