About

WebAssembly Text Format (WAT) is the human-readable S-expression representation of WASM binary modules. Converting WAT to WASM requires lexical analysis, type validation, and binary encoding conforming to the WebAssembly Core Specification (W3C). A malformed module - incorrect type signatures, mismatched stack depths, or invalid section ordering - produces a binary that engines reject at instantiation. This tool performs full parsing and validation before emitting the binary, catching errors that a manual hex-editing workflow would miss entirely.

The output binary begins with the magic number 0x00 0x61 0x73 0x6D followed by version 0x01 0x00 0x00 0x00, then encodes each section (Type, Function, Memory, Export, Code) with LEB128-encoded lengths. This converter handles multi-value returns, bulk memory operations, and reference types. Note: this tool approximates the behavior of the wat2wasm CLI from the WebAssembly Binary Toolkit. Certain proposal-stage features (e.g., exception handling, GC types) may not be supported depending on the parser version loaded.

Formulas

The WASM binary format encodes all integers using LEB128 (Little Endian Base 128) variable-length encoding. An unsigned integer n is encoded as a sequence of bytes where each byte stores 7 data bits and 1 continuation bit:

byte_i = (n >> (7 ⋅ i)) ∧ 0x7F ∨

{

0x80 if more bytes follow0x00 if last byte

Where n is the unsigned integer value, i is the byte index starting from 0, and the 0x80 high bit signals continuation. Signed LEB128 uses two's complement with sign extension on the final byte.

Module validation requires that the function type section declares signatures as vectors of value types: 0x7F (i32), 0x7E (i64), 0x7D (f32), 0x7C (f64). The magic number is 0x00 0x61 0x73 0x6D (ASCII: \0asm) and version is fixed at 0x01 0x00 0x00 0x00.

Reference Data

WASM Section ID	Section Name	Description	Binary ID
0	Custom	Name annotations, debug info, metadata	0x00
1	Type	Function type signatures (params → results)	0x01
2	Import	External function, table, memory, global imports	0x02
3	Function	Maps function index to type index	0x03
4	Table	Indirect function call tables (funcref)	0x04
5	Memory	Linear memory declarations (pages of 64 KiB)	0x05
6	Global	Global variable declarations with mutability	0x06
7	Export	Exported functions, memories, tables, globals	0x07
8	Start	Module start function index (auto-invoked)	0x08
9	Element	Table element initialization segments	0x09
10	Code	Function bodies (locals + expression bytecode)	0x0A
11	Data	Linear memory initialization segments	0x0B
12	DataCount	Number of data segments (bulk memory proposal)	0x0C

Frequently Asked Questions

This converter supports the WebAssembly MVP specification including all numeric types (i32, i64, f32, f64), control flow instructions (block, loop, if/else, br, br_table), memory operations, table operations, and multi-value returns. Bulk memory operations and reference types are supported when the underlying parser includes those proposals. Exception handling and GC proposals may not be available.

WAT validation goes beyond syntax. Common failures include type mismatches on the operand stack (e.g., pushing an i32 but a function expects f64), unreachable code after unconditional branches, mismatched block signatures, and exceeding the maximum function locals limit. The error message from the converter identifies the line number and the specific validation rule violated. Check that every block/loop/if has a matching end, and that exported names are unique.

Use the Hex View tab to inspect the raw bytes. The first 8 bytes must be 00 61 73 6D 01 00 00 00 (magic + version). You can also load the downloaded .wasm file in a browser using WebAssembly.instantiate() - if it throws a CompileError, the binary is malformed. The converter runs validation before emitting, so a successful conversion implies the binary passes engine-level validation.

This tool accepts WAT input up to 5 MB of text. Larger modules may cause browser memory pressure during parsing. For very large modules (hundreds of functions), conversion time scales linearly with the number of instructions. Typical modules under 1 MB convert in under 500 ms.

Yes. If your WAT source includes named functions, locals, or module names via the name annotation syntax (e.g., (func $add ...)), the converter emits a Name custom section in the binary. This is useful for debugging in browser DevTools, which display symbolic names from this section when inspecting WASM call stacks.

This tool is designed for one-direction conversion: WAT to WASM. Disassembly (WASM to WAT) requires a different decoding pipeline that reads binary sections and reconstructs S-expressions. A dedicated wasm2wat tool would be needed for that reverse operation.