The State of WebAssembly in 2026: What You Can Now Do Client-Side

In 2018 WebAssembly could do arithmetic. In 2026 it runs FFmpeg, DuckDB, Postgres, Tesseract, PyTorch inference, OpenCascade B-Rep kernels, and full 3D engines — inside a browser tab, at close to native speed. This post is a state-of-the-ecosystem snapshot: what shipped, what it enables, and which workloads still need a server.

The features that shipped between 2020 and 2026

• Threads (SharedArrayBuffer + atomics) — the reason ffmpeg.wasm can use every CPU core.
• SIMD (fixed-width 128-bit) — 2–4× speedups for image, video, and DSP code.
• Bulk memory operations — fast memcpy without a JS round trip.
• Reference types and tail calls — cleaner interop with JS and better perf for languages like Scheme and OCaml.
• Exception handling — C++ code that throws no longer needs to be recompiled with a slow shim.
• Garbage collection (WasmGC) — languages like Kotlin, Dart, and Java can now compile to WASM without shipping their own GC.
• The Component Model + WIT — a portable interface between modules; the plumbing that makes WASI-based sandboxing practical.
• WASI Preview 2 — a stable capability-based interface for I/O, sockets, and clocks.

What that unlocked on the client

Video and audio at native-adjacent speed

ffmpeg.wasm with threads + SIMD compresses a 1080p H.264 file at 0.5–1× real time on a modern laptop. That's fast enough that Compress Video, MP4 → GIF, and Trim Video feel snappy without touching a server.

Analytical databases in a tab

DuckDB-WASM handles multi-GB Parquet and CSV files, streaming from a File handle. Big CSV Viewer and SQL Playground are literally an analytical warehouse running client-side.

OCR and small-model inference

Tesseract.js and the background-removal segmentation model run entirely in-browser. Image → Text and Remove Background ship models around 30–100 MB and stay under a couple seconds per image.

3D CAD

OpenCascade compiled to WASM (occt-import-js) means STEP and IGES files — historically a desktop-CAD problem — open in a tab. See STEP Viewer.

Compression and archive handling

libarchive.js, zstd, and Brotli all run in-browser. Extracting RAR / 7z / TAR (Extract Archive) no longer needs WinRAR.

The workloads that still want a server

• Large-model LLM inference. A 70B-parameter model does not fit in a browser. Small models (up to a few billion params) are increasingly practical with WebGPU + WASM, but the frontier still lives on servers.
• Real-time multi-user collaboration. CRDTs run in the browser; the sync channel does not.
• Long-lived background jobs that must run when the tab is closed.
• Aggregating data across users. By construction, client compute can't see other users' data.

Where the ecosystem is going next

1. WasmGC adoption — expect more Kotlin / Java / OCaml / Scala apps in the browser as toolchains mature.
2. Component Model in production — sandboxed plugin systems where a page can safely run untrusted WASM.
3. Tighter WebGPU + WASM integration — pipelines where the CPU-side decoder is WASM and the GPU-side filter is WGSL.
4. Better debuggability — DWARF debuginfo in Chrome and Firefox is finally usable for optimized builds.

The takeaway for product teams

If your feature accepts a file, transforms it, and returns a file, the default choice in 2026 is a WASM engine running client-side. It's cheaper (no compute bill), more private (no upload), and often faster (no round trip). That's the calculus behind every Zro7 tool.