rea-reverse

WebAssembly module analyzer and WASM to WAT converter

Open a .wasm file to see its sections, imports, exports, toolchain, features and largest functions, then convert it to readable WAT text with wabt when you need the code.

Your file never leaves your browser. Parsing and disassembly run locally in a Web Worker that has no network access. Nothing is uploaded. How to verify this yourself

Drop a .wasm file here

or

The file is read in your browser. Up to 256 MiB.

A WebAssembly module is a compact binary, but it is not opaque. Its structure is laid out in numbered sections: the types it uses, the functions it imports from its host, the functions and memory it exports, its data segments, and often custom sections that say which compiler produced it and what the functions are called. Most of what you want to know about an unfamiliar .wasm file can be read from that structure without running a single instruction.

This tool reads it inside your browser. Choose a .wasm file and you get a structured report straight away. If you want the full text format, one click converts the module to WAT. The file is never uploaded.

What it does

Input. A .wasm file up to 256 MiB for the analysis report, and up to 32 MiB for the WAT conversion. Only core WebAssembly modules (binary version 1) are supported. Component Model components are not.

Analysis report. A small binary parser written for this page reads the module structure. It does not execute the module and does not decode function bodies. The report contains:

  • Module summary: file size, binary version, and the number of types, imported functions, defined functions, tables, memories, globals, tags, the start function, element segments and data segments.
  • Section table: every section with its id, name, byte offset and size, including custom sections such as name, producers and target_features.
  • Imports and exports: full tables of what the module needs from its host and what it offers to it. Import module names alone often reveal the environment, for example wasi_snapshot_preview1 or env.
  • Toolchain detection: a best guess among Rust, wasm-bindgen, Emscripten, Clang, Go, TinyGo, AssemblyScript, WASI, .NET and Zig, with the evidence each guess is based on (an import name, an export pattern, a producers entry).
  • Producers and target features: the contents of the producers and target_features custom sections when present.
  • Post-MVP features: features that are visible from the module structure, such as multiple memories, tags for exception handling or particular import and type forms.
  • Largest functions: the 20 function bodies with the largest byte size, with names taken from the name section when the module has one.
  • Warnings: sections the parser could not decode are reported as warnings rather than silently skipped.

WAT conversion. The Generate WAT button converts the module into the WebAssembly text format. Only when you click does the page load wabt.js 1.0.39 (about 218 KB gzipped; the wabt WebAssembly binary is embedded in the script as base64). The output is shown in a <pre> block that you can copy or download as a .wat file. All features wabt supports are enabled, including SIMD, threads, GC, memory64 and exceptions, and the name section is used to generate readable names. Output longer than 5 million characters is truncated, with a notice; for anything bigger, use the download or the command line tools below.

How it works

The WebAssembly binary format starts with the magic bytes \0asm and a 4-byte version, followed by sections. Each section has a one-byte id and a LEB128-encoded size, so a parser can walk from one section to the next without understanding what is inside. The page’s parser does exactly that to build the section table, then decodes the sections that describe the module’s shape: types, imports, functions, tables, memories, globals, exports, start, elements, data count, tags, and the custom sections name, producers and target_features. For the code section it reads only the size of each function body, which is how it ranks the largest functions. It never interprets instructions.

Toolchain detection is a set of rules over that data. Each toolchain leaves recognizable fingerprints: wasm-bindgen adds characteristic imports and exports, Emscripten imports helpers from env, Go’s runtime imports from gojs, WASI modules import from wasi_snapshot_preview1, and many compilers name themselves in the producers section. The report lists the matched evidence so you can judge each guess.

The WAT conversion uses wabt’s reader and text writer, the same code as the wasm2wat command line tool.

How your file stays private

The file is never uploaded:

  • The analysis runs in a Web Worker on your device. The worker’s Content Security Policy is connect-src 'none', so the browser does not allow it to make any network request at all.
  • The analysis report works offline once the page has loaded.
  • The wabt script for WAT conversion is downloaded from this site only when you click Generate WAT. If you load the page, go offline, and then click it for the first time, the conversion fails. This is a deliberate trade-off: most visitors only need the report, and they should not have to download about 800 KB of tooling they never use.
  • Analytics events are wasm_analyze and wasm_wat. They carry success or an error code, a size bucket and a duration bucket. They never contain the file name or any file content. The full list is on the privacy page.
  • The tool page shows no ads.

How to verify this yourself

  1. Open your browser’s developer tools and switch to the Network tab before you choose a file. Run the analysis, and generate WAT if you like. Inspect every request: none carries your file. The only request triggered by the WAT button is the wabt script from this site.
  2. Or load the page, go offline (turn off Wi-Fi, or tick Offline in the Network tab) and run the analysis. It completes.

Limitations

  • No decompilation to a high-level language. You get structure and WAT, not C, Rust or JavaScript.
  • WAT is long. Even small modules produce thousands of lines, and the text format is close to the instruction level. Use the report to decide where to look first.
  • No validation. wabt reads the module and writes text but does not run its validator, so an invalid module may still convert. A successful conversion is not a statement that the module is valid.
  • No Component Model. Components (the newer layered format) are not supported; only core modules, version 1.
  • No names in stripped modules. Minified or obfuscated modules usually have no name section, so functions appear as indexes only.
  • No runtime behavior. The module is never executed, so anything decided at runtime, such as which imports are actually called or what data is fetched, is not visible.
  • Toolchain detection is heuristic. It is based on fingerprints and can miss or misattribute a toolchain, especially in post-processed modules.

FAQ

Is the file really not uploaded?

Yes. The analysis worker cannot use the network at all. You can confirm this with the Network tab or by going offline, as described in How to verify this yourself.

Why did “Generate WAT” fail while I was offline?

The wabt script is only fetched when you first click the button. If the page lost the network before that, the script cannot be loaded. Reconnect and try again; the analysis report itself does not need it.

Can I open a Component Model .wasm?

No. Only core modules with binary version 1 are supported. A component has a different layer value in its header and is rejected.

Why are function names missing?

Names come from the name custom section. Release builds often strip it. Without it, functions are shown by index, such as func 42.

The WAT output says it was truncated. How do I get the full text?

Use the download button, or run wasm2wat module.wasm -o module.wat from wabt locally. The on-page view stops at 5 million characters to keep the browser responsive.

How do I double-check the report offline?

Install wabt and run wasm-objdump -h module.wasm for the section headers, wasm-objdump -x module.wasm for imports, exports and other section details, and wasm2wat --enable-all module.wasm for the text format. The results should match the page.

Compliance

Use this tool on modules you built, modules you are authorized to examine, or modules that are publicly distributed, for example to check what a web page you visit loads. Respect the licenses of the software you analyze and the laws that apply to you, including any terms that restrict reverse engineering. The tool gives no advice on bypassing licensing, DRM or other protections.