Convert ZIP to GZ

Almost everyone who wants this conversion was told to. A hosting panel asks for a `.tar.gz`, a deploy script untars its payload, a client's import documentation names the extension, or a Linux box on the other end has `tar` and nothing that reads ZIP without installing something first. The archive you have is a ZIP because that is what Windows and macOS make.

So the goal is conformance, not compression. Once the file has the shape the far end expects, the job is finished — and the rest of this page is mostly about what that shape actually is, because it is the one thing the conversion cannot hide from you. Most pages about this pair present GZ and ZIP as two interchangeable archive formats and let you discover the difference afterwards, usually at the moment something unpacks to a single unfamiliar file and you start wondering what went wrong. Nothing did; the formats are simply not the same kind of thing, and knowing that in advance turns a confusing result into an expected one.

This is the fact the pair turns on. GZ, specified in RFC 1952 and dating from 1992, compresses a single byte stream. It stores no list of members, no paths and no directories — the registry records it as a stream format with exactly one member, and its known problem as having no directory structure at all.

A ZIP, by contrast, is a container: a set of independently compressed entries with a directory at the end saying where each one lives. There is no way to pour the second into the first directly. Something has to flatten the many files into one stream before gzip can touch them, and that something is TAR.

The pipeline makes a TAR of the unpacked contents and compresses that tarball with gzip. The file you get back therefore has two layers: a gzip stream on the outside, a tar archive inside it, your files inside that. Any Unix machine will unwrap both in one step with `tar -xzf`.

The name is the one thing that looks odd. Downloads here take your original stem and the target extension, so `photos.zip` comes back as `photos.gz` rather than `photos.tar.gz`. Rename it if something downstream is fussy about extensions — the registry lists `.tgz` as an alternative spelling of the same thing — and be aware that unpacking it with a plain gzip tool leaves you holding a `.tar` to open next.

People expect a conversion to be worth something in bytes, and this one is not. Both formats compress with DEFLATE and both look back through a 32 KB window, so they find the same repetitions and produce broadly similar output on the same data. You are changing containers, not compressors.

There is one structural difference that can cut either way. ZIP compresses each entry separately and gzip sees one continuous tar stream, so an archive of many small similar files can compress a little better as a tarball, while the tar layer adds its own 512-byte block padding on top. On most real archives the two effects roughly cancel. If the goal is genuinely a smaller file, convert the ZIP to XZ instead.

A gzip stream can carry the original file name and modification time of what it compressed, and this is a real difference from its two siblings: BZ2 and XZ store no name at all. It is a small detail with a visible consequence — unpacking a `.gz` often gives you back a sensibly named file rather than something anonymous.

Here that name is `output.tar`, because the tarball is what was compressed. It is worth knowing when you unwrap the download by hand and wonder where your original name went: it is on the outer file, which you chose, and the inner tar carries the pipeline's name for the intermediate step.

The registry marks GZ as supported by all browsers, which is true and routinely misread. Browsers negotiate gzip as a transfer encoding: the server compresses a response, the browser decompresses it before anything sees it, and no file is involved. That is why the whole web is gzipped and nobody notices.

A `.gz` file you download is not that. The browser treats it as an opaque file and saves it as-is, because the compression is the content rather than the transport. Neither Windows Explorer nor the macOS Finder unpacks one natively, so the recipient needs 7-Zip, Keka or a shell — which is a fair reason to leave an archive as a ZIP when it is going to a person rather than a server.

If your ZIP contains a single file, the mismatch this page is about disappears — one file is exactly what GZ was designed for, and the result is the plain, idiomatic thing: one compressed stream, no container, no ambiguity about what is inside.

The pipeline still routes it through the same tar step for consistency, so what you download remains a gzipped tarball rather than a gzip of the file itself. If you specifically need the latter — a single `.sql.gz` or `.log.gz` for a tool that reads exactly that — do it locally with gzip, and this page would rather point you there than hand you a file whose shape is wrong for the job.

Unlike most conversions on this site, this one leaves your device. The ZIP is uploaded over an encrypted connection, unpacked and repacked by 7-Zip on our converter, and returned; the upload, the intermediate tar and the output are all deleted when the job ends, and the working directory is memory-backed and thrown away with the container.

That sets the boundaries. 25 MB per file on the free tier, sixty seconds per job before it is killed, and a refusal for any archive that claims it unpacks to more than 2 GB. A password-protected ZIP also stops here with a message rather than a hang, because the unpacker is given an empty password deliberately so that it reports the problem instead of waiting for one.

All three targets produce the same tar-inside-a-compressor shape and differ only in the compressor wrapped around it. GZ looks back through a 32 KB window, is the fastest of the three and is installed on everything. BZ2 sorts blocks of up to 900 KB, compresses text better than gzip, and is the only archive format our registry marks as legacy rather than current. XZ carries a dictionary of up to 64 MB and produces the smallest file of the three by a clear margin, at the cost of the longest packing time.

The choice is usually made for you by whatever you are feeding. Deploy tooling, container layers and most upload endpoints assume gzip and will not be talked out of it; source releases and distribution packages have largely moved to xz; bz2 mostly appears when you are matching an archive somebody made years ago and want the new file to sit beside the old ones. When nothing dictates the answer, gzip is the safe default, and being the safe default is precisely why this pair gets searched for far more often than its two siblings.

It is worth confirming that what came back holds what you sent, and the check differs by platform. On Linux or macOS, `tar -tzf` lists the contents without extracting anything, which is the fastest way to see that the paths look right and the file count matches. On Windows, 7-Zip or Keka will open the file directly and show you the tar inside it, then its contents on a second click.

That second click is the thing to expect rather than to worry about. Graphical archivers generally remove one layer at a time, so a gzipped tarball legitimately looks like an archive containing a single `.tar`, and only the layer below shows your files. Nothing has gone wrong when that happens; it is the same two-layer structure this page has been describing, seen from the outside. Anything that unwraps both at once is doing you a convenience, not correcting an error.