WebAssembly Inspector

WebAssembly modules are compact binaries that browsers and runtimes run next to JavaScript. They come out of compilers for C, C++, Rust, Go and others, and when one misbehaves or arrives from somewhere, the first question is simple: what does it need, and what does it give back? The answers are in the file’s structure, not in its instructions, and this page reads that structure.

The container format

A module begins with the four bytes 00 61 73 6d (the characters “\0asm”) and a four-byte version, currently 1. After that come sections, each with a one-byte id, a length and contents. The type section lists function signatures; import and export sections list what the module requires and offers; function, table, memory and global sections declare items; the start section names a function to run on load; the code section holds function bodies; and data holds initial memory contents. Custom sections have id 0 and carry names, debug data or producer information.

Exports and imports

Exports are the module’s public interface. Each has a name, a kind (function, table, memory or global) and, for functions, a signature in the form (i32, i32) → i32, using the types i32, i64, f32, f64 and reference types. Imports are the reverse: pairs of module and field names such as env and memory or wasi_snapshot_preview1 and fd_write, each with a kind and type. Whatever you pass to the instantiate call has to match them, so reading the import list tells you what glue code a loader needs.

Using the page

Open a file or paste the bytes in hexadecimal or Base64. The summary shows the version, the size, the number of defined functions, the counts of imports and exports and the start function if any. Tables follow for exports, imports and sections, with the number of bytes each section occupies and the number of entries. Custom sections are listed by name. A file that does not start with the WebAssembly header, or that ends in the middle of a section, produces an error that says so.

What the sizes show

Section sizes explain where bytes go. A module with a large code section needs better optimisation or fewer dependencies; a large data section usually means embedded strings, lookup tables or assets; a large name section holds debug information that can be stripped. Comparing two builds of the same module section by section shows what a compiler flag changed. The page lists sizes in bytes, and the sum is the file size.

A worked example

The Sample button loads a 41-byte module, the classic first example from the WebAssembly documentation. It has version 1, one defined function, no imports and one export. The export table shows the name add, kind function, type (i32, i32) → i32. The sections are type (7 bytes, 1 item), function (2 bytes, 1 item), export (7 bytes, 1 item) and code (9 bytes, 1 item). Together with the 8-byte header and the section ids and lengths they make up the 41 bytes. The hex is 0061736d0100000001070160027f7f017f030201000707010361646400000a09010700200020016a0b.

Limits

The inspector reads the structure and does not disassemble the instructions, validate the module in full, or run it. Some sections of newer proposals, such as certain reference-type and exception-handling features, are listed by id and size but not described in detail. The size limit is 50 MB, and the page keeps the file in memory only. For disassembly, use a toolkit such as wabt or the developer tools of a browser.

Related tools

• Source Map Decoder maps compiled JavaScript errors back to source.
• Hex to Binary helps when reading the bytes by hand.
• Endian Converter explains the little-endian numbers used in the format.
• Hash Generator fingerprints a module file for comparison.