WebAssembly in 5 minutes — how browser tools got desktop-fast

§1 — Problem statement

For most of the web’s history, the only language that ran in the browser was JavaScript. JavaScript is well suited for forms, interactions, animation — anything close to the page. It is substantially slower than compiled C, C++, or Rust for numerical work — image filters, PDF rendering, video encoding, ML inference. The performance gap meant heavy workloads ran either server-side (upload, process, download) or in a native app (install a desktop binary).

WebAssembly closes the gap.

§2 — Definition

A WebAssembly module is a compact binary file with a .wasm extension. Inside is machine-portable bytecode — instructions like “add these two numbers,” “load this memory address,” “call this function.” It is not JavaScript and not English; it is an intermediate language browsers know how to execute very quickly.

The browser fetches a .wasm file the same way it fetches a JavaScript file: download, parse, run. The difference is that the parsing step is faster (WASM is smaller and more predictable than JS) and the running step is faster too (WASM’s bytecode maps cleanly onto modern CPU instructions).

§3 — Loft’s WASM usage

Three of Loft’s heaviest workloads run as WASM.

§3.1 — PDFium (WebAssembly)

Google’s PDF engine (PDFium) — the same engine Chrome uses internally to render PDFs. Compiled to WASM and packaged for the browser. Handles PDF rendering and most of the read paths.

§3.2 — FFmpeg (WebAssembly)

Industry-standard tool for video and audio encoding. Compiled to WASM. Handles every video tool — compress, trim, convert, extract audio.

§3.3 — ONNX Runtime Web

Microsoft’s runtime for ONNX-format machine-learning models. Compiled to WASM with WebGPU acceleration where supported. Runs PaddleOCR for OCR and MODNet for portrait matting.

All three are mature C/C++ projects that pre-date the web tools built on them. Compiling to WASM means we get their full feature set in the browser without anyone re-writing twenty years of work.

§4 — Why this changes the privacy story

Before WASM, browser-side PDF processing was genuinely too slow for production use. JavaScript took twenty seconds to compress a single page; the heap melted on anything bigger than a small PDF. So tools uploaded to a server because that’s where the C++ libraries lived.

WASM put those libraries in the browser tab. The privacy upgrade is a side effect of an engineering breakthrough. The file does not need to leave because the code that can read it is already on your machine.

§5 — Constraints

Constraint	Detail
Memory ceiling per tab	a per-tab memory cap, low hundreds of MB on modern phones, higher on desktop
First-load weight	several MB compressed for PDFium, ~30 MB for FFmpeg
Native vs WASM speed	WASM is comparable, not equal; ~1.5-2x slower than native binary for the same workload
Browser support	every modern browser supports WASM, has for years
WebGPU acceleration	Chrome 113+, Edge 113+, Safari 18+
Security model	runs in the same browser sandbox as JavaScript — strong, but not magically safer

§6 — Verification

To see WASM in action in your browser: DevTools → Network → filter on .wasm. Open any Loft PDF tool. You’ll see the .wasm modules loading at first paint. After that, cached.

You can also see WASM execution via DevTools → Performance. Record a tool run; the WASM call frames show up in the flame graph distinct from JavaScript frames.

§7 — Open questions

A few things still aren’t settled in the WASM ecosystem and will likely change over the next few years:

• Multi-threading via SharedArrayBuffer. Available on cross-origin-isolated pages (Loft tools pages meet this requirement). Some workloads benefit greatly, some don’t yet. We use it for FFmpeg-MT and ORT.
• WebGPU adoption. ORT’s WebGPU path is now stable on Chrome/Edge; Safari 18 added it. The performance lift over WASM-only is large (often 5-10x) for neural-network inference.
• GC-managed languages. New WASM features (reftype, gc, stringref) let languages like Java and Kotlin target WASM without bringing their own GC. Not yet relevant for Loft’s stack, but the language landscape is widening.

§8 — References

• WebAssembly — MDN — canonical specification
• The pillar at /docs/how-it-works/ §4 — Loft-side overview of the WASM stack
• Service Workers post — paired browser feature that makes WASM tools offline-capable

I had to look up the exact byte format for §2 twice before that paragraph survived a self-review. The “machine-portable bytecode” framing is correct but easy to wave at; the WebAssembly binary encoding spec has the full version if you want it.