How to archive size analyser online for free
- Step 1Open the tool — Visit /archive-tools/archive-size-analyzer. No account is required to run the free tier. The page loads the fflate reader immediately and lazy-loads libarchive WASM only if your archive is a format fflate cannot read (7z/RAR/bz2/xz).
- Step 2Drop one archive — Drag a single archive onto the dropzone, or click to browse. This tool reads ONE archive at a time — it is not a batch tool. Supported readable formats: ZIP, TAR.GZ, GZIP, 7z, RAR, bz2, xz, TAR. The format is detected from magic bytes, not the extension, so a mis-named
.zipthat is really a 7z is still read correctly. - Step 3Let it validate the tier limit — Before processing, the file is checked against your tier: Free rejects anything over 50 MB or 500 entries. If your archive is larger you will see a tier-limit error rather than a partial result.
- Step 4Run the analysis — Click Process. fflate walks the ZIP/TAR.GZ central directory and sums each entry's uncompressed size into the extension map and the top-folder map. For 7z/RAR/bz2/xz the archive is read through libarchive and each entry's expanded byte length is summed instead.
- Step 5Read the on-screen result — The metric pills show 'Distinct extensions' and 'Top folders'. The preview shows the JSON:
byExtension(each row is{ ext, count, totalSize }) andbyTopFolder(each row is{ folder, count, totalSize }), both sorted bytotalSizedescending. The biggest group is the first array element. - Step 6Copy or download the report — Use Copy to grab the JSON into your clipboard, or Download to save
<name>-size-analysis.jsonlocally. Drop it into a spreadsheet, a ticket, or a follow-up tool — there is no server round-trip at any step.
What the report contains
The exact JSON shape the Size Analyser emits. There are no configurable options for this tool — the schema is empty, so every run produces the same structure.
| Field | Type | Meaning |
|---|---|---|
byExtension | Array of { ext, count, totalSize } | One row per distinct lowercase extension, e.g. { "ext": "png", "count": 412, "totalSize": 88412160 }. Sorted by totalSize descending. Files with no dot map to (no extension). |
byTopFolder | Array of { folder, count, totalSize } | One row per top-level path segment. assets/logo.png rolls into assets; a file at the archive root rolls into (root). Sorted by totalSize descending. |
total | Number | Total entry count counted (directory entries are skipped, so this is files only after the directory filter in most ZIPs). |
count | Number (per group row) | How many files fell into that extension or folder group. |
totalSize | Number (per group row) | Sum of UNCOMPRESSED bytes for that group. For plain ZIP this is read from the central directory; for 7z/RAR/bz2/xz it is the expanded byte length after libarchive reads the entry. |
Free vs paid limits (archive family)
Real per-tier caps for the archive tool family from the tier-limits table. Note the per-archive ENTRY-COUNT cap, not just the byte cap — a small ZIP with thousands of tiny files can hit the entry limit before the size limit.
| Tier | Max archive size | Max entries | Files per run |
|---|---|---|---|
| Free | 50 MB | 500 | 1 |
| Pro | 500 MB | 50,000 | 20 |
| Pro-Media | 2 GB | 500,000 | 100 |
| Developer | 2 GB | 500,000 | unlimited |
| Enterprise | unlimited | unlimited | unlimited |
Formats this tool can READ
Detected by magic bytes, not file extension. ZIP, GZIP, and TAR.GZ use fflate (fast, no full decompression for ZIP directory reads); the rest are routed through libarchive WASM, which fully decompresses to measure each entry.
| Format | Engine | How size is measured |
|---|---|---|
| ZIP | fflate | Uncompressed size read straight from the central directory — no payload decompression |
| TAR.GZ / GZIP | fflate | Entry sizes parsed from the TAR/gzip stream |
| 7z | libarchive WASM | Each entry fully decompressed; expanded byte length summed |
| RAR | libarchive WASM | Each entry fully decompressed; expanded byte length summed |
| bz2 / xz | libarchive WASM | Decompressed and measured by expanded length |
| TAR (plain) | fflate / libarchive | Entry sizes from the TAR headers |
Cookbook
Realistic before/after runs. The Size Analyser takes no options, so each recipe is about reading the report, not configuring the tool.
Find the dominant file type in a design archive
A 480 MB project ZIP feels heavy. The byExtension rollup shows the PSDs are the entire problem — 92% of the bytes in 38 files.
Input: project-final.zip (480 MB, 1,204 entries)
Report (byExtension, top rows):
[
{ "ext": "psd", "count": 38, "totalSize": 461373440 },
{ "ext": "png", "count": 802, "totalSize": 26214400 },
{ "ext": "svg", "count": 311, "totalSize": 4194304 },
{ "ext": "(no extension)", "count": 53, "totalSize": 131072 }
]
Read: 38 PSD files = ~440 MB. Strip or externalise the PSDs
and the archive drops to ~30 MB.Spot the heavy top-level folder
The byTopFolder rollup answers 'where', not 'what'. Here a vendored dependency tree is 70% of the archive.
Input: release-bundle.zip (210 MB)
Report (byTopFolder, top rows):
[
{ "folder": "node_modules", "count": 9981, "totalSize": 154140672 },
{ "folder": "dist", "count": 142, "totalSize": 41943040 },
{ "folder": "assets", "count": 88, "totalSize": 12582912 },
{ "folder": "(root)", "count": 7, "totalSize": 65536 }
]
Read: node_modules should not ship in a release bundle —
exclude it before zipping.Files at the archive root vs in folders
Entries with no slash in their path roll into the (root) group, so you can see how much sits loose at the top level.
Input: mixed.zip
Report (byTopFolder):
[
{ "folder": "data", "count": 40, "totalSize": 10485760 },
{ "folder": "(root)", "count": 3, "totalSize": 5242880 }
]
Read: 3 loose files at the root account for 5 MB —
likely a stray export that belongs in a subfolder.Analyse a 7z without 7-Zip installed
fflate cannot read 7z, so the tool routes it through libarchive WASM. The byExtension report is identical in shape — only the engine differs.
Input: backup.7z (detected by magic bytes 37 7A BC AF 27 1C)
Engine: libarchive WASM (fflate cannot read 7z)
Report (byExtension, top rows):
[
{ "ext": "sql", "count": 1, "totalSize": 314572800 },
{ "ext": "log", "count": 24, "totalSize": 52428800 }
]
Note: for 7z the totalSize is the DECOMPRESSED size of each
entry, summed — not the on-disk compressed size.Hand the JSON to a spreadsheet
The report is plain JSON arrays — paste byExtension into a converter or spreadsheet to chart it yourself, since this tool does not draw the chart for you.
Download: release-bundle-size-analysis.json byExtension -> spreadsheet columns: ext | count | totalSize node_modules sub-types become visible once you add a 'totalSize / 1048576 = MB' column. Tip: pair with /archive-tools/file-type-breakdown when you want COUNTS per type rather than BYTES per type.
Edge cases and what actually happens
Archive over 50 MB on Free
Tier limit (rejected)Free caps every archive at 50 MB. A larger file is rejected before analysis with a tier-limit error — there is no partial breakdown. Upgrade to Pro (500 MB) or Pro-Media (2 GB), or split the archive first with /archive-tools/archive-splitter and analyse a part.
Archive over 500 entries on Free
Tier limit (rejected)The archive family enforces an entry-count cap as well as a byte cap. A 5 MB ZIP that contains 9,000 tiny files exceeds the Free 500-entry limit even though it is well under 50 MB. Pro raises the entry cap to 50,000.
totalSize is uncompressed, not on-disk
By designEvery totalSize is the sum of UNCOMPRESSED bytes per group. A folder of already-compressed JPEGs will show its real expanded size, which is close to its on-disk size; a folder of plain text will show a number far larger than what it occupies inside the ZIP. If you want compressed-vs-uncompressed ratios, use /archive-tools/compression-ratio-calculator instead.
Directory entries are skipped
By designExplicit directory entries (paths ending in /) are filtered out before grouping, so they do not appear in byExtension and do not inflate total. Only files are counted. A folder still shows up as a byTopFolder group because grouping is by the first path segment of each file.
Files with no extension
PreservedAn entry like LICENSE or Makefile has no dot, so it is grouped under (no extension). A dotfile like .gitignore has gitignore as its 'extension' under the simple split-on-dot rule, so it lands in a gitignore group rather than (no extension).
Nested archives are not opened
Counted as one entryA ZIP that contains an inner assets.zip counts that inner archive as a single zip entry at its own size — the analyser does not recurse into it. To break down a nested archive, extract it first with /archive-tools/nested-archive-extractor, then analyse the inner ZIP.
Encrypted ZIP entries
Supported (sizes only)The central-directory read still reports each entry's name and uncompressed size even when the payload is encrypted, so the size breakdown works without the password. To confirm whether an archive is encrypted, use /archive-tools/encrypted-archive-detector.
Mis-named file (wrong extension)
Handled by magic bytesFormat is detected from the file's leading bytes, not its name. A report.zip that is actually a 7z is read by libarchive correctly. If detection returns 'unknown' the file is treated as a libarchive candidate; a non-archive file then fails to parse with a format error.
Only top-level folders are grouped
By designbyTopFolder uses just the FIRST path segment, so src/components/Button.tsx and src/utils/x.ts both roll into src. You cannot see per-subfolder totals from this tool. For a flat per-extension count, file-type-breakdown is the companion.
No chart is drawn
Report onlyDespite older copy mentioning a bar chart, the live tool returns a JSON report plus metric pills (distinct extensions, top folders) — it does not render a visual chart. Sort and chart the downloaded JSON in your own spreadsheet if you need a graphic.
Frequently asked questions
Does the Size Analyser upload my archive?
No. fflate and libarchive WASM run inside your browser tab. Open DevTools, Network, while processing — you will see zero outbound requests carrying your data. The only thing that may touch the network is a one-time fetch of the libarchive WASM module the first time you analyse a 7z/RAR/bz2/xz.
What is the maximum archive size and entry count?
Free: 50 MB and 500 entries. Pro: 500 MB and 50,000 entries. Pro-Media: 2 GB and 500,000 entries. Developer: 2 GB and 500,000 entries. Enterprise: unlimited. Both the byte cap AND the entry cap apply — a small archive with thousands of files can hit the entry limit first.
Which formats can it read?
ZIP, TAR.GZ, and GZIP via fflate; 7z, RAR, bz2, and xz via libarchive WASM; plain TAR too. Format is detected from magic bytes, so a renamed archive still works. It is a read-only analysis tool — it does not create or convert archives.
Are the sizes compressed or uncompressed?
Uncompressed. Each group's totalSize is the sum of expanded byte sizes. For plain ZIP that figure is read from the central directory without decompressing; for 7z/RAR/bz2/xz the entries are decompressed by libarchive and the expanded length is summed. For compressed-vs-uncompressed ratios use the Compression Ratio Calculator.
What output do I get?
A JSON report named <archive-name>-size-analysis.json containing byExtension, byTopFolder, and total. On screen you also get metric pills for 'Distinct extensions' and 'Top folders'. You can Copy the JSON or Download the file. There is no CSV output and no bar chart from this tool.
How is this different from File Type Breakdown?
File Type Breakdown counts ENTRIES per extension; Size Analyser focuses on BYTES per group and adds top-level folder rollups. Use both — they answer different questions. Find it at /archive-tools/file-type-breakdown.
Does it find duplicate files?
No. Grouping is by name/extension and folder only. To detect actual byte-identical duplicates, use /archive-tools/redundancy-analyzer, which hashes entries with SHA-256.
Can I analyse several archives at once?
Not with this tool — it reads one archive per run. The Free tier allows one file anyway. For a multi-archive size summary use /archive-tools/batch-compression-report, which accepts many archives on paid tiers.
Does it recurse into nested archives?
No. An inner data.zip inside the archive is counted as one zip entry at its own size. Extract it first with /archive-tools/nested-archive-extractor, then run the analyser on the inner archive.
Why does a subfolder not show up separately?
Folder grouping uses only the first path segment, so src/a/b.ts and src/c/d.ts both count under src. This tool gives you top-level rollups, not a full directory tree.
Which browsers work?
Any browser with WebAssembly: Chrome, Edge, Firefox, Safari, Brave, Opera, plus mobile Chrome and Safari. Very large archives may exceed device memory on mobile, especially 7z/RAR where libarchive must fully decompress.
Can I run this in CI or via an API?
Today the tool is a standalone browser page. The closest scriptable equivalents are fflate (Node) for ZIP/TAR.GZ directory reads and libarchive bindings for 7z/RAR. JAD wraps all of them behind this one UI; programmatic access is on the roadmap.
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.