Convert TAR.GZ to TAR.GZ Online (Rebuilding the Same Format With Different Settings)

Two TAR.GZ Files Can Differ Even When Both Extract Identically

Rebuilding a TAR.GZ into another TAR.GZ isn't a pointless round trip; it means fully decompressing the original gzip stream, unpacking the tar structure underneath, and then re-encoding both layers from scratch with different settings applied. Gzip's DEFLATE compression, specified in RFC 1951, supports compression levels numbered 1 through 9, trading compression time against how small the output gets — level 1 compresses fastest with the least shrinkage, level 9 compresses tightest but takes the longest, and gzip's own default sits at level 6 as a general-purpose middle ground. Two TAR.GZ files holding identical file contents can differ meaningfully in size purely because one was built at level 1 and the other at level 9, despite decompressing to byte-for-byte identical files either way.

The tar layer underneath carries its own real variation between archives that look identical once extracted. GNU tar and other tar implementations sometimes differ in exactly how they format certain header fields, whether they emit pax extended headers for long filenames or stick to GNU's own older long-name extension, and whether sparse files are recorded using GNU's sparse format or left expanded. Rebuilding a TAR.GZ can specifically normalize these tar-layer differences — for instance, converting an archive using GNU-specific extensions into one built strictly to the more portable pax interchange format defined by IEEE Std 1003.1-2001, for better compatibility with tar implementations that don't recognize GNU's own proprietary extensions.

Single-Threaded Gzip Against Pigz's Parallel Block Compression

Standard gzip compresses using a single CPU core no matter how many are available on the machine running it, processing the entire stream sequentially from start to finish. Pigz, a parallel implementation of gzip written by Mark Adler — one of gzip's own original authors — breaks the input into independent 128 KB chunks and compresses them simultaneously across multiple cores, then writes the compressed chunks back out in the correct order with a combined checksum covering the whole file. Rebuilding a large TAR.GZ with pigz instead of ordinary gzip can meaningfully cut wall-clock compression time on a multi-core machine, since the work gets split across cores rather than run one instruction stream at a time.

That speed comes with a documented, minor trade in compression ratio: pigz's independent chunks, by default, still borrow the last 32 KB of the previous chunk as a preset dictionary to preserve most of DEFLATE's usual matching effectiveness, though pigz's own manual notes an --independent option that disables even that link, trading a small amount of additional ratio for chunks that can be decompressed independently or recovered separately if one chunk is damaged. Either way, the resulting file remains a fully standard gzip stream that any ordinary gzip-only decompressor can read without needing pigz itself installed.

Pigz's own documentation also calculates a check value for each chunk in parallel alongside the compression itself, then combines those individual values into the single CRC-32 checksum a standard gzip trailer expects, so a file decompressed with plain gzip afterward sees exactly the same integrity check it would from an archive built entirely single-threaded — the parallelism is invisible to anything reading the finished file.

What Rebuilding an Already-Compressed TAR.GZ Can Change

• Gain or lose size, depending on direction: rebuilding at gzip level 9 instead of a faster default shrinks the file somewhat; rebuilding at level 1 trades size back for speed.
• Gain — faster rebuilds on multi-core hardware: using pigz instead of single-threaded gzip splits the compression work across available CPU cores.
• Gain — a normalized tar variant: converting GNU-specific long-name and sparse-file extensions into the more portable pax interchange format improves compatibility with stricter tar readers.
• Lose — nothing about the actual file contents: a straightforward rebuild doesn't alter the underlying files themselves, only the compression settings and tar-layer conventions around them.
• Gain — a single archive from a previously split set, or the reverse: some tools split large TAR.GZ output into fixed-size parts externally, and a rebuild can merge those back into one continuous file.
• Lose — a small amount of time: any of these rebuilds requires a full decompress-then-recompress pass, which takes real CPU time proportional to the archive's size.

Where GNU Tar and BSD Tar Expose These Full-Extension Settings

Gzip's compression level is set directly with a numbered flag, from -1 through -9, in GNU gzip and in GNU tar's own -z flag when the underlying gzip options are passed through, and 7-Zip and PeaZip both expose an equivalent compression-level slider or dropdown in their archive-creation dialogs. Pigz is available as a separate package on most Linux distributions and through Homebrew on macOS, and GNU tar can be told to use it in place of ordinary gzip with the --use-compress-program flag pointed at the pigz binary.

Normalizing tar-layer format differences is mainly a GNU tar and BSD tar concern specifically: GNU tar's --format=pax option forces pax-format output explicitly rather than relying on GNU's own older extensions, and its --format=ustar option goes further, targeting the original, narrower POSIX ustar format for maximum compatibility with older or stricter tar readers, at the cost of the 100-byte filename and roughly 8 GiB single-file limits that format carries without pax's extensions layered on top.

The Real, Documented Reasons People Rebuild a Gzip Tarball as Gzip

A common scenario in continuous-integration systems involves a build server producing TAR.GZ artifacts quickly at a low compression level to keep build times short, followed by a separate release step that rebuilds the same archive at a higher compression level specifically for the final published download, trading extra CPU time once for a smaller file every one of many downstream downloaders will fetch afterward.

A second real pattern involves large archives on machines with several idle CPU cores, where switching the compression step from single-threaded gzip to pigz cuts real wall-clock time noticeably without changing the output format at all — the resulting file is still an ordinary gzip stream, just produced faster by spreading the work across cores that would otherwise sit unused during a long single-threaded compression run.

A third documented scenario involves cross-platform compatibility testing, where an archive built with GNU tar's own long-filename extensions fails to open correctly in a stricter, non-GNU tar implementation that doesn't recognize those specific extensions — rebuilding the same archive with --format=pax targets the portable, standardized interchange format instead, resolving the compatibility gap directly rather than working around it downstream.

A fourth pattern involves reproducible-build efforts, where two builds of the exact same source tree need to produce byte-for-byte identical TAR.GZ output for verification purposes — a rebuild that fixes file ordering, timestamps, and compression settings to constant, agreed-upon values removes the small variations that different build machines, tar versions, or default compression levels would otherwise introduce into what should be an identical result.

Common Rebuild Scenarios for an Already-Gzipped Tarball

Common Questions About Normalizing an Existing TAR.GZ Build

Why would I convert a TAR.GZ into another TAR.GZ instead of leaving it alone?
Because the compression level, the compressor used, and the specific tar format variant underneath can all differ between two TAR.GZ files that extract identically — rebuilding changes those settings without touching the actual file contents.

Will rebuilding at a higher gzip compression level shrink my archive noticeably?
Somewhat, though DEFLATE's fixed 32 KB window limits how much difference the level setting alone can make; the gap between level 1 and level 9 is real but generally more modest than switching to an entirely different algorithm.

What is pigz, and is its output different from regular gzip's?
Pigz is a parallel gzip implementation that splits compression across multiple CPU cores for speed. Its output is a standard gzip stream, fully readable by any ordinary gzip decompressor with no special tool needed.

Why would I normalize a GNU-format tar archive to the pax format?
Some stricter or non-GNU tar implementations don't recognize GNU's own proprietary long-filename and sparse-file extensions; rebuilding with --format=pax targets the standardized, more widely compatible interchange format instead.

Does rebuilding a TAR.GZ this way change any of the files inside it?
No. Changing the compression level, compressor, or tar format variant doesn't alter the underlying file data once extracted — every file comes out byte-for-byte identical regardless of which of these settings built the archive.