How to Convert GZ to ZIP

A GZ file is not really an archive in the way most people expect. Gzip compresses exactly one file and nothing else. That is why you so often see the double name archive.tar.gz: the tar step bundles many files into a single stream, and gz then compresses that one stream. On its own, a plain .gz holds a single compressed file with no folder structure inside it.

A ZIP file is different. It is a true container that can hold one file or thousands, each stored and compressed separately, with the directory structure preserved. It also opens with a double click on Windows, macOS, and most phones, with no command-line tool required. Converting GZ to ZIP means unpacking that single gzip stream and repackaging its contents in a format anyone can open. This guide explains what each format really is inside, exactly what the converter does, how the common tar.gz case is handled, and when you should leave the GZ alone.

What GZ and ZIP actually are

The conversion is a two-move operation, not a rename. First the gzip layer is removed to recover the original file inside it. Then that file is placed into a fresh ZIP container. Because gz stores a single item, a converted ZIP normally contains a single entry too, unless the gz was a .tar.gz, in which case the tar bundle is expanded and every file inside it becomes its own ZIP entry.

Both formats compress, but they compress differently. Gzip uses the DEFLATE method on one continuous stream. ZIP also uses DEFLATE by default, but applies it per file. For a single item the resulting sizes are close. The reason to switch is rarely a smaller file. It is compatibility: a recipient who has never touched a terminal can open a ZIP, while a bare .gz often leaves them stuck.

Inside a gzip stream

Gzip is a compression format wrapped around a single data stream, defined by RFC 1952.^[1] A .gz file begins with a short header carrying a two-byte magic number, a flag byte, a modification timestamp, and optionally the original filename, followed by the compressed data and an eight-byte trailer holding a CRC-32 checksum and the original uncompressed length. The compression itself is DEFLATE, the same LZ77-plus-Huffman method used across the web, so gzip is efficient and fast to decompress.^[2]

The defining limitation is right there in the design: the format describes one continuous stream and has no table of contents, no per-file boundaries, and no concept of directories. It cannot, by itself, represent a folder of files. This is not an oversight but the point of gzip, which was built to compress a single stream (often piped from another program) rather than to package a collection. Bundling multiple files is deliberately left to a separate tool, tar, which is why multi-file gzip archives are always .tar.gz.

Inside a ZIP archive

ZIP takes the opposite approach: it is an archive format that packages many files together, each compressed independently, and it records where each one lives.^[3] A ZIP file stores every entry with its own local header and compressed data, then places a central directory at the end listing every entry, its name, its path, its size, its checksum, and its offset within the file. Because that directory sits at the end and points back into the archive, a reader can list the contents and jump straight to any single file without decompressing the rest.

The format was created by PKWARE in 1989 and is documented in its APPNOTE specification, which most desktop operating systems now support natively.^[4] Each entry is typically compressed with DEFLATE, the same core algorithm gzip uses, so for a single file the compressed sizes are close. What ZIP adds over gzip is structure: folders, many entries, random access to any one of them, and the double-click support that Windows, macOS, and mobile file managers all build in.

How the conversion actually works

Knowing the two structures, the conversion is easy to follow. The tool reads the gzip header, verifies the magic number, and runs the DEFLATE stream through an inflate step to recover the exact original bytes, checking them against the CRC-32 and length stored in the trailer. At this point it holds the single file that was inside the .gz, byte-for-byte identical to the original.

It then creates a new ZIP: it writes that file as a ZIP entry, compresses it with DEFLATE, and builds the central directory that makes the archive listable and openable everywhere. If the recovered file is itself a tar bundle, the tool unpacks the tar first so that each file it contained becomes its own ZIP entry with its folder path intact. Because DEFLATE is lossless in both directions, nothing in your data changes; only the packaging around it does.

The shared engine: DEFLATE

A detail that explains why converting GZ to ZIP rarely changes the file size much is that both formats are powered by the same compression engine. Gzip is defined as a thin wrapper around a DEFLATE stream in RFC 1952, and ZIP's default and near-universal compression method is DEFLATE as well.^[1] The two files differ in their framing (their headers, trailers, and directories) but the compressed bytes at the core are produced by the same algorithm, so a single file packed as gzip and the same file packed as a one-entry ZIP end up almost identical in size.

DEFLATE itself combines two classic techniques. First, LZ77-style matching scans the data for sequences that have appeared recently and replaces each repeat with a short back-reference (a distance and length) pointing at the earlier copy. Second, Huffman coding then assigns shorter bit patterns to the symbols that occur most often and longer ones to the rare symbols. Together these squeeze out redundancy in text, code, and structured data very effectively, which is why gzip became the web's standard transfer compression.^[2] It also explains the format's blind spot: content that is already compressed, such as JPEG images or MP4 video, has little redundancy left to find, so wrapping it in either gzip or ZIP shrinks it only marginally. When you convert, you are re-framing DEFLATE-compressed data, not compressing it a second time.

Convert GZ to ZIP, step by step

1. Open the converter and add your GZ

   Open the FileFormer archive converter and drop your .gz file in. It runs in your browser, so the file stays on your device.

2. Let it decompress the gz layer

   The tool strips the gzip layer to recover the single file inside. If the file is a .tar.gz, the tar bundle is expanded so every file it held is restored with its folder path.

3. Repackage into a ZIP

   The recovered file or files are written into a new ZIP container with standard DEFLATE compression, so the archive stays reasonably small while gaining universal support.

4. Download and open

   Download the .zip. Double click it on any modern computer or phone to see the contents, no extra software needed.

The special case of tar.gz

The most common real-world .gz file is not a lone compressed document but a .tar.gz (sometimes abbreviated .tgz), and it deserves its own explanation because it is where the one-file-only limit of gzip becomes visible. A .tar.gz is two layers stacked: tar first concatenates a whole tree of files, along with their names, paths, and permissions, into one continuous archive stream, and gzip then compresses that single stream. From gzip's point of view it is still compressing exactly one file, which happens to be a tar bundle.

That layering is why simply renaming a .tar.gz to .zip never works: a ZIP reader would see the gzip header, not a ZIP central directory, and refuse it. A proper conversion has to peel both layers. The tool inflates the gzip stream to recover the tar archive, then reads the tar to extract every individual file with its folder structure, and finally writes each of those files as its own ZIP entry. The result is a single ZIP that a Windows or macOS user can open with a double click and browse as ordinary folders, with the two Unix-oriented layers dissolved into one universally readable archive.

GZ versus ZIP at a glance

The two formats solve different problems. This table shows where each one fits so you can decide whether the conversion is worth it.

Real-world scenarios and what to expect

Whether the conversion is worth doing depends on what the gz holds and who needs to open it. A few common cases:

The pattern is consistent: convert when a person on a mainstream desktop or phone needs to open the file, and keep the gz when it lives inside a Linux or server workflow that already understands it.

When to keep the GZ instead

If your files stay on Linux servers, in deployment pipelines, or move between developers who already use the command line, GZ and TAR.GZ are the native choice and there is no reason to convert. Web servers also serve gzip transparently, so a .gz asset in that context is doing its job.

Convert to ZIP when the file has to reach someone who just wants to double click and look inside. If you also need to shrink the result before sending it, run the ZIP through the file compressor or trim its contents first. For the reverse direction or other archive types, see the related guides below.