Convert TAR.GZ to TAR Online (Removing the Gzip Layer, Not the Archive)

A TAR.GZ Was Always a Tar File; Only the Wrapper Comes Off

Converting a TAR.GZ into a plain TAR isn't a conversion between two different archive designs at all — it's the removal of a single compression layer that was applied on top of an ordinary tar file to begin with. Tar itself, standardized under POSIX since 1988, packs each file into a 512-byte header block recording its name, owner, group, permission mode, and size, immediately followed by that file's raw data padded to the next 512-byte boundary, ending with two consecutive zero-filled 512-byte blocks that mark the archive's end. Gzip's DEFLATE compression, defined in RFC 1951, runs entirely independently over whatever byte stream tar produces, with no awareness of the file boundaries inside it.

Because those two jobs never overlap, undoing a TAR.GZ back into a plain TAR is a single, reversible operation with nothing ambiguous about it: decompress the gzip stream, and the exact tar byte sequence that existed before compression comes back out, unchanged in every respect — file order, header contents, padding, and the trailing zero blocks are all restored exactly as tar originally wrote them.

Why the Resulting TAR File Is Always Bigger, Not Smaller

Removing gzip's compression is the one part of this conversion that isn't neutral: the resulting plain tar file is, without exception, larger than the TAR.GZ it came from, because DEFLATE's whole purpose was shrinking that same byte stream in the first place. The size difference depends entirely on how compressible the original content was — heavily compressible source code or plain text can grow several times larger once decompressed, while an archive already full of photos, videos, or other pre-compressed data barely changes size at all, since gzip had very little redundancy left to remove from that kind of content to begin with.

Nothing about tar's own internal structure changes during this step. Every 512-byte header stays exactly as GNU tar, BSD tar, or whichever implementation originally wrote it, including any long-filename or sparse-file extensions that were present before compression — pax extended headers marked with the "x" or "g" typeflag, or GNU tar's own proprietary long-name records, decompress along with everything else and remain fully intact and readable by any tar implementation that already supported them.

The default blocking factor tar uses also carries straight through this step unchanged. GNU tar historically writes and reads data in physical blocks of 20 tar records at a time — 10,240 bytes per block — a convention inherited from magnetic tape drives, where reading and writing in larger physical chunks reduced mechanical start-stop overhead. Modern disk-based archives don't depend on that reasoning anymore, but the default blocking factor still applies by convention, and it stays identical whether the archive is compressed or not, since gzip operates on the whole byte stream regardless of how tar internally grouped its own blocks.

What Stripping the Gzip Layer Gains and What It Trades Away

• Gain — faster reading and writing: a plain tar file skips DEFLATE's compression and decompression steps entirely, which matters when an archive is read or rewritten repeatedly in a pipeline.
• Gain — a format some pipelines expect uncompressed: certain backup and transfer tools apply their own compression or deduplication layer downstream and specifically need an uncompressed tar as input to work correctly.
• Lose — the smaller file size DEFLATE provided: the plain tar is always at least as large as, and typically noticeably larger than, the original TAR.GZ.
• Unchanged — every file's Unix permissions, ownership, and name: tar's own header fields decompress exactly as written, with nothing added or removed by this step.
• Unchanged — sparse-file and long-filename extensions: any GNU or pax extended headers present before compression survive the decompression step completely intact.
• Lose — a small amount of storage or transfer efficiency: a larger file takes longer to copy over a network or occupies more disk space while sitting unused.

Every Common Platform Already Handles This Decompression Natively

GNU tar's -z flag, or its -a / --auto-compress option detecting the .tar.gz or .tgz suffix automatically, decompresses a TAR.GZ directly on essentially every Linux distribution without installing anything extra, since gzip has shipped as part of the base system on Unix-like platforms since the early 1990s. macOS's Archive Utility and its underlying BSD tar behave the same way, decompressing and unpacking in one step when a TAR.GZ is double-clicked or passed to the tar command in Terminal.

Windows has no built-in graphical support in File Explorer for either format, but Windows 10 version 1803 and later ships a command-line tar.exe, based on the libarchive project, that both decompresses and creates gzip-compressed archives from a terminal without any separate installation. For a graphical option, 7-Zip, WinRAR, and PeaZip all extract the gzip layer and expose the underlying tar file, or optionally re-save it as a standalone .tar, in a single operation through their normal extraction dialogs.

The Real, Documented Reasons Someone Strips Gzip Compression Off

A common, practical scenario involves feeding an already-downloaded TAR.GZ into a downstream backup or deduplication tool that specifically expects uncompressed input, since compressing data twice — once with gzip and again inside the deduplication tool's own scheme — usually wastes CPU time without shrinking the result any further, and can even interfere with the second tool's ability to find duplicate blocks across files, since gzip's output looks essentially random at the byte level even where the underlying content repeats.

A second real pattern shows up when an archive needs to be re-examined or edited entry by entry — adding, removing, or replacing individual files inside a tar archive with a tool like GNU tar's --delete or --append options works directly against a plain, uncompressed tar file, but not against a compressed stream, since those in-place modification operations require random access to the archive's internal structure that a compressed stream doesn't offer.

A third scenario involves transferring an archive over a connection or storage medium that already applies its own compression, such as certain network filesystems or storage arrays with built-in compression enabled at the block level — compressing the data twice in that case adds CPU overhead for no real space savings, so stripping gzip off before the transfer avoids paying that redundant cost twice.

A fourth pattern involves recompressing the same underlying tar content with a different algorithm entirely — someone who wants a TAR.BZ2 or TAR.XZ instead of TAR.GZ has to decompress back to plain tar first as an intermediate step, since bzip2 and xz both need the raw tar stream as their input rather than an already-DEFLATE-compressed one, and stacking a second compressor directly on top of gzip's output wouldn't meaningfully shrink it any further.

Compressed TAR.GZ Set Against the Plain TAR It Unpacks Into

Common Questions About Turning a TAR.GZ Back Into Plain TAR

Why would I want a bigger, uncompressed file instead of keeping it compressed?
Some downstream tools, like deduplication or backup systems, need uncompressed input to work correctly, and compressing twice with two different schemes usually wastes CPU time without shrinking the result any further.

Does decompressing a TAR.GZ change any of the files inside it?
No. DEFLATE is lossless, and tar's own header structure is untouched by compression entirely, so every file, permission, and name comes back exactly as it was before the TAR.GZ was created.

Why is the plain TAR file so much bigger than the TAR.GZ was?
Because gzip's whole purpose was shrinking that same data. How much bigger depends on how compressible the original content was — already-compressed files like photos barely change size, while plain text can grow several times larger.

Can I add or remove files from a TAR.GZ directly, without decompressing it first?
Not with GNU tar's in-place --delete or --append options — those require an uncompressed tar file, since editing a compressed stream in place isn't structurally possible the same way.

Do sparse files or long filenames survive this decompression step?
Yes. Any GNU or pax extended headers present in the original TAR.GZ decompress along with everything else and remain fully intact in the resulting plain tar file.

Does the tar blocking factor change when the gzip layer is removed?
No. GNU tar's default 20-record, 10,240-byte physical blocking convention is part of the tar layer itself, and it stays identical whether or not a gzip layer was ever wrapped around it.