WASM Binary Analyzer

Inside a WebAssembly Module

A .wasm file is a tightly packed binary container. It starts with an 8-byte header, then a sequence of typed sections, each with a known purpose. Knowing what's in each section is the first step to optimizing WebAssembly bundle size, debugging build output, or understanding what your compiler emitted.

The Header

Every valid WASM module starts with:

That's it, 8 bytes. The magic identifies the file as WASM (distinguishing it from JavaScript, raw machine code, or other binary formats). The version is currently always 1; the format has been stable since the WebAssembly MVP in 2017.

The Standard Sections

After the header come sections. Each section starts with a one-byte type ID and a varuint length, then its contents. The standard section IDs and what they hold:

Type (1). Function signatures used in the module. (i32, i32) -> i32 etc. Compiler-generated and usually small.

Import (2). Functions, tables, memories, and globals the module borrows from its host. For a web app, this is where JavaScript callbacks the WASM expects to call appear.

Function (3). Declarations, which signature each function uses. Doesn't contain bodies; just maps function index to type index.

Table (4). Tables of function references (used for indirect calls). For C/C++ via Emscripten, this is how function pointers work.

Memory (5). Linear memory declarations: initial size, max size, whether it's shared. Most modules have exactly one memory.

Global (6). Module-level globals (like static variables).

Export (7). What the module exposes to the host. The JavaScript wrapper calls into the module through exports.

Start (8). Optional function to run when the module is instantiated (like a constructor).

Element (9). Initialization data for tables.

Code (10). The big one. Compiled function bodies. In most binaries, this is 70–95% of the file size.

Data (11). Initialized memory contents, static strings, lookup tables, constants from your source code.

DataCount (12). Used for bulk memory operations.

Custom (0). Anything else: debug info, names, source maps, producer metadata.

What the Size Breakdown Tells You

The analyzer shows section sizes as both bytes and percentages. Common patterns:

Code dominates (80%+). Normal. Optimization should focus on code: dead-code elimination, inlining, instruction selection. Use wasm-opt -Oz.

Data is huge (>30%). You've embedded large static assets. Consider externalizing them, fetch them at runtime instead of compiling them in.

Custom sections are huge (>20%). You've shipped debug info to production. Strip name sections and debug data: wasm-strip --strip-debug or wasm-objcopy --strip-debug.

Imports are huge. You're depending on many JavaScript callbacks. Each import has overhead, both in module size and in call-site cost. Bundle related imports into fewer wrapper functions.

Many small sections. Probably normal. Most overhead comes from Code and Data; the others are typically small.

Optimizing WASM Size

Stage 1: Compile for size.

• Rust: opt-level = "z", lto = true, codegen-units = 1, panic = "abort".
• C/C++ via Emscripten: -Oz -flto, --closure 1.
• AssemblyScript: asc --optimize --shrinkLevel 2 --converge.

Stage 2: Post-process.

• Run wasm-opt -Oz (from Binaryen). Often shrinks output 20–50% more.
• Strip debug info: wasm-strip or wasm-objcopy --strip-debug.
• Strip names: wasm-strip --strip-custom-section="name" (gives up readable stack traces in exchange for size).

Stage 3: Architecture.

• Move large data to fetched assets.
• Code-split into multiple modules, loaded lazily.
• Use SIMD if your runtime supports it (faster, sometimes smaller).
• Consider whether you really need WASM, for small, infrequent computations, JavaScript may be smaller overall.

Common Build Pitfalls

Whole C++ stdlib embedded. Linking against libc++ pulls in iostream, exception handling, and locale data, easily 200KB+. Use -fno-exceptions, custom allocators, and minimal stdlib subsets.

Floating-point softfp. If your target doesn't have hardware float and your code uses doubles heavily, you'll pull in libgcc's soft-float routines. Use integers when possible.

Stack trace metadata. Rust ships function names and DWARF debug data by default. strip-debug saves real space.

Multiple instances of the same code. Generics in Rust or template instantiations in C++ create multiple monomorphized copies. Inspect via twiggy top (a complementary CLI tool) to find the biggest contributors.

When to Care About WASM Internals

You typically don't need to read the binary directly. Tools like twiggy, wasm-objdump, and this analyzer surface the information you need. Reach for the analyzer when:

1. A bundle is unexpectedly large. Section breakdown tells you where to look.
2. A build differs from a baseline. Compare section sizes between two versions to find regressions.
3. A WASM file fails to load. Check the header is valid and sections are well-formed.
4. You're auditing a third-party WASM module. What does it import? What does it export? Are there suspicious custom sections?
5. You're learning WebAssembly internals. Reading real binaries builds intuition for what compilers emit.

Tooling Ecosystem

WASM tooling worth knowing about:

• wabt (WebAssembly Binary Toolkit): wasm2wat, wasm-objdump, wasm-validate, wasm-strip.
• binaryen: wasm-opt, wasm-as, wasm-dis, wasm-merge.
• twiggy: Code size profiler, what functions contribute most to size.
• wasm-tools: Modern Rust-based suite for parsing, printing, validating.
• wasm-bindgen: Rust ↔ JavaScript bridge generator.
• emscripten: C/C++ → WASM compiler.

Privacy

WASM parsing runs entirely in the browser. The binary you upload is not transmitted to any server, useful when inspecting proprietary algorithms, internal builds, or commercial WASM modules under NDA.