Initializing... drag & drop files here
Supports: TB2
backup.tb2 becomes backup.tar. Rename inline before conversion if you need a different output name.TB2 is shorthand for a tar archive compressed with bzip2 — the same payload as .tar.bz2, just collapsed into a single-extension filename. Converting it to plain TAR keeps the file layout, permissions, ownership, and symlinks identical while removing the bzip2 wrapper. The result is a larger but instantly readable archive that every Unix utility, container builder, and backup tool can stream without invoking a decompressor.
.tb2 re-decompresses each 100-900 KB block. A plain.tar lets tar --list, tar --extract --to-stdout, and dd jump straight to the byte offset without CPU overhead..tb2 distribution mirrors to modern .tar.zst (used by Arch Linux package repos since 2019).org.apache.commons.compress without the optional jbzip2 dependency) read TAR but not bzip2 streams.tar -tf archive.tar lists contents in milliseconds; tar -tjf archive.tb2 decompresses the whole stream first. Auditors verifying a backup catalog appreciate the difference on multi-GB archives.| Property | TB2 (tar.bz2) | TAR |
|---|---|---|
| Compression | bzip2 (Burrows-Wheeler) | None — pure container |
| Typical size on 100 MB of source code | ~18-25 MB | 100 MB (plus padding) |
| Extraction CPU | High — single-threaded bzip2 decode | Negligible — direct read |
| Random access | No index; sequential block decode | Direct byte-offset seek |
| Native tooling | tar -xjf, bzip2 -d, pbzip2 |
tar -xf, every POSIX system |
| Preserves Unix perms/symlinks/ownership | Yes | Yes |
| Block alignment | 512-byte tar blocks inside compressed stream | 512-byte tar blocks, padded to record size |
| Common origins | Linux source tarballs (kernel.org pre-2013), Gentoo distfiles, FreeBSD ports cache | Backups, Docker image layers, OCI artifacts |
| Variant | Equivalent on disk | Notes |
|---|---|---|
.tb2, .tbz2, .tbz, .tz2 |
Same bytes as .tar.bz2 |
Single-extension aliases; some filesystems and older Windows tools prefer them |
Output .tar |
Uncompressed tar archive | Suffix changes; SHA-256 of underlying tar is identical to what bunzip2 would produce |
| Compression level used inside | Block size 100-900 KB (-1 to -9) |
Cannot be inferred from filename; xconvert decompresses whichever level was used |
Multi-stream .bz2 |
Concatenation of independent bzip2 streams | Handled transparently — output is a single contiguous tar |
Yes. .tb2, .tbz2, .tbz, and .tz2 are all single-extension aliases for a tar archive compressed with bzip2. Byte-for-byte the contents are identical to .tar.bz2; only the filename differs. Some FAT/NTFS workflows and older Windows tools prefer the three-character suffix because they choke on double extensions.
Almost always, yes — that is the point. Bzip2 typically compresses text-heavy payloads (source code, logs, JSON) to 15-30% of their original size, so a 50 MB .tb2 of source might expand to a 200-300 MB .tar. Binary payloads that are already compressed (JPEGs, MP4s, pre-zipped jars) compress poorly under bzip2, so the size difference can be smaller — sometimes only 5-10%.
No. The bzip2 layer wraps an unmodified tar stream, so removing it leaves the tar intact — same file ordering, same Unix permissions, same ownership UIDs/GIDs, same symlink targets, same mtime/atime/ctime values, same long-filename extensions (GNU ././@LongLink or PAX headers). sha256sum of the output .tar matches what bunzip2 archive.tb2 would produce locally.
Bzip2 uses the Burrows-Wheeler transform on 100-900 KB blocks followed by Huffman coding. The reverse BWT requires sorting an entire block before any output bytes can be emitted, and the reference implementation is single-threaded. Gzip's DEFLATE is a streaming LZ77+Huffman scheme that emits output continuously. On a typical 2026 laptop, expect bzip2 decode at 25-40 MB/s versus gzip at 100-200 MB/s and zstd at 1-2 GB/s.
Yes — tar -xf archive.tb2 auto-detects bzip2 in modern GNU tar (since 1.15) and BSD tar (libarchive). The reason to convert to.tar is when you need to re-pipe through a different tool, inspect the file list cheaply, or hand the archive to a system that lacks a bzip2 library. If you just want the files on disk, skip the conversion and use extract TB2 directly.
After converting to.tar, run it through gzip, xz, or zstd. On xconvert, use TAR to TAR.GZ for a 2-3x speed boost on decompression versus bzip2 with a small size penalty, or TAR to TAR.XZ for tighter compression than bzip2 at the cost of slower packing. For the reverse direction, TAR to TB2 re-applies bzip2.
Yes — both are tar-level features encoded inside the tarball itself, not the bzip2 wrapper. Sparse-file extensions (GNUTYPE_SPARSE, PAX GNU.sparse.*) and hard-link references survive the conversion unchanged. The bzip2 layer never inspects the tar payload, so anything legal in the original .tar.bz2 is legal in the output .tar.
xconvert processes archives well into the multi-gigabyte range; the practical limit is your upload bandwidth and browser memory, not the converter. For multi-GB Linux distribution tarballs or large backup snapshots, expect the bzip2 decode to dominate processing time — bzip2 is single-threaded in the reference codec, so a 4 GB archive can take several minutes to decompress even with fast disk I/O.
Both. Most new distribution channels have moved to xz (LLVM, Linux kernel since 3.4 in 2012) or zstd (Arch Linux packages since 2019, Fedora rpm payloads since F31). However, .tb2/.tar.bz2 remains common in: Gentoo Portage distfiles, FreeBSD ports cache, legacy SourceForge releases, and many academic dataset mirrors that haven't migrated. Converting old .tb2 archives to .tar (then optionally to .tar.zst) is a common modernization step.