Skip to content

WebAssembly Inspector

Lists imports, exports, memory and section sizes of a .wasm module and prints its text format.

Opens a `.wasm` file and shows what is inside it: the sections and their sizes, every import and export, the memory and table declarations, and the function names from the name section if the build kept them. The module is parsed, never instantiated or run.

🔒 Runs entirely in your browserwasminspectbinary

Drop a .wasm module

Parsed in this tab — the module is inspected, never instantiated or run.

Reads the binary structure — sections, types, imports, exports, memory, the name custom section — and cross-checks the whole module against the browser’s own WebAssembly.validate. Function bodies are measured, not disassembled: this shows what a module declares and touches, not a full text-format conversion.

How to use it

  1. Drop the module in

    Any `.wasm` file. It is read in this tab and cross-checked against the browser’s own `WebAssembly.validate`, so you get a second opinion on whether it is well-formed.

  2. Look at the sections first

    The size table is the fastest way to see where the bytes went — a large data section means embedded assets, a large custom section is usually debug names or DWARF.

  3. Read the imports

    Imports are the module’s entire contract with the host — every function it can call and every memory it shares. If you are auditing a module you did not build, this is the list that matters.

Common questions

Can I see the actual code?

No. Function bodies are measured, not disassembled — this reports what a module declares and touches rather than converting it to the text format. `wasm2wat` from the WABT toolkit is the tool for a full disassembly.

Why are the function names missing?

Because the build stripped the name custom section, which is what a release build normally does. Exports keep their names regardless — they are part of the module’s interface — so an exported function is still identifiable.

Is a module with imports dangerous?

Not in itself — WebAssembly can only reach what the host hands it, and a module with no imports cannot touch the outside world at all. What the imports name is exactly what it can do, which is why they are worth reading before you instantiate something.

Engine validation says invalid but it parsed.

Those check different things. The parse reads the structure; `WebAssembly.validate` also type-checks every function body. A module can have a perfectly readable section layout and still be rejected — a truncated file or a post-processing step that rewrote bytes it should not have.

Feed it from

Next

These accept what this tool produces, so the result can go straight in.