Look inside a .tar.gz.
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
Drop a .tar.gz or .tgz and OmniViewer streams it
through the browser’s own decompressor, reads the tar headers as they
come past, and shows the archive as a real folder tree.
Every file arrives with its size, its unix permissions, its owner and its
timestamp, and you can filter thousands of paths down to the one you want.
Click preview on any entry and it is pulled out on the spot —
text and images show inline, so you can read a config file or check a log
without saving anything. Open hands that file to OmniViewer’s
own format detection instead, so a site.yaml inside a backup
gets the whole YAML toolkit and a breadcrumb back to the archive.
Nothing is uploaded and nothing is written to disk unless you ask for it.
A ZIP stores a directory at the end of the file, so any member can be found
instantly. A .tar.gz cannot: the tar’s own headers are
inside the compressed stream, so reaching the last one means
decompressing everything before it. There is no shortcut, in this tool or
any other — what OmniViewer does is refuse to hold any of it. Only the
512‑byte headers are read; the file contents between them are counted
past and dropped, so listing an archive costs time proportional to its size
but memory proportional to nothing at all.
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.