Drop a .gz. See inside it.
safe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQsafe · secure · no server · works offline · fast
…or paste a file you copied in Finder, or just start typing at the cursor.
↓ scroll for about & FAQ
A .gz is a wrapper, and the only question anyone opening one
really has is what is inside it? OmniViewer answers that first: it
decompresses a small prefix, reads the payload’s own first bytes, and
tells you it is a tar archive, a JSON document, a CSV, a log, a PDF. If that
payload has a toolkit of its own, one click hands it over — a
metrics.json.gz opens with the whole JSON toolkit behind it, and
a breadcrumb back to the archive. There is no upload and no server, and the
heavy work runs in a background Web Worker so the page never freezes.
Underneath that, the file is shown as what it actually is: a chain of
members. A gzip file is one or more complete, independent
gzip streams laid end to end — cat a.gz b.gz > both.gz
is a perfectly valid file — and each carries a header with the original
filename, the modification time and the machine that wrote it, and a trailer
with a CRC‑32 and a length.
.tar.gz, the archive inside, as a real folder tree with sizes, unix permissions, owners and dates. Any file can be previewed inline (text and images), downloaded, or handed to OmniViewer’s own format detection so a site.yaml inside the backup gets the YAML toolkit. The tab appears only when the payload really is a tar.
A ZIP keeps a directory at its tail; a Parquet file keeps a footer; an MP4
keeps a moov atom. A gzip file keeps nothing. There is
no table of contents, no offset list, and no record of where a member ends
— the only way to find that out is to walk the compressed bitstream
until it says it is finished. That single fact is why gzip cannot
seek, why it cannot be decompressed in parallel, and why almost no in‑browser
tool will open a big one.
OmniViewer’s answer is a DEFLATE walker that decodes the Huffman symbols
without reconstructing the output: a match is 258 bytes it accounts
for with one addition and then forgets, so there is no 32 KB history
window and no output buffer, and peak memory is three small tables whatever
the file weighs. The common single‑member case does not even need it —
the header is at the front and the CRC‑32 and length are the file’s
last eight bytes, so a 20 GB .gz reports both instantly.
Inside a gzip file
walks the whole structure with the field tables, the bit‑level decoder and real parsing code.
OmniViewer opens every file format; the gzip toolkit sits alongside the other archive tools — including the ZIP viewer, which is the same job on the format that does have an index — powered by the same viewing engine as fastjsonviewer.com and hugecsv.com.
No. OmniViewer is a static page with no server-side processing: your file is read directly by your browser, and every tab — members, entries, blocks, verify and stats — runs locally in a Web Worker. The file never leaves your computer, and neither does anything you extract from it.
It decompresses just the beginning. The first 64 KB of output is enough to read a tar header, match every magic number worth knowing, and tell text from binary, so the payload is identified from a tiny fraction of the work. Everything else is read from the header at the front of the file and the eight-byte trailer at the end.
Effectively unlimited. A single-member file — which is almost all of them — costs two small reads to describe: the ten-byte header at the front, and the last eight bytes of the file, which are always the final member’s CRC-32 and uncompressed size. The member walk and the block map stream in one-megabyte blocks and hold no history, so memory does not grow with the file. Only the automatic walk is bounded, and a button runs the whole-file pass when you want exact figures.
Yes. When the payload turns out to be a tar archive, an ENTRIES tab appears with the whole archive as a folder tree, and any file in it can be previewed, downloaded, or opened in the toolkit for its own format. Listing reads only the 512-byte headers — the file contents between them are counted past and never held — so the cost scales with how many entries the archive has, not how big it is.
Because the format is defined as a stream, not a container. A gzip file is a sequence of complete, independent gzip members, and a decompressor simply reads them one after another — which means concatenating two .gz files with cat produces a valid third one. Tools exploit this deliberately: bgzip and pigz -b compress in independent blocks so a reader can jump into the middle of a file, which is how a multi-gigabyte BAM can be indexed at all.
The DEFLATE stream itself. Inside a gzip member the compressed data is a sequence of blocks, and for each one the compressor chose a strategy: stored (the bytes verbatim, when compressing them would make them bigger), fixed Huffman (a built-in code table, cheap for short data), or dynamic Huffman (a code table computed for these bytes and written out in front of them). The tab lists each block with its type, its offset in bits, the bytes it costs, the bytes it produces and its own ratio — so you can see exactly where a file compressed well and where it did not.
Because DEFLATE is a bit stream, not a byte stream. A block header is three bits, Huffman codes are between one and fifteen bits, and nothing realigns to a byte boundary except a stored block and the end of the final block. So the second block in a file almost never starts on a byte — its true position is a bit offset, and rounding that to bytes would be a lie about where it is.
No, and this is the single most useful thing to know about the format. DEFLATE has no integrity check inside it. A flipped bit in the compressed data usually still decodes — into different bytes than were put in — and the walk finishes normally. That is exactly why gzip appends a CRC-32 of the original data and its length to every member, and why the VERIFY tab exists: it decompresses everything and checks those two values, which is the only thing that can actually answer the question.
Yes. Detection is by content, not by name: any file starting with the bytes 1f 8b opens in this toolkit, whatever it is called. The .tgz, .taz and .gzip spellings all resolve to the same app, and a .tar.gz needs no special handling because the last extension is the one that counts.
Because the size field in a gzip trailer is only 32 bits, so it records the uncompressed length modulo 4 GB. A file that unpacks to 5 GB honestly reports 1 GB, and every tool reading that field has the same problem — gzip -l included. OmniViewer says so when it sees it, and the whole-file walk on the MEMBERS tab computes the true size by summing what the DEFLATE symbols actually produce, which has no such ceiling.
They share a compression algorithm and nothing else. Both use DEFLATE for the actual squeezing, but a ZIP is an archive format — many files, each compressed separately, with a directory at the end listing where they all are — while gzip compresses exactly one stream and stores no index at all. That is why a .tar.gz needs tar to hold the files and gzip to compress them, and why you can pull one file out of a ZIP instantly but not out of a .tar.gz.