TGZ to TAR — removing the gzip wrapper so a plain-tar step can consume the artefact

A deployment step may require plain TAR while the published artefact is project.tar.gz. This route decompresses gzip, validates the supported USTAR contents, and writes a new uncompressed TAR. Names and payload bytes are retained, but headers are rebuilt with defaults: it is not a byte-for-byte copy of the original inner TAR.

tar stores members uncompressed, so a compressed source may grow substantially.

Drop files here or Choose files TGZ, up to 12 MB

Add a file to start.

Processed on your device. Files aren’t sent anywhere.

No sign-up. Nothing to install.

Stripping the gzip wrapper

Native streaming decompression unwinds the gzip stream and its checksum is validated; the tar members are then read one by one with their header checksums checked, and written into a new tar container.

Regular file names and payload bytes are preserved exactly.
Directories are kept, so the tree the deployment step expects is intact.
The output tar stores members without compression.
Names keep their tar sequence; sorted-by-name exists for deliveries that want the members alphabetically arranged.
Timestamps, permissions, owners, comments, extra fields and the gzip header name and time are not preserved.

What the deployment step receives

The consumer sees a plain container: header plus payload per member, nothing wrapped.

Aspect	project.tar.gz	output .tar
Compression layers	gzip over tar	none
Member payload	stored inside gzip	stored as-is
Names and directories	preserved	preserved
Timestamps and permissions	present in tar headers	not carried over
Typical size	smaller	larger

Why the output is bigger than the input

Decompression restores the headers and full payload that gzip encoded compactly. Text-heavy bundles commonly produce a larger uncompressed TAR. Size is not guaranteed to grow, because source padding and metadata are also rewritten.

If the consumer needs a smaller transfer, keep the tar.gz and convert only when the step genuinely cannot read gzip.

Plain-tar questions

Does the output tar stay compressed?

No gzip wrapper is added. Members are written into an uncompressed TAR with fresh headers; output often grows, but its exact size depends on the source contents and rewritten metadata.

Does the tar keep the original permissions?

No. Timestamps, permissions, owners, comments and extra fields are not preserved; names and payload bytes are.

Is the artefact uploaded to a server?

No. The gzip stream and tar members are read inside the browser tab and the tar is a file you download.

Does this extract the bundle into folders?

No. Members are streamed and written into the output container; no folders are created on your machine.

Running the strip

Pass the .tar.gz or .tgz to the archive studio; one file, ceiling 12 MiB.
Set the target to TAR and choose entry order.
Wait for both layers to finish reading; 200 entries and 8 MiB per member are the ceilings.
Read any rejection reason in the file list. It may concern a member feature, checksum or limit rather than naming a specific entry.
Download the .tar and hand it to the deployment step.
Compare the entry list with the release notes, since metadata is not part of the output.

Rejections to expect

Symlink, hardlink, device or FIFO entries are refused.
PAX or GNU extended headers have no supported representation and stop the read.
Absolute, traversal or duplicate paths are refused.
Names must decode as ASCII or valid UTF-8.
PAX/GNU long-name extension records are unsupported. Names already shortened by an earlier tool cannot be reconstructed from the TAR.
The gunzipped TAR stream, including headers and padding, is capped at 32 MiB and a 60x expansion ratio. The reader does not recursively unpack nested archive payloads.

More sharing options