DEV Community

OnePassApps
OnePassApps

Posted on

Create a ZIP in the Browser: The Deflate Ratios and CRC-32 Checksums You Can Check

#zip #javascript #webdev #tools

I work on OnePassApps, so I am writing about a tool we ship. I also ran it and read the finished archive back off disk with unzip, so the numbers below are bytes, not a summary line.

The File Studio's ZIP files tab takes a list of local files and builds files.zip in the tab. The panel is three labelled steps:

  • 01 Source - "0 files · 0 B. Folder names are kept where the browser gives them."
  • 02 Options - a LIMITS block: Files "0 of 500", Total size "0 B of 256 MiB", and Duplicate names "Numbered, e.g. “notes (2).txt”"
  • 03 Result - "Create ZIP builds files.zip from the list on the stage. Your originals stay unchanged."

The stage adds the rest of the contract: "Drop files to add to a ZIP, or browse", "Any files · up to 500 and 256 MiB in total · stays on this device", and the two lines that decide where the work happens - "Nothing leaves this tab." and "Processing stays in this browser."

Two runs, two archives

Run 1 was three files: a 1,200-byte text file, a 55-byte CSV and an 82-byte JSON file. The panel reported "Created one ZIP with 3 files (527 B)", "Created in 0.4 s", "3 of 3 added · duplicate names numbered", and a result line reading "3 files · 527 B · 61% smaller".

Run 2 was five files, including two different files that are both called notes.txt - one 20 bytes, one 39 bytes. The panel reported "5 files · 816 B · 42% smaller" and again "5 of 5 added · duplicate names numbered". On the stage the second one was listed as notes (2).txt, marked "from notes.txt · 39 B".

So the numbering is not cosmetic. Two files with the same name do not overwrite each other and they do not silently join the archive under one entry - the later one is renamed, and the panel says which file it came from.

What unzip says about the archive

unzip -l files.zip:

  Length      Date    Time    Name
---------  ---------- -----   ----
     1200  2026-11-03 09:18   zip-readme.txt
       55  2026-11-03 09:18   zip-notes.csv
       82  2026-11-03 09:18   zip-data.json
       20  2026-11-03 09:18   notes.txt
       39  2026-11-03 09:18   notes (2).txt
---------                     -------
     1396                     5 files
Enter fullscreen mode Exit fullscreen mode

unzip -v files.zip is where the interesting part is:

 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
    1200  Defl:N       42  97% 2026-11-03 09:18 8ae135e7  zip-readme.txt
       55  Defl:N       46  16% 2026-11-03 09:18 7bd5c740  zip-notes.csv
       82  Defl:N       61  26% 2026-11-03 09:18 fb693e74  zip-data.json
       20  Defl:N       22 -10% 2026-11-03 09:18 5269ab0e  notes.txt
       39  Defl:N       39   0% 2026-11-03 09:18 cf936246  notes (2).txt
--------          -------  ---                            ------
    1396              210  85%                            5 files
Enter fullscreen mode Exit fullscreen mode

Three things worth taking from that table:

  1. The 1,200-byte text file shrank 97%, because it was 40 repetitions of one line. The CSV and the JSON barely moved - 16% and 26% - because they are already dense. Compression ratio is a property of the content, not of the tool.
  2. notes.txt grew. Twenty bytes in, 22 bytes stored, -10%. A deflate stream plus a local header is larger than the file it holds, and the table says so instead of hiding it. The same is true of notes (2).txt at 0%: 39 bytes in, 39 bytes out.
  3. Every entry carries a CRC-32 checksum - zip-readme.txt is 8ae135e7. That is the value an extractor verifies per entry, which is why unzip -t can tell you the archive is sound before you trust what came out.

The percentage on the panel is not the percentage in the table

The panel said "42% smaller" and unzip -v said 85%. Both are correct about different things, and it is worth knowing which is which.

The panel compares the whole archive file - 816 bytes on disk - against the total of your inputs, 1,396 bytes. unzip -v compares the compressed entry payloads - 210 bytes in total - against those same 1,396 bytes. The gap between them is the ZIP structure itself: local headers, the central directory and the file names. For five files that is 606 bytes of overhead, which is a lot of overhead for five files.

The practical consequence: a handful of large, compressible files makes the panel's number look modest while the payload really did shrink; many small, already-dense files make the archive mostly headers. If you are packaging hundreds of tiny files, the file count - up to 500 - matters more than the byte total.

What it costs

The plan block next to the tool reads "Standard is free right now", "$0 / month", "100,000 credits every 30 days · No end date set · No card required", and "No automatic paid subscription. Existing paid subscriptions keep their terms." The ZIP work happens on your device, so it does not touch credits at all.

Try it

Open the File Studio, add files, press Create ZIP, then check the result with your own unzip. If you want the wider picture of what runs in the tab and what does not, the guides page has the rest of it.

The same tab, written up as a feature story for Telegram, is here: https://telegra.ph/Create-a-ZIP-in-the-Browser-What-Ends-Up-Inside-fileszip-11-03

Top comments (0)