How to Open a .GZ File on Mac
June 23, 2026
A .gz file looks almost identical to a .tar.gz at a glance, but it's a meaningfully different thing — and opening one, or figuring out why it only produces a single file instead of a whole folder, trips people up regularly. Here's the distinction explained clearly, along with exactly how to open one on macOS.
GZ versus TAR.GZ: the key difference
GZIP, the compression algorithm behind the .gz extension, was designed to compress a single file — not to bundle multiple files or folders together the way TAR or ZIP do. When you see a plain .gz file (without "tar" in the extension), it almost always means exactly one file was compressed, and extracting it produces exactly one file back, with the same name minus the .gz extension. This is different from .tar.gz, covered in our separate guide, where TAR handles bundling multiple files first and GZIP compresses that combined bundle afterward. A plain GZIP file has no bundling step at all — it's compression applied directly to a single file's contents, nothing more.
This distinction explains a common point of confusion: someone extracts a .gz file expecting a folder full of contents, the way a ZIP or TAR.GZ typically behaves, and instead gets back just one file. That's not a partial or failed extraction — it's the format working exactly as designed, since there was never more than one file inside to begin with.
Where you'll actually encounter plain GZ files
- Log files — server and application logs are frequently rotated and individually compressed as
.log.gzto save storage space over time - Database dumps — a single large SQL export file, compressed as
.sql.gz, common when migrating or backing up a database - Web server assets — some web infrastructure pre-compresses individual static files with GZIP for faster delivery
- Single large datasets — a lone CSV or JSON data export compressed on its own rather than bundled with anything else
Opening a .gz file on macOS
Double-clicking a .gz file in Finder generally triggers Archive Utility to decompress it automatically, the same native handling that covers .tar.gz — since GZIP decompression is a foundational Unix capability built into macOS at the system level. The decompressed file appears in the same folder, named identically to the original but without the .gz extension.
If double-clicking doesn't produce the expected result, or you want more control (choosing a specific destination, seeing clear progress on a very large single-file compression like a multi-gigabyte database dump), a dedicated archive app handles GZIP the same way it handles every other supported format — with a visible progress indicator and a chosen destination folder, rather than Archive Utility's silent default behavior.
Opening via Terminal
The gzip command-line tool ships with macOS by default, and decompressing a file with it is a single short command:
gzip -d yourfile.gz
The -d flag means decompress. One detail worth knowing: by default, this command replaces the original .gz file with the decompressed version rather than keeping both — if you want to preserve the original compressed file too, add the -k (keep) flag: gzip -dk yourfile.gz.
Creating your own .gz file
To compress a single file with GZIP via Terminal:
gzip -k yourfile.txt
This produces yourfile.txt.gz alongside the original (again, using -k to keep the source file rather than replacing it). Note that GZIP genuinely only accepts a single file as input at the command-line level — trying to point it at a folder will produce an error, since bundling isn't part of what GZIP does. To compress an entire folder, you'd combine it with TAR first, producing a .tar.gz instead, which is the far more common real-world use case for anyone compressing more than one file.
A note on the related .Z format
You may occasionally encounter an even older .Z extension (capital Z, distinct from lowercase .gz), which uses the older Unix "compress" algorithm predating GZIP. It's rare in modern contexts but does still appear in some legacy system exports and older Unix tooling. macOS's built-in gzip command can decompress .Z files as well, using the same gzip -d syntax, since GZIP was designed as a direct successor with backward decompression compatibility for the older format.
A realistic scenario: downloading a database backup
Picture a developer or system administrator downloading a nightly database backup that arrives as customer_data_backup.sql.gz. Double-clicking it in Finder produces exactly one file — customer_data_backup.sql — ready to import directly into a database tool. If that same person mistakenly expected a folder structure (perhaps thinking of it the same way they'd think of a TAR.GZ bundle from a software release), the single-file result can briefly look like something went wrong, when in fact the extraction completed perfectly. This exact mix-up is common enough that it's worth deliberately remembering: no "tar" in the extension means no bundling ever happened, and a single file out is the correct, expected result.
GZIP compression ratios in practice
GZIP was designed decades ago with an emphasis on speed over maximum compression ratio, which is exactly why it remains the default choice for scenarios like real-time web server compression and routine log rotation — situations where compressing and decompressing quickly matters more than shaving off the last few percentage points of file size. For text-heavy content like logs, SQL dumps, or plain-text data exports, GZIP typically reduces file size substantially, often landing in a similar range to what ZIP achieves on comparable content, since both use closely related DEFLATE-family compression under the hood. If squeezing out meaningfully smaller files matters more than speed, formats like 7Z (using LZMA2) or xz-compressed TAR archives generally outperform plain GZIP, at the cost of slower compression — see our guide on getting the best compression results for a deeper breakdown of how different algorithms trade off speed against final size.
Troubleshooting
- Extraction produces only one file when you expected a folder: expected behavior for plain GZIP — check whether the file should actually have been a
.tar.gzinstead, if the sender intended to bundle multiple files - "Not in gzip format" error: the file extension may not match its actual format — verify with a source you trust, since a mislabeled file extension will cause this exact error regardless of which tool you use to open it
- Decompression seems to silently delete the original file: this is GZIP's default behavior (replacing rather than preserving the compressed original) — use the
-kflag in Terminal, or a GUI app that preserves the original by default, if you need to keep both versions
Handling a batch of .gz files at once
It's common to end up with a whole folder of individually-compressed .gz files at once — a week's worth of rotated log files, for instance, each named something like app.log.1.gz, app.log.2.gz, and so on. Finder's built-in extraction handles these one at a time with no batch option, meaning a folder of twenty rotated logs means twenty individual double-clicks. A dedicated archive app with batch extraction support handles the entire folder in one drag-and-drop action instead, decompressing every .gz file in the selection in sequence — considerably faster for anyone regularly working with rotated logs, sharded data exports, or any other workflow that produces many small individually-compressed files rather than one bundled archive.
Frequently asked questions
Can a .gz file contain a password? No — GZIP has no built-in encryption or password support at all, unlike ZIP or 7Z. If you need to protect a single compressed file with a password, compress it as an encrypted ZIP or 7Z instead.
Is .gz the same thing as .zip? No — despite both being compression formats, they work fundamentally differently. ZIP bundles and compresses multiple files together in one unified format; plain GZIP compresses exactly one file with no bundling capability at all.
Why would a log file be compressed individually instead of bundled with other logs? Typically because log rotation systems compress each log file independently as it ages out of active use, making it simple to delete or archive individual dated log files without needing to unpack a larger combined bundle just to access one day's logs.
Recognizing GZIP files by their file signature
If you ever need to verify a file is genuinely GZIP-compressed regardless of what its extension claims — useful when troubleshooting a mislabeled or renamed file — GZIP files always begin with the same two-byte magic number (1F 8B in hexadecimal) at the very start of the file, a detail every properly-implemented decompression tool checks before attempting to process the file. This is why renaming a random file to end in .gz won't trick a competent archive tool into treating it as valid GZIP data; the tool inspects the actual file header, not just the extension, and will correctly reject anything that doesn't match.
The bottom line
A plain .gz file compressing to a single output file isn't a partial extraction — it's the format doing exactly what GZIP was built for. macOS handles basic GZIP decompression natively through Archive Utility or the Terminal gzip command, and for anything beyond the basics — clear progress on large single-file compressions, or working alongside ZIP, RAR, 7Z, and TAR.GZ in one place — Unzipr covers GZIP in the same consistent interface as every other format it supports.