Is this .gz intact?
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 & FAQDEFLATE — the algorithm inside a gzip file — has no integrity check of its own. Flip one bit in the middle of the compressed data and it usually still decodes: not into an error, but into different bytes than were put in. Every structural tool will walk that stream from end to end and report nothing wrong.
That is precisely why gzip appends a CRC‑32 of the original data and its length to every member, and checking those two values is the only thing that can answer the question. This tab does it: each member is decompressed over its own byte range, folded into a running CRC‑32, compared with what the trailer promised, and thrown away as it goes.
Nothing is retained, so a member far larger than your machine’s memory still verifies — the cost is time and reading, never RAM. The run is cancellable, and a failure names the member, its offset in the file, and both values: what the trailer said, and what the contents actually produce. Nothing is uploaded; a corrupt download is diagnosed on your own machine.
It’s one lens on OmniViewer’s GZ Viewer — Open & Extract Online: drop a file and every tab is one click away. OmniViewer opens every file format, entirely in your browser — no upload, no server.
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.