How to Convert TZ2 to TAR Online
- Upload Your TZ2 File: Drag and drop or click "+ Add Files" to load one or more
.tz2archives. Batch is supported — drop several.tz2files together and convert them in one pass. Files stay on our servers and are not stored on a permanent server. - Pick Combine Mode: Under "Combine?" choose Individual Archives (the default for archive input) to produce one
.tarper input.tz2— each input is decompressed and the inner tar stream is written out as-is. Pick Single Archive instead if you want to unpack every uploaded.tz2and re-pack their combined contents into one merged.tar. - Review the Output Extension: The output is written with
.tar. Unlike a rename-only conversion between bzip2 aliases (.tz2→.tb2), this conversion strips the bzip2 compression layer entirely — the resulting.tarcontains the same files but is the raw uncompressed tarball, typically 3–10× larger than the input depending on payload entropy. - Convert and Download: Click Convert. No account, no watermark, no email. Each archive's contents — filenames, directory structure, POSIX modes, symlinks, hard links, and modification times — are preserved exactly as they were inside the original
.tz2.
Why Convert TZ2 to TAR?
.tz2 is one of several short aliases for a tar archive compressed with bzip2 (canonical name .tar.bz2). Converting to plain .tar removes the bzip2 layer, leaving the underlying POSIX tarball. The output is much larger, but it's also faster to read sequentially, supports random per-file access when paired with an external index, and is the form most build pipelines actually consume after a one-time decompress step. Typical scenarios:
- Re-compressing with a different algorithm — Decompress
.tz2to.tarfirst, then re-pack with gzip, xz, or zstd. Going.tz2→.tar.xzdirectly via a re-pipe usually saves a temp file but produces the same bytes; the explicit.tarstep is handy when you want to inspect, edit, or split the tarball between recompression passes. - Random per-file access via tar indexes — Bzip2 is a streaming codec with no built-in index, so reading file
Nfrom a.tz2requires decompressing everything before it. A plain.tarlets tools liketarindexerorratarmountbuild a sidecar offset map for O(1) extraction of individual entries — useful for huge ML or genomics tarballs. - Build pipelines that expect raw tar — Docker
ADD/COPYaccepts compressed and plain tar, but some CI cache layers, Buildroot fragments, and Yocto recipes hard-code the.tarextension or assume no compression layer. Decompressing once and committing the.tarsimplifies these. - Faster repeated reads — Bzip2 decompresses at roughly 25 MB/s on a single core (vs. ~96 MB/s for gzip and ~53 MB/s for xz). For archives you extract dozens of times a day in tests or builds, the one-time disk cost of an uncompressed
.tarsaves real CPU time. - Streaming over fast local networks — On a 1 Gbps LAN or NVMe-to-NVMe copy, bzip2's CPU cost can exceed the bandwidth savings; sending a 2 GB
.tarstraight over the wire often finishes before a.tz2of the same payload finishes decompressing on the receiver. - Combining multiple
.tz2files — Switch the Combine mode to Single Archive to unpack several.tz2files and merge their contents into one.tar. When two inputs contain the same path, the later one wins — the same conventiontaritself uses.
Need a different output instead of plain tar? Try TZ2 to tar.gz for a much faster decompress, TZ2 to tar.xz for tighter compression, or TZ2 to ZIP for Windows-native compatibility. To unpack a .tz2 directly into files instead of an uncompressed tarball, use Extract TZ2. To go the other direction, TAR to tar.bz2 re-applies bzip2 compression.
TZ2 (tar.bz2) vs TAR — What Changes
| Property | TZ2 (.tar.bz2) |
TAR (uncompressed) |
|---|---|---|
| Inner format | POSIX tar (ustar / pax) | POSIX tar (ustar / pax) — identical |
| Compression layer | bzip2 (BWT + MTF + Huffman, 100–900 KB blocks) | none |
| Typical text payload size | ~10–20% of raw | 100% (uncompressed) |
| Magic bytes at offset 0 | BZh |
ustar at offset 257 |
| Decompress speed (single core) | ~25 MB/s | n/a — read directly |
Streaming append (tar -rf) |
No (bzip2 stream not appendable) | Yes |
| Random per-file access | No (sequential decompress required) | With external index (tarindexer, ratarmount) |
| Preserves Unix modes / symlinks | Yes (via inner tar) | Yes (via inner tar) |
| Built-in on Windows 11 | Yes (libarchive in File Explorer, since 2023) | Yes (libarchive in File Explorer, since 2023) |
tar -xf autodetects |
Yes (bzip2 magic) | Yes (no compression) |
tar.bz2 vs Related Archive Compressions
Numbers below are from rootusers.com's benchmark on a 580 MB mixed-content file at each tool's default level — representative, not absolute. Real-world ratios vary with payload type.
| Format | Compress speed | Decompress speed | Output size (% of raw) | When to pick |
|---|---|---|---|---|
.tar (no compression) |
n/a | n/a (read direct) | 100% | Fast local copies, random access via index, intermediate step for re-compression |
.tar.gz / .tgz |
~19 MB/s | ~96 MB/s | ~21% | Frequently read archives, build artifacts, default for source releases |
.tar.bz2 / .tz2 / .tb2 |
~7 MB/s | ~25 MB/s | ~17% | One-time downloads where size matters more than CPU |
.tar.xz / .txz |
~1.5 MB/s | ~53 MB/s | ~14% | Distribution tarballs (compress once, download many times) — kernel, Arch packages |
Bzip2 sits between gzip and xz on both axes: better compression than gzip, faster than xz, but slower to decompress than either. That's why most modern Linux distros have migrated source tarballs from .tar.bz2 to .tar.xz — the decompress speed difference doesn't matter when you only extract once, and the size win is real.
Frequently Asked Questions
Will the TAR be larger than the TZ2?
Yes — usually 3–10× larger, depending on payload type. The bzip2 layer is removed, so all the compression savings disappear. Text-heavy payloads (source code, logs, configs) compress to roughly 10–17% of raw with bzip2, so removing it grows the file 6–10×. Payloads that are already compressed (JPEG, MP4, MP3, PDFs with embedded JPEG) barely compress at all, so the .tar may only be 5–15% larger than the .tz2.
Why not just rename .tz2 to .tar and call it done?
Because they're not the same format. .tz2 is a bzip2-compressed tar; the bytes start with BZh (bzip2 magic). .tar is the raw uncompressed POSIX archive; the bytes start with the first tar header block and ustar appears at offset 257. Renaming a .tz2 to .tar doesn't strip the compression — most tools will still recognise the bzip2 magic and decompress on the fly, but anything that pattern-matches on the extension and skips magic-byte detection will read garbage. This converter actually decompresses the bzip2 layer.
Can I extract the resulting .tar on Windows without installing anything?
Yes on Windows 11, where File Explorer added libarchive-based support for .tar, .tar.gz, .tar.bz2, and similar formats in the 2023 update — right-click → "Extract All" works directly. Windows 10 (1803 and later) ships a bundled tar.exe you can call from PowerShell or cmd.exe: tar -xf archive.tar. On older Windows, 7-Zip, WinRAR, and PeaZip all handle plain tar.
Does converting preserve POSIX permissions, symlinks, and timestamps?
Yes. The conversion only touches the outer compression layer — the inner tar stream is written out byte-for-byte (in Individual Archives mode) or recomposed from the unpacked entries (in Single Archive mode). File modes, owner/group IDs, symbolic links, hard links, and mtime are all preserved. If the original .tz2 was built on Windows or by a tool that didn't capture POSIX bits, the converter can't restore information that wasn't there — but it won't strip anything either.
Is the .tar decompression actually faster?
For sequential reads, yes — there's no decompression at all, so you're limited by disk and tar's own parsing. Bzip2 decompresses at roughly 25 MB/s on a single core (rootusers.com benchmark, 580 MB file at -9), while reading a .tar from an NVMe SSD easily hits 1–3 GB/s. For random per-file access, the .tar only wins if you maintain an external offset index — without one, tar -xf archive.tar somefile.txt still scans linearly from the start, just faster than the bzip2 path because there's no decompress overhead.
Can I make a .tar appendable so I can add files later?
Yes — that's one of the main reasons to keep an uncompressed .tar. tar -rf archive.tar newfile.txt appends to a plain tarball; tar -uf archive.tar newfile.txt updates only changed files. Neither works on a .tar.bz2 because bzip2 is a streaming codec — appending would require decompressing, re-tarring, and re-compressing the whole thing. Many backup and snapshot workflows keep the live archive as .tar and only compress when archiving to cold storage.
Will the converter re-compress at all, or is the output truly uncompressed?
Truly uncompressed in Individual Archives mode — the converter reads the bzip2 stream, decompresses it, and writes the inner tar bytes directly to disk without re-applying any compression. The output .tar is exactly the byte stream that bzip2 -d or bunzip2 would produce on the same input. In Single Archive mode, the converter unpacks each input, merges the entries, and re-tars the combined tree — still without any compression layer.
How do I extract or list contents of the resulting .tar?
Run tar -xf archive.tar to extract or tar -tf archive.tar to list contents. The -x flag means extract; -t means list; -f specifies the file. No -j flag is needed because there's no bzip2 layer. To extract a specific file: tar -xf archive.tar path/to/file.txt. To extract into a target directory: tar -xf archive.tar -C /destination/path.
Is there a file size limit on this converter?
xconvert processes archives on our servers without uploading to a permanent server, and there is no hard cap published for TZ2-to-TAR conversions. file size limits depend on your upload bandwidth and our server-imposed quota and the size of the decompressed output. In Individual Archives mode the converter streams the decompression, so even multi-gigabyte archives are feasible on most modern desktops. Single Archive mode unpacks each input fully before re-tarring, which takes more memory; expect noticeable processing time on archives totalling 1 GB+ because of bzip2's CPU cost on decompression.