WebAssembly Module Size Estimator
Estimate the min/typical/max size range of a WebAssembly module based on source language, compile target, optimization level, and selected feature modules — a heuristic estimate, not a real file analysis.
FreeOnline Tool
Loading…
How to Use
- Choose your source language (Rust, C++/Emscripten, Go/TinyGo, AssemblyScript, or Zig).
- Choose a compile target (Web/Browser, Standalone, or WASI) and an optimization level (-O0 through -Oz).
- Check the feature modules your project will use (JSON parsing, HTTP client, crypto/hashing, image processing, etc.) — multiple selections allowed.
- Click "Estimate Size" to see the min/typical/max size range, an estimated gzip-compressed size, and a breakdown of what contributes to the total.
- Click "Load Sample Data" to see a worked example: Rust with JSON/HTTP/crypto and wasm-bindgen bindings.
Features
- Calculates size ranges from a built-in heuristic lookup table (per-language runtime baseline, 12 feature-module size deltas, target-platform overhead, optimization-level coefficients) — it never uploads or parses an actual .wasm file.
- Covers 5 source languages (Rust, C++/Emscripten, Go/TinyGo, AssemblyScript, Zig), 3 compile targets, and 6 optimization levels (-O0 to -Oz).
- 12 selectable feature modules (JSON, HTTP, crypto/hashing, image processing, math, string/regex, date-time, compression, encoding, random, YAML, wasm-bindgen bindings), each with its own size contribution.
- Outputs min/typical/max size estimates plus an approximate gzip-compressed size (roughly 50% of the typical size).
- Renders the size breakdown as an ASCII bar chart so you can see each contributor's share at a glance.
- The results panel explicitly states this is a heuristic estimate for reference only, not the actual compiled output size.
Use Cases
Compare languages before committing to one
Deciding between Rust and AssemblyScript for a browser-side WASM module — estimate the rough size difference for similar feature sets before you write any code.
See how much an optimization level actually saves
Curious how much smaller -Oz is versus -O2 for your feature mix — switch the dropdown and watch the estimate update instantly.
Plan which features to cut for a size budget
When a WASM bundle needs to shrink, uncheck feature modules one at a time (e.g. drop image processing or YAML) and see how much the estimate drops, to prioritize what to remove.
Give a rough size number during early project planning
No code exists yet but the team needs a ballpark size figure for a technical proposal — get a quantified range in seconds instead of guessing.
FAQ
Does this tool parse a .wasm file I upload?
No. There's no file upload at all. It computes an estimated range purely from the language, target, optimization level, and feature checkboxes you select, using a built-in heuristic table — it has nothing to do with your actual compiled binary.
How accurate is the estimate?
It's a rough estimate based on publicly known typical values. Real-world size varies a lot with actual code, dependency versions, and compiler version — treat it as a reference for early technical decisions, not a substitute for measuring your real build.
How is the gzip-compressed size calculated?
It's a simple 50%-of-typical-size approximation. Real gzip ratios for wasm binaries vary by content, typically in the 40%-60% range — treat this as a rough guide only.
Why does the same feature module add the same size regardless of language?
The current model uses a single language-agnostic size delta per feature module rather than calibrating it per language — that's a known simplification of the estimation model.