Read a ZIP byte by byte.
safe · secure · no server · works offline · fast
…or just start typing at the cursor.
↓ scroll for about & FAQsafe · secure · no server · works offline · fast
…or just start typing at the cursor.
↓ scroll for about & FAQ
Drop a .zip and OmniViewer shows its bytes in
hexadecimal with file offsets and an ASCII panel. It is the tool
for the cases where the structure itself is the question: locate the
50 4B 03 04 local headers and the 50 4B 01 02 central
directory records, read the End of Central Directory record at
the tail, check whether an archive is truncated mid‑member, or find the
bytes appended after the archive ends.
The view is windowed — only the bytes needed to paint your screen are read — so it opens a 20 GB archive as readily as a small one. You can highlight byte ranges in four colours to mark up a structure you are working out. The same drop also lists every entry, audits the archive, and reports stats.
It’s one lens on OmniViewer’s ZIP Viewer — Browse & 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 archive is read directly by your browser, and every tab — entries, audit, stats and hex — runs locally in a Web Worker. The archive never leaves your computer, and neither does any file you extract from it.
Yes, and that is the point. The archive tells OmniViewer exactly where each member starts, so a preview or download reads only that entry’s compressed byte range, decompresses it with the browser’s built-in DEFLATE decompressor, and checks the CRC-32 the archive recorded. The other members are never touched, so pulling one file out of a 20 GB archive is as fast as pulling it out of a small one.
Effectively unlimited. Listing an archive needs only its index: a tail read to find the End of Central Directory record and one read of the central directory it points at — roughly 46 bytes plus the path per member. The compressed contents are never read, so the cost scales with the number of entries, not the size of the file. ZIP64 archives past 4 GB and past 65,535 entries are handled.
Yes. All of those are ZIP archives with a different extension and some required members inside, and OmniViewer detects them from their first four bytes rather than their name. Drop a .docx and you can browse to word/document.xml and read it inline; drop an .apk and you can see AndroidManifest.xml, classes.dex and the resources; drop an .epub and you get its chapters. Same for .war, .ipa, .whl, .xpi, .crx and .nupkg.
An entry name inside a ZIP is an arbitrary string that extractors treat as a file path, and nothing in the format stops it being "../../../etc/cron.d/backdoor". An extractor that joins the output folder with that name writes outside the folder — that is zip slip. The AUDIT tab flags any entry with a ".." segment, an absolute or drive-qualified path, or a backslash separator (which slips past sanitizers that only look for forward slashes), and lists the exact entries, so you know before you extract.
Yes, from the index alone. Every entry declares its uncompressed size, so the expansion is visible before anything is decompressed. The AUDIT tab flags entries that expand by more than several hundred times — ordinary data never does, but a run of one repeated byte compresses about 1030:1 — and flags an archive whose total declared output dwarfs its size on disk. It also reports entries whose offsets overlap, which is how the modern non-recursive bombs reuse one payload many times.
A ZIP stores every member’s metadata twice: once in a local header before the compressed bytes, once in the central directory at the end. Almost every tool lists from the central directory, but some extract using the local header — so a deliberate mismatch can show a scanner one file and an extractor another. This was the basis of the Android "Master Key" and Janus bugs. OmniViewer cross-checks a sample of entries and reports any disagreement in name, method, CRC or size.
It can list one but not decrypt it. A ZIP encrypts member contents, never its table of contents, so the names, sizes and structure are always readable and the AUDIT tab reports which entries are encrypted and whether they use modern WinZip AES or the legacy, cryptographically broken ZipCrypto. Extracting an encrypted entry is not supported.
Stored (uncompressed) and DEFLATE, which together cover essentially every ZIP in the wild — DEFLATE is method 8 and is what over 95% of real entries use. Those two work because the browser ships a DEFLATE decompressor natively, so no compression library is needed. Entries using bzip2, LZMA, XZ, PPMd or Zstandard are listed in full with all their metadata, but marked as not extractable here.
Yes. A folder in a ZIP is only an optional zero-length member whose name ends in a slash, and plenty of archives omit them entirely — a member called src/lib/util.js with no entry for src/ at all. OmniViewer builds the tree from the path segments, so you always get a real folder view, and it rolls file counts and sizes up through the folders.