How to ratio calculator for security & compliance
- Step 1Stage the suspect archive locally — Pull the ZIP from your evidence store, quarantine, or pipeline artifact onto the machine. The tool reads it via the browser File API — nothing transits a network, so chain-of-custody isn't broken by an upload.
- Step 2Open the calculator — Go to /archive-tools/compression-ratio-calculator. Drop a single ZIP. For larger evidence bundles use Pro (500 MB) or Pro-media/Developer (2 GB).
- Step 3Read sizes and methods without extracting — Process. The CSV lists every entry's name, uncompressed size, compressed size, ratio, and method — derived from the central directory only. The archive is never decompressed, so a malicious payload is never run or written to disk.
- Step 4Flag decompression-bomb candidates — Sort by the ratio column. An entry near 99–100% with a small compressed size and a huge uncompressed size is the bomb signature (a few KB expanding to GBs). Treat those entries as hostile until proven otherwise.
- Step 5Note encrypted entries — Entries with method
AESare encrypted — you can see their sizes but not their contents. Record which parts of the bundle are encrypted so the next reviewer knows what needs a password to inspect. - Step 6Attach the report to the case — Download
<archive>-ratios.csvand file it with the case. Pair it with a hash from checksum-generator so the evidence log has both content integrity and a packing profile.
What the report tells a reviewer
Each report field mapped to the security/compliance signal it provides. All read from the central directory — no decompression.
| Report field | Security signal | What to do |
|---|---|---|
name | Unexpected paths, traversal-style names, hidden dotfiles | Cross-check against the expected manifest |
uncompressedSize | An entry far larger uncompressed than the whole download | Possible decompression bomb — do not extract |
ratio near 100% | Tiny compressed → enormous uncompressed | Classic bomb shape; quarantine the entry |
method = AES | That entry is encrypted | Note it; you'll need the password to inspect content |
method = Stored | Entry shipped uncompressed (often a binary/media) | Expected for already-compressed payloads |
SUMMARY ratio | Overall packing profile of the bundle | Compare across versions to spot a packing change |
Tier limits for evidence-sized archives
Pick the tier that covers your largest expected bundle. Size is enforced per job before processing.
| Tier | Max ZIP size | Max entries | Files per job |
|---|---|---|---|
| Free | 50 MB | 500 | 1 |
| Pro | 500 MB | 50,000 | 20 |
| Pro-media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | Unlimited |
Cookbook
Audit-shaped scenarios. Paths and sizes are illustrative.
Decompression-bomb shape in a vendor ZIP
One entry compresses a few kilobytes into gigabytes — the ratio screams it. Because the tool never decompresses, you spot it safely before extraction.
name,uncompressedSize,compressedSize,ratio,method readme.txt,2048,820,60.0%,Deflate payload.bin,4294967295,42000,100.0%,Deflate SUMMARY,4294969343,42820,100.0%, payload.bin: ~42 KB stored, ~4 GB uncompressed = 100.0%. Flag and quarantine. Never extract on the review host.
Identifying which entries are encrypted
An evidence bundle where only some files are protected. The method column tells you exactly what needs a password.
name,uncompressedSize,compressedSize,ratio,method index.json,3200,980,69.4%,Deflate secrets/keys.pem,4096,4144,0.0%,AES secrets/db.dump,1048576,1050200,0.0%,AES SUMMARY,1055872,1055324,0.1%, The AES entries are encrypted; sizes are visible, content is not. Request the password for those two.
Comparing packing profiles across two releases
A vendor's v2 suddenly stores files that v1 deflated. The SUMMARY ratio shift is a flag to ask why the build changed.
v1.0 SUMMARY: ...,74.9%, (mostly Deflate) v2.0 SUMMARY: ...,12.1%, (many entries now Stored) A large drop in overall ratio with the same content means the packing method changed. Worth a question to the supplier before you trust the new build.
Unexpected paths in the entry list
The name column is read straight from the directory, so traversal-style or hidden paths show up for review even though nothing is extracted.
name,uncompressedSize,compressedSize,ratio,method app/main.js,40000,9000,77.5%,Deflate ..\\..\\etc\\cron.d\\evil,120,80,33.3%,Deflate .hidden/installer.sh,5000,1800,64.0%,Deflate Traversal-style and dotfile entries are visible here before any extraction tool touches them.
Pairing the report with a hash for the evidence log
Ratios profile the packing; a checksum proves integrity. Together they make a complete, upload-free record.
Step 1: /archive-tools/compression-ratio-calculator
-> evidence-ratios.csv (entry sizes + methods)
Step 2: /archive-tools/checksum-generator
-> SHA-256 of the archive + per-entry digests
File both with the case. Nothing was uploaded;
nothing was decompressed.Edge cases and what actually happens
Suspect file is a 7z / RAR, not a ZIP
Rejected: not a valid ZIPThis reader is ZIP-only and will reject a 7z/RAR/tar with Not a valid ZIP archive. — by design it doesn't attempt to parse formats it can't read safely. Identify the true format first with auto-format-detector, then use the appropriate inspector.
Encrypted entries in the bundle
SupportedSizes and the AES method are read from the directory without a password, so you can profile an encrypted bundle's structure. Content stays sealed — you cannot read what's inside without the key, which is the correct behaviour for evidence you're not authorised to decrypt.
Decompression bomb
Detected, never detonatedA near-100% ratio on an entry with a huge uncompressed size is the bomb signature. Crucially, the calculator only reads the size field — it never decompresses — so identifying a bomb carries no risk of expanding it. Do not feed flagged archives to an extractor on the review host.
ZIP64 bundle larger than 4 GB per entry
Sentinel sizesThe reader doesn't parse ZIP64 extra fields, so an entry over 4 GB reports the 0xFFFFFFFF sentinel rather than its true size, and the ratio is unreliable for that entry. For forensic accuracy on ZIP64, corroborate with a CLI lister that handles ZIP64.
Archive exceeds the tier size cap
Rejected: tier limitOver the cap you get File "name.zip" exceeds the <tier> tier per-job limit (<size>). Upgrade for larger files. Evidence bundles can be large — Pro (500 MB) or Pro-media/Developer (2 GB) cover most; beyond 2 GB, profile with a CLI.
Truncated / tampered central directory
Invalid / partialIf the central directory was altered or truncated, you may see fewer rows than expected or a Not a valid ZIP archive. error. That discrepancy is itself a signal worth recording. Compare the entry count against the supplier's manifest, and consider corrupted-zip-repair to recover what's salvageable.
Path-traversal or hidden entry names
Visible by designEntry names are read verbatim from the directory (UTF-8, non-fatal decode) and CSV-escaped. Traversal-style (../) or dotfile names appear in the report so a reviewer can catch them before extraction — nothing is written to disk during analysis.
Regulated data that must not leave the boundary
SupportedBecause nothing is uploaded, the regulated boundary doesn't move — analysis is equivalent to running a local CLI on the file. Confirm with your compliance team that local browser processing matches your data-handling policy; most accept it on that basis.
Frequently asked questions
Is the suspect ZIP ever uploaded?
No. It's read locally with the browser File API and parsed in the page. Nothing about its contents leaves the machine — verify in DevTools → Network. This is what makes it safe for evidence and regulated data.
Does it decompress the archive to measure it?
No — and that's the security point. It reads only the central-directory size and method fields, so a malicious payload is never expanded or written to disk. You get structure and sizes with zero detonation risk.
Can it detect decompression bombs?
It surfaces the signature: an entry with a tiny compressed size and a huge uncompressed size shows a near-100% ratio. You read that from the directory without expanding the entry, so spotting a bomb never triggers it. Quarantine flagged entries.
Can I see which entries are encrypted?
Yes. Encrypted entries show method AES in the report. You can see their sizes but not their contents, and you don't need the password just to list them — useful for triaging what requires a key to inspect.
Does it modify or extract the archive?
No. It's strictly read-only — it neither extracts nor rewrites the file. The original archive is untouched, which keeps chain-of-custody intact.
What formats does it support for security review?
ZIP only. For a 7z/RAR/tar you'll get Not a valid ZIP archive.. Detect the real format with auto-format-detector, then use the matching inspector.
How does this fit chain-of-custody requirements?
Pair the ratio report with a SHA-256 from checksum-generator. The hash proves the file is unchanged; the ratio CSV records its packing profile. Neither step uploads or alters the evidence.
Can multiple reviewers work on the same bundle?
Yes — each browser tab is independent with no shared state, and the report is deterministic from the archive, so two reviewers on the same ZIP get identical CSVs. Free tier limits apply per session; Pro lifts them.
Is it acceptable in HIPAA / PCI / FedRAMP environments?
Because nothing transits a network, using the tool doesn't move your regulated boundary — it's equivalent to a local CLI. Confirm local browser processing aligns with your data-handling policy; most teams accept it on that basis.
What if the directory has been tampered with?
You may see fewer entries than expected or a Not a valid ZIP archive. error — both are signals worth logging. Compare the entry count to the supplier's manifest and try corrupted-zip-repair to recover the directory.
How big an evidence bundle can it handle?
50 MB (Free), 500 MB (Pro), 2 GB (Pro-media/Developer), with per-archive entry caps of 500 / 50,000 / 500,000 respectively. The size cap is enforced before processing with a clear error.
Can I run this through automation for a pipeline gate?
There's no public HTTP API; archive tools are browser-only. On Pro+ the same logic can run via the local @jadapps/runner (headless browser). For a server-side CI gate, a CLI lister in the pipeline is the more natural fit.
Privacy first
Every JAD Archive tool runs entirely in your browser using fflate, @zip.js/zip.js, and the libarchive WASM bridge. Your archives never leave your device — verified by zero outbound network requests during processing.