Look inside a WebAssembly .wasm file

What it shows

• Imports, grouped and explained. Every function, memory, table and global the module needs from its host, by module name, with each function’s signature. Known glue is named in one sentence: WASI (wasi_snapshot_preview1 or wasi_unstable, with the capabilities its functions reach: files, clock, random numbers, sockets, environment variables and arguments), Emscripten’s JavaScript glue (env, or the one-letter module a of a minified build), wasm-bindgen for Rust (__wbindgen_*, __wbg_*) and Go’s wasm_exec.js.
• Exports. What the page or runtime can call, with each function’s signature, and the internal name when the name section gives a different one.
• Size by section. A bar and a list of the type, import, function, table, memory, global, export, start, element, code, data and custom sections, so you see at once whether a 3 MB module is code, embedded data or debug info that a release build would drop.
• The summary. WebAssembly version; function, type and global counts; each memory’s initial and maximum size in 64 KB pages and bytes, shared or not, 32- or 64-bit; tables; the start function that runs on load; and which features beyond WebAssembly 1.0 the module uses (SIMD, threads, bulk memory, reference types, GC, memory64, multi-memory, exception handling, tail calls), each with the instruction or type that shows it.
• Who built it. The producers section (language, and the tools with versions, such as rustc 1.97.1, clang 19, wasm-bindgen 0.2.126), target_features, the name section (used to label every function), a sourceMappingURL or external_debug_info address as text, and whether DWARF debug sections are present.
• Functions and their text. The biggest functions by code size, then every function with a name search. Opening one prints its instructions in the WebAssembly text format (WAT), one function at a time so a 20 MB module stays responsive. Modules up to 2 MB can be saved whole as a .wat file.
• Data and its strings. Each data segment with its size and memory address, and the printable text inside: error messages, format strings, version numbers, URLs. The first 50 strings of a segment are listed and every string is searchable.

Reading a module

A worked example

The SQLite build this site’s SQLite viewer uses, sql-wasm-browser.wasm from sql.js 1.14.2, is 658,410 bytes. 89% of it is code (585 KB in 1,879 functions); 68 KB is data, whose first string is 3.49.1, SQLite’s version. All 38 imports come from a module named a with one-letter names, the mark of Emscripten’s minified glue, and its memory starts at 338 pages (21 MB) and may grow to 32,768 pages (2 GB). It has no name section, so its functions are shown by number. It uses bulk memory, sign extension and non-trapping float-to-int instructions.

What imports tell you

A WebAssembly module can do nothing outside its own memory except through its imports, so the import list is the complete set of things it can ask its host for. A module whose WASI imports include path_open can ask to open files by name; one with only fd_write can write to streams the host already opened, usually just the console. Whether the host grants any of it is the host’s choice: browsers have no WASI at all, and wasmtime gives no folder access unless you pass --dir.

Why the text is long

The text format writes each instruction on its own line, so a module’s .wat is typically 15 to 25 times its size: sql.js’s 658 KB becomes about 15 MB of text. That is why functions open one at a time here.

Written for this site

The module is decoded by viewhack’s own reader and text printer, written from the WebAssembly Core Specification and the tool-conventions documents for the name, producers and target_features sections. It covers WebAssembly 1.0 and 2.0 plus the threads, GC, typed references, exception handling, tail call, memory64 and multi-memory proposals. Most SIMD arithmetic instructions are shown by opcode number (v128.op_N) rather than by name. No wabt or binaryen code is used, and no library is downloaded.

Tested on

Modules generated in the test with WASI imports, name and producers sections, a data segment, a source-map address, an exported memory and functions, and the real WebAssembly files bundled with sql.js (MIT), pdf.js’s colour-management module (written in Rust, built with wasm-bindgen) and the other vendored libraries on this site, every function of which decodes to its last byte.

What this cannot do

• Run the module. It never compiles, instantiates or runs it. That keeps you safe, but it also means the page cannot say what the code does when it runs.
• Decompile to C or Rust. You get the module’s own instructions as text, not the source it was compiled from. wasm-decompile (part of wabt) and Ghidra with a WebAssembly plugin get closer, on your computer.
• Tell you what it actually does. A module’s imports describe what it CAN ask the host for, not what it does: a module that imports sock_send may never call it, and a host may refuse or fake any import.
• Follow debug links. A sourceMappingURL or external_debug_info address is shown as text and never fetched, so source maps and separate DWARF files are not read. DWARF sections inside the file are listed, not decoded.
• Open wasm inside other files. A .wasm inside a ZIP, an npm package or a browser extension, or base64 wasm embedded in a .js file, is not found here: unpack it first and drop the .wasm itself. WASI 0.2 components (the component model) are recognised and named, but only core modules are read.
• Validate. A module that reads cleanly here can still be rejected by an engine for a type error. wasm-tools validate or a browser checks that.

Other ways to look inside

Command line

wasm-objdump -x and wasm2wat (wabt), or wasm-tools print and wasm-tools objdump (Bytecode Alliance). twiggy top ranks what takes the space.

Browser DevTools

On a page that already loads the module, Chrome and Firefox list it under Sources and show its text, with DWARF source when the module was built with -g.