TGZ to TGZ Converter

How to Convert TGZ to TGZ (Recompress, Merge, or Split)

1. Upload Your TGZ File(s): Click "+ Add Files" or drag and drop one or more .tgz archives onto the dropzone. Drop several at once if you want to merge them into one output.
2. Pick the Combine Mode: Under "Combine?" choose Single Archive to merge every uploaded archive's contents into one new TGZ, or Individual Archives to repack each input as its own TGZ. The default when the source is already an archive is Individual Archives.
3. Confirm Output Format (Optional): The output extension is locked to .tgz (tar + gzip). If you need stronger compression, use a sibling page — see TGZ to TAR.XZ (LZMA2) or TGZ to 7z — or pick TGZ to ZIP for Windows-native sharing.
4. Convert and Download: Click "Convert." The original archive is extracted, the contents are re-packed with tar and recompressed with gzip, and the new TGZ is delivered to your browser. No watermark, no sign-up, no email.

Why Convert TGZ to TGZ?

A TGZ-to-TGZ pass is not a no-op. The tool decompresses the gzip layer, unpacks the tar, then writes a brand-new tar stream that is recompressed with gzip — so the central index, the tar headers, and the gzip stream are all freshly written. That matters in several specific cases:

• Recompress a weakly compressed archive. Many build pipelines emit .tgz files using gzip -1 (fast) or via libraries that default below the GNU gzip default of -6. Re-passing the contents through a fresh gzip cycle can shave 5-15% on text-heavy archives (logs, JSON, source trees) — though gains plateau because gzip's DEFLATE has a 32 KB sliding window and can't find long-range redundancy the way LZMA can.
• Merge multiple TGZs into one. Drop several .tgz files in, pick Single Archive, and the contents are extracted and combined into one output .tgz. Avoids the manual tar -xzf a.tgz && tar -xzf b.tgz && tar -czf merged.tgz . shell loop.
• Split one TGZ into per-entry archives. Use Individual Archives when the source contains many independent top-level items — each becomes its own .tgz, handy for bulk distribution where each recipient only wants one folder.
• Fix a broken tar header chain. When a .tgz was produced by a tool that wrote non-standard header padding (some legacy Java zip libraries, certain container snapshot exporters), repacking through gzip + GNU tar produces a stream that every BSD tar, GNU tar, and 7-Zip can read.
• Normalize archive format. A .tgz may have been written in the older v7 or ustar tar format, in GNU tar's L-block long-name encoding, or in PAX extended-header format. Repacking emits a single consistent format that downstream tools handle predictably.
• Strip macOS resource forks. A .tgz created on macOS via Finder's "Compress" can contain ._filename AppleDouble metadata files. Repacking from a clean extract drops the macOS-specific sidecars when you re-share the archive with Linux servers.

.tgz vs .tar.gz — Are They Different?

There is no technical difference. Renaming archive.tar.gz to archive.tgz (or vice versa) does not change a single byte inside the file. Use whichever extension your downstream tool or convention expects.

gzip Compression Level Quick Guide

For files where the last few percent matters, switching format usually beats raising the gzip level — DEFLATE's ceiling is set by its 32 KB window. See TGZ to TAR.XZ for LZMA2 (often 20-40% smaller on source code), or TGZ to TAR.BZ2 for the bzip2 alternative.

Frequently Asked Questions

Will my TGZ actually get smaller after repacking?

Usually only by a small amount. If the source was compressed with gzip -1 or by a library that uses a low default level, repacking with a standard gzip -6/-9 pass can shrink the archive by 5-15% on text-heavy content. If the source was already produced with gzip -9, you should expect under 1% difference — gzip is deterministic and the DEFLATE algorithm caps at the same ratio for the same window settings. For meaningful gains on already-tight TGZs, switch format to .tar.xz (LZMA2) via TGZ to TAR.XZ.

Does converting TGZ to TGZ change the tar member format?

It can. GNU tar supports several on-disk formats — v7 (legacy), ustar (POSIX.1-1988), GNU (with L-blocks for long names), and PAX/POSIX.1-2001 (extended headers). When the tool repacks, it writes a single consistent format that all modern tar implementations read. If your source TGZ used GNU's deprecated long-name encoding and a downstream tool only speaks PAX, repacking can fix the compatibility gap.

How do I merge multiple TGZ files into one?

Drag every .tgz file into the upload area at once, or use successive "+ Add Files" clicks. Set "Combine?" to Single Archive. The tool extracts each input archive, combines the contents, and writes one merged output .tgz. If two source archives contain a file at the same relative path, the later one overwrites the earlier — rename inside one of the archives first if you need to keep both.

Why would I split one TGZ into individual archives?

Two cases. First, distribution: each recipient only needs one of the top-level folders inside the archive, and shipping 20 small .tgz files is easier than asking everyone to extract a 5 GB bundle. Second, parallel processing: build farms and CI runners can pull and extract per-folder archives in parallel where a single monolithic TGZ has to be downloaded and unpacked serially.

Will repacking preserve Unix file permissions and symlinks?

Yes. The tar format records POSIX permissions, ownership (UID/GID), and symbolic links inside the tar headers, and the repack writes them back unchanged. This is the main reason TGZ persists on Linux instead of being replaced by ZIP — ZIP's permission handling is convention-only and varies by tool, whereas tar's is standardized. If you need full xattrs (SELinux labels, capabilities, ACLs), make sure the source was created with tar --xattrs and the PAX format; otherwise those are stripped at archive time, not at repack time.

Why is the output size sometimes one or two bytes different from the input?

Because the gzip wrapper around the tar stream stores a modification timestamp, the original filename, and an optional comment in its header. Re-running gzip writes a fresh header (new mtime, possibly different filename string), so the few header bytes change even when the compressed payload is identical. The actual file contents inside the archive are untouched.

Can I add encryption or a password to the output TGZ?

Not natively. The .tgz format has no built-in password layer — tar and gzip both date from before consumer encryption was a standard archive feature. To encrypt a tar bundle you typically pipe through gpg (tar -czf - dir | gpg -c > dir.tgz.gpg) or convert to a format that supports it: TGZ to 7z gives AES-256 with header encryption, and TGZ to ZIP supports AES-256 in tools that implement WinZip's spec.

When should I pick a different format instead of repacking TGZ?

If you need broad compatibility with Windows users who'll double-click in File Explorer, use TGZ to ZIP — Windows has read-only .tar.gz support only since Windows 10 build 17063 (2018, via tar.exe) and the GUI still defaults to ZIP. If you need maximum compression, use TGZ to TAR.XZ (LZMA2) or TGZ to 7z — both routinely produce archives 20-40% smaller than gzip on source code, logs, and other text. If you just want the plain uncompressed tar (e.g., to pipe through a different compressor), use TGZ to TAR.

Is there a file size or count limit?

No fixed cap is published for this tool. Server memory and upload size become the practical bottleneck for very large archives (multi-gigabyte). For routine archives in the tens to low hundreds of megabytes, repacking completes in seconds. If your TGZ exceeds a few GB, expect the conversion to take longer and consider doing the repack locally with gzip -d archive.tgz | gzip -9 > archive.new.tgz instead.