unzippr runs offline · nothing uploads

Drop a zip.
It opens right here.

No upload, no queue, no cartoon animal holding your files. The DEFLATE decompressor is hand-written from the 1996 spec and runs in this tab, so your archive never leaves the machine you're on. Opens .zip, .tar, .gz, .tgz and .tar.gz; packs zips too.

no server behind it every byte checksum-checked v1.1
drop a .zip, .tar, .gz, .tgz or .tar.gz anywhere on this page — it opens in this tab's memory, pulled apart by an engine written here by hand, sent to no server.

How this started: a client sent over a handover zip — contracts, spreadsheets, the sensitive stuff — to a laptop that, thanks to a fresh corporate reimage, had no unzip tool on it at all. Every "unzip online" result wanted the archive uploaded first. Upload the confidential file. To a page with a cartoon animal and no surname behind it. I did it the ugly way that night (mailed it to an older machine), then spent a week reading how a zip is actually built: an index at the tail, a checksum on every file, and one openly published compression method from 1996. So this page exists. The decompressor is written straight from that document, checked byte-for-byte against the reference tool, and there is nowhere to upload anything because there is no server behind the page.

— just me, the one who got tired of the upload button

Four moves, drop to done

start to finish, no waiting screen

  1. Read the index. A zip keeps its table of contents at the very end — names, sizes, dates, checksums — and it's shown to you before a single byte gets unpacked.
  2. Pull it open in the tab. The decompressor rebuilds each file from its Huffman codes and back-references — the same math your desktop tool runs, just running here.
  3. Check the receipts. Each file is recomputed against the checksum the packer stamped — the ✓ in the last column is measured, not painted on.
  4. Take the files. One tap downloads a single file; "unzip everything" writes the whole tree into a folder you choose (Chrome and Edge), structure and all.

What it won't touch, and says why

limits stated up front, not discovered later

Pull log

newest pull first

v1.1
tar, gz, tgz and tar.gz now open through the same hand-written inflate — gzip streams checked against their trailing CRC-32 and length, tar members against their header sums. preview learned to say "binary, download to open" honestly, and a dropped folder packs into a store-method zip with every path kept.
v1.0
the open and make benches, a live checksum badge per file, text and image preview, unzip-to-folder, unicode names in both directions.
v0.9
the engine's proving run: 200 random buffers at all nine zlib levels, byte-identical every time; Python's strict zipfile accepts my writer's output whole. proof pinned to the wall.

Asked over the bench

the questions that actually come in

Why hand-write DEFLATE when the browser ships DecompressionStream?

Because that API inflates a raw stream, but a zip is a container of many entries with headers, offsets and checksums that something still has to parse — and once you're parsing the container honestly, owning the decompressor means every byte's path is code I can stand behind. (Making a zip does lean on the browser's CompressionStream — the right tool right where it fits.)

A row shows ✗ and a failed checksum — now what?

That entry is damaged — a truncated download, a disk blip, or a bad copy made years ago. Re-fetch the zip if you can; if not, the other files' ✓ marks still hold (each entry is independent), and the broken one is honestly past any opener's help.

Do Mac-made zips open cleanly?

Yes — including the __MACOSX folders macOS tucks inside (shown plainly; take them or ignore them) and UTF-8 filenames. Windows zips with legacy encodings get the old-codepage reading, which clears the usual garbled characters.

Which archive formats does it actually speak?

ZIP, TAR, GZ, TGZ and TAR.GZ — all through the one hand-written DEFLATE engine, because gzip and zip share the same compression underneath and tar is just an uncompressed box of headers. RAR and 7z are a different answer: proprietary or separate compressors that would each be their own engine, so pretending would only earn distrust. This does the family it can vouch for, byte by byte.

Why does a tar row show a header check, not a checksum?

Because that is all tar carries. A ZIP stamps a CRC-32 per file and gzip stamps one over the whole stream — both get recomputed and shown. Tar's header holds a sum over the header itself, no per-file data digest, so it verifies what exists and labels it honestly rather than inventing a green tick the format never promised.

Notes from the workshop

longer reads, written up between builds

DEFLATE, by hand Huffman trees, back-references and the twenty-page 1996 document that quietly runs the world's archives — what I learned writing it from scratch. The upload you didn't notice "Unzip online" sites and the confidential files that pass through them — an audit of where your archives actually go. Anatomy of a ZIP Local headers, the table of contents at the tail, and why a zip's index lives at the end — a tour of the container.