How to size analyser in developer workflows
- Step 1Triage a size regression — When a release ZIP jumps in size, drop it into /archive-tools/archive-size-analyzer and read
byExtension[0]/byTopFolder[0]. The biggest group is the regression — often a new dependency, an un-stripped source map, or a media file that crept in. - Step 2Review a PR's artifact without checking out — If a PR attaches or produces an archive, drop it here instead of checking out the branch and rebuilding. You see what changed in composition in seconds — faster than a local build.
- Step 3Decide what to exclude before zipping — Before you ship, analyse the candidate archive. A
byTopFolderrow fortest,.git, ornode_modulesis a list of things to add to your.npmignore/ build-exclude config, then rebuild. - Step 4Compare two builds by reading both reports — Run the analyser on the old and new artifacts and diff the two JSON reports in your editor. The group whose
totalSizejumped is the answer. For an entry-level diff of what files changed, use /archive-tools/archive-diff. - Step 5Confirm ratios and duplicates with siblings — Size Analyser shows uncompressed bytes per group. To see how well each type compresses, follow up with /archive-tools/compression-ratio-calculator; to find byte-identical duplicate assets, use /archive-tools/redundancy-analyzer.
- Step 6Save the report into the PR or ticket — Download
<artifact>-size-analysis.jsonand paste the relevant rows into the PR description as evidence: 'this tag added 40 MB of source maps under dist/'. The JSON is plain and reviewer-friendly.
Common developer questions, mapped to the report
What you read out of byExtension / byTopFolder for each everyday triage question. The tool has no options — it is purely about reading the right field.
| Question | Field to read | What 'good' looks like |
|---|---|---|
| Why did the release ZIP grow? | byExtension[0] and byTopFolder[0] | The biggest group should be your actual build output, not deps or maps |
| Did we ship source maps? | byExtension -> map group | Absent (or zero count) in a production artifact |
| Did node_modules sneak in? | byTopFolder -> node_modules | Absent in a release bundle |
| Are there loose files at the root? | byTopFolder -> (root) | Small or expected (e.g. a single README/manifest) |
| How many distinct file types? | 'Distinct extensions' pill | Stable across builds; a jump signals new artefact types crept in |
Where Size Analyser fits among archive sibling tools
Pick the right tool for the question. Size Analyser answers 'what is taking the bytes'; the others answer adjacent questions.
| I want to know... | Use | Why |
|---|---|---|
| Which file type / folder is biggest (bytes) | archive-size-analyzer | Groups uncompressed bytes by extension and top folder |
| How many entries per type (count) | /archive-tools/file-type-breakdown | Count-oriented, complements the byte view |
| How well it compresses (ratio) | /archive-tools/compression-ratio-calculator | Compressed vs uncompressed per file and overall |
| Are there duplicate files | /archive-tools/redundancy-analyzer | SHA-256 hash to find byte-identical entries |
| What entries changed between two builds | /archive-tools/archive-diff | Entry-level before/after comparison |
| Size summary across many archives | /archive-tools/batch-compression-report | Accepts multiple archives (paid tiers) |
Cookbook
Developer-shaped runs. Sizes are uncompressed bytes; the tool sorts each group descending for you.
Track down an 80 MB release regression
The new tag is 80 MB heavier. byExtension puts the source maps right at the top.
Old tag: app-1.4.0.zip (110 MB)
New tag: app-1.5.0.zip (190 MB)
app-1.5.0 byExtension[0..1]:
{ "ext": "map", "count": 132, "totalSize": 83886080 }
{ "ext": "js", "count": 132, "totalSize": 73400320 }
Read: 80 MB of newly-added source maps. The build started
emitting .map in production. Strip them and rebuild.node_modules shipped in a release bundle
byTopFolder shows a vendored dependency tree that should have been excluded.
Artifact: service-release.tar.gz
byTopFolder:
{ "folder": "node_modules", "count": 12044, "totalSize": 178257920 },
{ "folder": "dist", "count": 96, "totalSize": 20971520 }
Read: node_modules is 170 MB of the 190 MB artifact.
Add it to the build-exclude and ship dist/ only.Diff two builds by reading both reports
Run the analyser on both artifacts, diff the JSON. The group that jumped is the cause.
git checkout-free comparison:
v2.0-size-analysis.json media: 4 MB
v2.1-size-analysis.json media: 96 MB <- jumped
byTopFolder diff (media folder):
v2.0 { "folder": "media", "totalSize": 4194304 }
v2.1 { "folder": "media", "totalSize": 100663296 }
For an entry-level diff of WHICH files changed:
/archive-tools/archive-diffOpen a 7z artifact on a fresh CI runner
A colleague hands you a .7z and your machine has no 7-Zip. libarchive WASM reads it in-browser.
Artifact: build-cache.7z
Local: 7z -> not installed
Analyser (engine: libarchive WASM):
byExtension[0] = { "ext": "o", "count": 3120, "totalSize": 262144000 }
Read: object files dominate the build cache. Expected for a
compile cache; not something to ship in a release.Confirm what compresses vs what does not
Size Analyser shows uncompressed bytes; pair with the ratio tool to see what is worth compressing.
archive-size-analyzer (uncompressed bytes): json: 60 MB png: 40 MB compression-ratio-calculator follow-up: json -> ~12% of original (compresses well) png -> ~99% of original (already compressed) Read: the JSON is the bloat worth keeping zipped; the PNGs are near-incompressible, so re-zipping them is a no-op.
Edge cases and what actually happens
Tool takes no options
By designThe Size Analyser's option schema is empty — there are no sort, filter, or grouping toggles. Output is always grouped by extension and top-level folder, sorted by totalSize descending. This makes runs deterministic and review-safe but means you cannot, for example, ask it to group by a deeper path.
Sizes are uncompressed, not the ZIP's on-disk footprint
By designA byExtension totalSize of 60 MB for JSON might compress to 7 MB inside the ZIP. If you are reasoning about download size rather than expanded size, follow up with /archive-tools/compression-ratio-calculator — the analyser deliberately reports uncompressed bytes.
Only top-level folders are rolled up
By designsrc/app/x.ts and src/lib/y.ts both count under src. You cannot see per-subfolder totals here. For deep-tree analysis, extract and use a disk tool, or diff entry-by-entry with /archive-tools/archive-diff.
Nested artifact not opened
Counted as one entryAn inner assets.zip counts as a single zip entry at its own stored size, without recursion into its contents. Extract it first with /archive-tools/nested-archive-extractor to break down the inner archive.
Artifact over the tier cap
Tier limit (rejected)Free rejects over 50 MB or 500 entries; Pro over 500 MB or 50,000 entries. CI artifacts frequently exceed Free — use Pro for typical release bundles, or split with /archive-tools/archive-splitter for very large ones.
Dotfiles grouped oddly
ExpectedExtension grouping splits on the last dot. .gitignore becomes the gitignore group, not (no extension); app.min.js becomes js. If your report shows a surprise gitignore or env group, it is a dotfile being treated as that extension.
One archive per run
By designThis tool reads a single archive at a time, so you cannot drop a folder of builds and get a combined report. For a size summary across many archives use /archive-tools/batch-compression-report on a paid tier.
Mis-named artifact
Handled by magic bytesFormat is detected from content, so a build.zip that CI actually wrote as a 7z still analyses via libarchive. If detection cannot identify the format it is treated as a libarchive candidate and a non-archive then fails with a format error.
No CLI/API yet
RoadmapThere is no programmatic endpoint today — it is a browser page. The scriptable equivalents are fflate (Node) for ZIP/TAR.GZ directory reads and a libarchive binding for 7z/RAR. JAD wraps both behind this UI.
Report is JSON, no chart
Report onlyOutput is a JSON report (byExtension, byTopFolder, total) plus metric pills. There is no rendered chart in the tool — paste the JSON into a spreadsheet if you want a graphic for a PR.
Frequently asked questions
Is there a CLI or API equivalent?
Not yet — the tool is a browser page. The closest scriptable equivalents are fflate (Node) for ZIP/TAR.GZ central-directory reads and a libarchive binding for 7z/RAR. JAD wraps all of them behind this one UI; programmatic access is on the roadmap.
Can I configure how it groups?
No. The option schema is empty. It always groups by lowercase extension and by top-level folder, sorting each group by total uncompressed bytes descending. That determinism is intentional — there is nothing to misconfigure.
How do I find why my release ZIP grew?
Drop it in and read byExtension[0] and byTopFolder[0] — the biggest groups. A jump usually traces to a new dependency tree, un-stripped source maps, or a media file that crept in. Compare with the previous artifact's report to confirm.
Can I diff two builds?
Run the analyser on both and diff the two JSON reports in your editor — the group whose totalSize jumped is the cause. For a true entry-level before/after of which files changed, use /archive-tools/archive-diff, which is built for two-archive comparison.
Does it count compressed or uncompressed bytes?
Uncompressed. To reason about download size and how well each type compresses, follow up with /archive-tools/compression-ratio-calculator. The analyser deliberately reports expanded sizes so you can see real composition.
How do I detect shipped source maps?
Look for a map group in byExtension. In a clean production artifact it should be absent or zero. A populated map group with real bytes means your build is emitting source maps into the release — strip them and rebuild.
Can I batch many CI artifacts?
Not in this tool — it reads one archive per run. For a size summary across many archives use /archive-tools/batch-compression-report on a paid tier; that one accepts multiple files.
Does it find duplicate assets?
No — it groups by name and folder, not content. For byte-identical duplicate detection (the same logo committed under three paths) use /archive-tools/redundancy-analyzer, which hashes entries with SHA-256.
Will it open a 7z my machine cannot?
Yes. 7z, RAR, bz2, and xz are read via libarchive WASM in the browser, so you do not need p7zip installed. Note 7z/RAR are fully decompressed to measure, so very large ones are RAM-heavy.
Does it recurse into a nested zip in my artifact?
No. An inner archive is counted as one entry at its own size. Extract it with /archive-tools/nested-archive-extractor first, then analyse the inner archive separately.
Is the artifact uploaded anywhere?
No. fflate and libarchive WASM run in your browser tab — the artifact stays local. The only network touch is a one-time WASM module fetch for 7z/RAR/bz2/xz support, never the artifact itself.
What is the largest artifact I can analyse?
50 MB on Free, 500 MB on Pro, 2 GB on Pro-Media / Developer, with matching entry caps (500 / 50,000 / 500,000). Past 2 GB, list the archive with the CLI as covered in the CLI-comparison guide.
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.