Reset to defaults
Need help?How to Re-pack TAR to TAR Online
- Upload Your TAR Archive: Drag and drop your
.tarfile(s) into the uploader, or click "+ Add Files" to browse. Batch is supported — drop ten archives and process them in one job. - Choose Single Archive or Individual Archives: "Single Archive" merges every uploaded
.tarinto one combined output (handy when a vendor ships youpart1.tarandpart2.tar). "Individual Archives" rewrites each input as its own normalized.tarso the file count stays the same. - Confirm TAR as the Output Format: TAR is already selected. If you actually wanted a compressed variant, switch to tar.gz, tar.bz2, tar.xz, or zip from the format picker.
- Convert and Download: Click "Convert". Your re-packed
.taris generated server-side and offered for download — no sign-up, no watermark, no re-tarball-by-hand on the command line.
Why Re-pack a TAR File?
TAR is just a concatenation of file headers plus raw bytes — there is no compression, no checksum on the archive as a whole, and no central directory. That simplicity is why people still ship .tar after 45 years, but it also means a "TAR to TAR" round-trip is a real operation: you can normalize the layout, merge multiple tarballs, or rewrite to a different tar dialect. According to the GNU tar manual, GNU tar can read and write at least four dialects (v7, ustar, oldgnu/gnu, posix/pax), and they are not byte-equivalent for the same set of files.
- Merge multi-part vendor tarballs — Linux distros, AOSP code drops, and scientific datasets are often split across several
.tarfiles (source-1.tar,source-2.tar…). Re-packing into one archive gives you a single artifact to checksum, sign, and upload. - Switch dialects for compatibility — Old build systems (
pdtar, BSD pax pre-2001) choke on GNU extensions like././@LongLinkand sparse-file headers. Re-packing as USTAR (POSIX 1003.1-1988) trades the >100-char filename ceiling for universal portability. - Drop ACLs, xattrs, and SELinux labels — POSIX.1-2001 pax headers carry these as extended records. If your archive is moving between Linux, macOS, and a FAT32 USB stick, stripping them avoids "Operation not permitted" warnings on extract.
- Reproducible / deterministic builds — The reproducible-builds.org archives guide flags atime, ctime, owner UIDs, and entry order as the four sources of byte-drift in
.tar. A re-pack with sorted entries, fixed mtime, anduid=0/gid=0produces an archive whose SHA-256 matches across machines. - Repair archives created in odd directories — A tarball created with absolute paths (
/home/alice/project/...) or with a leading./can be cleaner after re-pack into a single top-level folder. - Re-tarball after editing contents offline — If you extracted, patched one config file, and need to ship the result back, this tool re-packs without you needing tar on a Chromebook or restricted corporate machine.
TAR Format Dialects — What Actually Differs
| Dialect | Year | Max filename | Max file size | Sparse files | xattr / ACL | Notes |
|---|---|---|---|---|---|---|
| v7 (original) | 1979 | 100 chars | 8 GB | No | No | Last-resort compatibility only; no UID/GID names |
| ustar (POSIX) | 1988 | 100 + 155 prefix = 256 | 8 GB | No | No | Widely portable baseline |
| oldgnu | ~1992 | unlimited (via ././@LongLink) |
8 GB | Yes | No | Pre-2003 GNU tar default |
| gnu | 2003+ | unlimited | 8 GB (binary-encoded) | Yes | No | GNU tar default through 1.27 |
| pax (POSIX.1-2001) | 2001 | unlimited | unlimited | No (in spec) | Yes | GNU tar default since 1.28 |
Source: GNU tar 1.35 manual, chapter 8. The "8 GB" ceiling on pre-pax dialects comes from the 12-octet ASCII octal size field (077777777777 = 8 GiB − 1).
Reproducible-Build Re-pack Cheatsheet
| Step | What we do | Equivalent tar flag |
|---|---|---|
| Sort entries | Alphabetical by name, locale-independent | --sort=name |
| Zero ownership | Set every entry to UID 0 / GID 0 | --owner=0 --group=0 --numeric-owner |
| Fix timestamps | Single mtime (often SOURCE_DATE_EPOCH) |
--mtime=@$SOURCE_DATE_EPOCH |
| Strip pax cruft | Remove atime, ctime from extended headers | --pax-option=delete=atime,delete=ctime |
| Pick a stable format | Use ustar or gnu rather than default pax | --format=ustar |
These five steps are the canonical advice from reproducible-builds.org and require GNU tar 1.28 or later.
Frequently Asked Questions
Why does a TAR to TAR conversion change the file size at all?
Because tar pads each file entry to a 512-byte block boundary, and the archive itself is padded to 10240 bytes (20 blocks) by default. When the dialect changes — say USTAR to pax — extended headers add a few hundred bytes per long-named entry. A re-pack with sorted entries can also defragment the block padding. Expect the new .tar to be within ±1% of the original, not byte-identical.
Will a re-packed USTAR archive lose my long filenames?
Yes, if any path exceeds 256 characters (100-char name + 155-char prefix). USTAR truncates or errors on those. If you have long paths and need portability, choose pax instead of USTAR — pax stores the full name in an extended header that all modern tar implementations (GNU tar 1.13+, BSD tar/libarchive, Python tarfile, 7-Zip 21.04+) read transparently.
Does this tool preserve symlinks, hard links, and file permissions?
Yes. Tar's typeflag byte (2 for symlink, 1 for hard link, 5 for directory) is preserved through the re-pack, and the 8-octet mode field carries Unix permissions (rwxrwxrwx + setuid/setgid/sticky). What is not preserved by default is extended attributes (xattr, ACLs, SELinux labels) when you down-convert from pax to ustar — those live only in pax extended headers.
Can I merge multiple TAR files into one without extracting them first?
Yes — that's exactly what "Single Archive" mode does. Tar is a streamable format with no central index, so merging is a concatenation pass over each input's entries into a single output stream. The result is a normal .tar with one directory tree per input archive at the top level. If your inputs have colliding paths, the later entry wins on extract (standard tar behaviour).
Why not just rename the .tar to .tar — what does conversion actually do?
A rename does nothing useful; a conversion rewrites the archive. The tool reads every entry header, optionally re-orders them, optionally drops or rewrites metadata (atime, ctime, owner names), and writes a fresh archive in the dialect you pick. Think of it as tar -x | tar -c with deterministic flags, not mv old.tar new.tar.
How do I make the output bit-for-bit reproducible across machines?
You need three things from your source: identical file contents, identical entry order, and identical mtimes. The re-pack handles entry order and metadata normalization. For mtime, the Reproducible Builds project recommends setting SOURCE_DATE_EPOCH to your last-commit timestamp and using it for every entry. Two re-packs of the same input with the same settings should produce the same SHA-256.
Is there a file-size limit?
Server-backed conversions on xconvert handle tar archives up to several GB; very large archives (>2 GB) will queue rather than process instantly. For comparison, FreeConvert caps free users at 1 GB per file. If you need to extract a tarball instead of re-packing one, use Extract TAR to pull individual files instead of re-packing the whole archive.
What's the difference between this and re-tarring on the command line?
Functionally none — this is tar -xf input.tar && tar --format=ustar --sort=name -cf output.tar . packaged into a web UI. The advantage is that you don't need a Unix shell, root, or even tar installed locally. The disadvantage is the upload/download round-trip, so for >5 GB archives the CLI is faster. For a one-off, the web tool wins on ergonomics.