WebAssembly explained: how a database, editor, or game can run inside your browser

Reviewed September 30, 2026. This guide reflects WebAssembly 3.0 and current browser APIs. Individual features still require compatibility checks.

A web page can now run a SQL database, video codec, image editor, scientific simulation, or language runtime without sending every computation to a server. One technology behind these applications is WebAssembly, or Wasm.

WebAssembly is a safe, portable, low-level code format with a compact binary representation. It is a compilation target for languages such as C, C++, Rust, C#, and others. It complements JavaScript rather than replacing HTML, CSS, browser APIs, or application design.

From source code to a browser feature

Source language
Rust, C++, or another language→Compiler
Produces .wasm→Browser engine
Validates and instantiates⇄JavaScript and Web APIs
UI, files, network

The browser fetches the binary module, validates it, compiles it for the current machine, and creates an instance. JavaScript can call exported Wasm functions. A module can call functions deliberately imported from JavaScript.

Four pieces to understand

Strings, objects, and browser elements do not automatically cross the boundary as rich JavaScript values. Toolchains generate “glue” code to encode data into linear memory, call Wasm, and decode the result. Crossing that boundary has a cost, so a useful design performs meaningful batches of work rather than bouncing tiny operations back and forth.

Why Wasm can be fast—but is not automatically faster

The format is designed for efficient decoding, validation, and execution using common hardware capabilities. Compilers can bring mature native libraries to the web. Predictable numeric loops, codecs, compression, database operators, and simulations are strong candidates.

Performance still depends on the workload and implementation:

• Modern JavaScript engines already optimize hot code aggressively.
• Copying data and converting strings across the JS–Wasm boundary can dominate small tasks.
• A large module increases download, compilation, and startup time.
• Memory limits and single-thread defaults may constrain browser builds.
• Threads require workers and, for shared memory, additional security headers and browser support.

Benchmark the complete user task on representative devices. A microbenchmark of one function cannot capture loading, parsing, memory transfer, and rendering.

The sandbox is a boundary, not a magic shield

WebAssembly runs inside the browser's security model. It follows same-origin and permissions policies. A module does not receive arbitrary filesystem, camera, network, or DOM access merely because native code was compiled into it. The host must import or expose capabilities.

Why heavy work belongs in a Web Worker

The browser's main thread handles input, layout, and painting. A long database query on that thread can freeze scrolling and buttons even if the code itself is fast. Web Workers run scripts in a separate thread and communicate through messages.

This separation improves responsiveness, but transferring large data can still cost time and memory. Prefer transferable buffers, streaming, or compact result sets when the library supports them.

A concrete example: DuckDB-Wasm

DuckDB-Wasm compiles the analytical DuckDB engine to WebAssembly. Its documentation describes a browser client that executes SQL locally with no server round-trip. It uses Apache Arrow to exchange typed columnar data with JavaScript and can read CSV, JSON, and Parquet through its virtual filesystem.

This architecture powers Noetrion's SQL Playground: the browser loads the engine, registers a local dataset, runs a query in a worker, and renders the returned table. The dataset is not uploaded to a Noetrion database.

// Simplified architecture, not a complete application
const worker = new Worker(workerUrl)
const db = new duckdb.AsyncDuckDB(logger, worker)
await db.instantiate(wasmModule)

const connection = await db.connect()
const result = await connection.query(
  "SELECT category, AVG(price) FROM dataset GROUP BY category"
)

Browser limits still apply. DuckDB documents single-thread operation by default, experimental multithreading, memory limits, and CORS rules for remote files. A native server remains better for datasets that exceed the user's device or need shared concurrency.

Good and poor fits

A simple form, content page, or small JSON transformation rarely needs Wasm. Shipping a multi-megabyte runtime for a task JavaScript can finish instantly makes the experience worse.

Deployment checklist

1. Measure module size, startup time, peak memory, and end-to-end task time.
2. Feature-detect the required Wasm capabilities and provide a clear fallback.
3. Serve the correct MIME type and configure caching deliberately.
4. Use a worker for long operations and design cancellation where possible.
5. Define which imports grant network, storage, clock, randomness, or device access.
6. Apply Content Security Policy and cross-origin isolation only with an understood threat model.
7. Keep third-party runtimes updated and publish their licenses.
8. Tell users accurately whether files remain local and which resources load from third parties.

WebAssembly expands what a browser can execute efficiently. The best applications use it as one component in a transparent architecture: JavaScript coordinates the interface and Web APIs, workers protect responsiveness, and the host grants only the capabilities the module actually needs.