The tar.exe that ships in C:\Windows\System32 is libarchive, not GNU tar. That has two consequences worth knowing: it extracts formats you would not expect, and it fails at one of them in a way that returns exit code 0.
Measured on Windows 11 25H2, build 26200.9457.
It reads RAR and 7z
No install, no Store extension:
tar -tf archive.rar # list without extracting
tar -xf archive.rar # extract here
tar -xf archive.7z -C .\unpacked
A 1,731-byte RAR listed its entry and extracted to 4,585 bytes. A 909KB 7z extracted all 29 files. Both returned exit code 0.
The RAR tested carried the signature 52 61 72 21 1A 07 00 — RAR4. RAR5, which current WinRAR writes by default, was not tested here; I had no RAR5 sample. That is a gap in the measurement, not a known failure. tar -tf on your own file answers it in a second.
This is also why the "you need WinRAR" advice is mostly obsolete on Windows 11: the shell has had native RAR/7z handling since 23H2. You can see it in the registry — .rar lists ArchiveFolder among its handlers. On my machine the default was an installed archiver that had claimed the association years ago, which is the usual reason nobody notices.
Now the part that cost me time
Ask it to create a RAR:
tar -a -cf out.rar -C .\folder .
echo $LASTEXITCODE # 0
Exit code 0. A file appears. It is not a RAR.
source folder 5,806,287 bytes
out.rar 5,837,312 bytes <- larger than the input
Byte 257 of out.rar reads ustar. libarchive cannot write the RAR format — it is proprietary — so -a (auto-detect by extension) fell through to an uncompressed tar and used the name you asked for. No warning, no non-zero exit, and the only visible symptom is that your "compressed" archive grew.
If a build script does this, the artifact ships and fails at whoever tries to open it with a real RAR tool.
What it does write correctly
Verified by signature, not by extension:
| Command | First bytes | Actual format | Size |
|---|---|---|---|
tar -a -cf out.7z |
37 7A BC AF 27 1C |
7z | 798,214 |
tar -a -cf out.zip |
50 4B 03 04 |
zip | 1,798,875 |
tar -czf out.tar.gz |
1F 8B |
gzip | 1,788,453 |
tar -a -cf out.rar |
2E 2F 00 00 + ustar @257 |
plain tar | 5,837,312 |
Same 5,806,287-byte source for all four.
Two things stand out. 7z came out 2.25x smaller than zip — 13.7% of the source versus 31.0%. And tar.gz landed within 1% of zip, which I did not expect; the deflate stream is doing nearly all the work in both, and the container overhead barely registers at this size.
Practical notes
Check the signature, not the extension, when a script produces an archive. Two bytes is enough for zip and gzip, six for 7z, and ustar at offset 257 catches a tar wearing someone else's name.
-a picks the format from the filename. That is convenient until the requested format is unwritable, at which point it degrades silently. Being explicit (-czf for tar.gz) removes the guessing.
Passwords are out of scope. There is no flag to supply one, so encrypted archives need a real archiver. Creating RAR and handling encrypted archives are the two jobs that still justify installing something — extraction is not one of them.
The version for people who just want the file open, with the Explorer route: https://www.coding-now.com/en/guides/open-rar-7z-windows?utm_source=devto
If anyone has a RAR5 sample handy, I would like to know whether tar -tf lists it on 25H2 — that is the one row of my table I could not fill in.
