Convert GZ to ZIP

The experience that brings people here is specific and universally irritating. A file arrives called something like `project-2.1.tar.gz`, Windows has no idea what it is, and installing an archiver produces a second file called `project-2.1.tar` that Windows also has no idea what to do with. Two steps in, and there is still nothing at all to look at.

Nothing is broken. That is the normal shape of a Unix archive, and it looks strange only if you grew up with ZIP, where compressing and bundling happen in one operation and nobody has to think about the distinction. On the Unix side they have always been two separate jobs done by two separate programs, and the file name records both of them in the order they were applied — read `project-2.1.tar.gz` from the right and it tells you the whole story: gzipped, and underneath that, tarred. Once you can read the extension that way, the format stops being mysterious and becomes merely inconvenient.

GZ, standardised as RFC 1952 in May 1996, compresses exactly one byte stream. Our registry records it as a stream format with a single member and lists the absence of any directory structure as a known problem — there is no field anywhere in a gzip file for a file name list, a folder or a permission.

TAR supplies all of that. It is a bundler with no compression whatsoever, dating from 1979, which writes a header block for every file and then its contents in sequence. Put the two together and each does one job well: TAR knows what the files are called and where they sit, gzip makes the result smaller. `.tar.gz` is not a quirk of packaging, it is a division of labour written into the file name. The same pattern produces `.tar.bz2` and `.tar.xz`, which are the identical arrangement with a different compressor on the outside — recognising one of them means recognising all three.

The converter decompresses the gzip stream and then looks at what came out. If it is a single item, it tries to read that item as a TAR and, when that succeeds, uses its contents as the real payload. Only then is the ZIP written, from inside the extracted directory so your files sit at the top level rather than inside a wrapper folder.

The check forces the tar type rather than trusting the file name, and that detail was learned the hard way on this pair's siblings. Because a gzip header can store the original name, the intermediate file arrives sensibly named and a name-based check works; BZ2 and XZ store no name at all, and the same check missed the tar entirely. The symptom was an archive containing one opaque blob instead of the files that went in.

Plenty of gzip files hold one ordinary file and no tar: a database dump as `backup.sql.gz`, a rotated `access.log.gz`, a single exported CSV. That is gzip used exactly as designed, and it is not a broken archive.

The converter handles it by falling back. When the decompressed content does not parse as a TAR, it is treated as the single file it is, and the ZIP you get contains that file alone. This is why the page works equally well for a hosting panel's nightly SQL dump and for a source release, which are otherwise very different things wearing exactly the same extension — and why you do not need to know which of the two you have before you upload it.

A gzip header can carry the original name and modification time of whatever was compressed, which is a small feature with a visible payoff: decompressing a `.gz` often restores a sensible name rather than leaving you to guess. It is the one thing gzip has that its two Unix siblings do not.

Inside a tarball that information matters less, because the TAR already carries every name. It matters most in the single-file case above, where the name in the gzip header is the only record of what the file was called before somebody renamed the archive. The ZIP you download takes your own file's stem, so `backup.tar.gz` returns as `backup.zip`.

Very little, because both formats use the same compression. DEFLATE with a 32 KB window is what gzip does and what ZIP does to each of its entries, so the two land in a similar place on the same data.

The one systematic difference runs against ZIP: gzip compresses the whole tar as a single continuous stream and can therefore find repetition that crosses file boundaries, while ZIP restarts at every entry. On an archive of many small similar files — a source tree, a set of config files — expect the ZIP to be a few percent larger. On a handful of large files, expect no meaningful difference at all, and certainly not one worth planning around.

TAR records a mode, an owner and a group for every member, which is precisely why Unix tooling likes it. ZIP has no equivalent that Windows understands, so those values do not travel — the general rule for archive conversions here is that the files come out byte for byte and the container's knowledge about them is what is at risk.

For most people downloading a dataset or a plugin, none of it matters. It matters if you are moving something that will be run rather than read: scripts lose their executable bit, and a deployment that assumed it will fail in a way that looks unrelated to the archive. Set the modes again on the machine that needs them.

This conversion runs on our converter rather than in the page, because unwrapping and rewriting archives needs real programs. Your file is uploaded over an encrypted connection, unwrapped, repacked as a ZIP and sent back, and the upload, the intermediate tar and the output are all deleted as the job ends.

The scratch space is memory-backed, bounded and discarded with the container. The free tier takes 25 MB per file, jobs are killed at sixty seconds, and an archive that declares more than 2 GB of unpacked content is refused before anything is written — a real consideration with gzip, where a modest download can hold a very large tree.

If `.tar.gz` files land in your downloads folder regularly, the durable fix is a local archiver rather than this page. 7-Zip and Keka both take off both layers in one action, cost nothing, work offline and have no upload ceiling at all — and recent Windows builds ship a `tar` command that does the same thing from a terminal without installing anything whatsoever.

Use the converter when you cannot install software on the machine in front of you, when the file is a one-off, or when what you actually need is a ZIP to hand to somebody else rather than a folder to look at. Those are genuinely different needs with different best answers, and a page insisting that the converter is always the right one would not be telling you the truth about your own situation.

Occasionally the file that started this is not a compressed archive but a compressed single artefact: a WordPress backup that is one SQL dump, an export that is one enormous JSON file, a log shipped from a server. The `.gz` extension is identical and gives nothing away, which is why so many people arrive expecting a folder and find one file.

The conversion handles it either way, and the ZIP you get contains whatever was genuinely in there. If it holds a single file with an unfamiliar name, nothing failed — the gzip header carried that name and the converter used it. That is the moment to look at the extension underneath rather than at the archive: a `.sql` wants a database tool, a `.json` wants an editor, and no amount of repacking will make either of them into a folder of documents.