a Wasm runtime

A .wasm file is just bytes; something has to actually run it. A Wasm runtime is that something: the engine that loads a Wasm module, checks it is well-formed, turns its bytecode into real machine code for the CPU you are on, gives it a sandboxed slice of memory, and lets it execute. The browser has one built into its JavaScript engine (V8 in Chrome, SpiderMonkey in Firefox); outside the browser the best-known standalone runtimes are Wasmtime and Wasmer.

Concretely, a runtime does several jobs in order. First it validates the module - this is a real pass that proves every instruction's stack types line up and control flow is structured, so a malformed or hostile module is rejected before it runs. Then it compiles: many runtimes use ahead-of-time or just-in-time compilation to produce native code (so it runs fast), while some use a simple interpreter (slower, but quick to start and tiny). It sets up the module's linear memory and tables, wires up the imports the module asked for (the only way the code reaches the outside world), and enforces the sandbox: the guest cannot read or write outside its own linear memory, cannot make a system call you did not grant, and is confined to the host functions you handed it.

Runtimes matter because the safety and the speed both live here, not in the .wasm file. The same module behaves differently depending on the engine's compiler quality, its supported features (threads, SIMD, the component model, WASI versions), and how strictly the host wires up capabilities. Be candid: different runtimes support different feature sets and move at different paces, so 'runs on Wasm' in practice means 'runs on the runtimes that support what this module needs' - portability is real but not unconditional.