photomopOpen the studio

AI and on-device processing

WebAssembly

Also called wasm or web assembly. Here is what it means, when it changes what you export, and what people get wrong.

AI and on-device processingRuns on your deviceUpdated 10 August 2026

The short answer

WebAssembly is a portable binary instruction format that browsers execute at close to native speed inside the same sandbox as JavaScript. It lets existing code written in C, C++ or Rust, image codecs and model runtimes especially, ship to the web without being rewritten.

Updated

The short version

WebAssembly at a glance

Quick facts about WebAssembly: type, standardised by, compiled from, simd, runs in, role in ai imaging
Quick factDetail
TypePortable binary instruction format
Standardised byW3C
Compiled fromC, C++, Rust and others
SIMDFixed-width 128-bit vector instructions
Runs inThe same sandbox as JavaScript
Role in AI imagingCPU fallback when WebGPU is unavailable

Slide the table sideways to see every column.

Why does image work lean on WebAssembly so heavily?

Because the hard parts were already written. Decades of work went into codecs for JPEG, PNG, WebP and AVIF, into resampling filters, colour conversion and compression search, almost all of it in C or C++. Rewriting that in JavaScript would be enormous, slow and a fresh source of bugs.

Compiling it to WebAssembly gives you the same battle-tested implementation running in a tab. That is why a browser tool can offer encoder settings a browser natively does not expose, convert between formats the platform has no built-in encoder for, or run the identical resampling maths a desktop application uses. The same applies to inference runtimes, which are C++ projects long before they are web projects.

What makes it fast, and what still limits it?

The format is designed for speed: a compact binary encoding that validates and compiles quickly, static typing, and a linear block of memory the module addresses directly with no garbage collector pausing the middle of a tight loop. Fixed-width SIMD instructions operate on 128-bit vectors, so several pixels are handled per instruction, and threads let a decode or a filter spread across cores.

The limits are structural. Data usually has to cross between JavaScript and the module's memory, and for large images those copies are not free. There is no direct access to the GPU from inside a module. And memory is a real ceiling, since a large photo expands to many bytes per pixel once decoded, which is the usual reason a browser tool falls over on an enormous file.

When is it the fallback rather than the first choice?

For neural network inference, WebGPU is faster, often dramatically so, because the arithmetic is exactly the wide parallel work a GPU exists for. WebAssembly is the path you take when WebGPU is unavailable: an older browser, a blocklisted driver, a virtual machine without hardware acceleration.

That makes it the universal floor rather than the ceiling. Nearly every device can run it, results match the GPU path closely, and the only real difference is time. For codec work and general pixel processing the calculation is different again, and WebAssembly is frequently the right first choice rather than the fallback, because those workloads are sequential enough that a GPU adds transfer overhead without much benefit.

What people get wrong about webassembly

Each one is a real failure mode, not a style preference.

  1. Copying an entire large image in and out of module memory for each step of a pipeline instead of keeping it in place.

  2. Loading a heavy codec module on page load when it is only needed once the user picks a file.

  3. Running WebAssembly work on the main thread, which blocks the interface for the whole duration of a decode.

  4. Assuming WebAssembly can reach the GPU directly, when it needs a separate WebGPU path for that.

Questions people ask

WebAssembly, answered

The follow-up questions people search for once they have the definition.

Is WebAssembly a replacement for JavaScript?

No, they are complements. JavaScript handles the interface, the network and the page, while WebAssembly handles compute-heavy inner loops such as decoding, filtering and inference. A typical image tool calls into a module for the heavy part and does everything else in JavaScript.

Why is it slower than the same code on my desktop?

The sandbox adds bounds checking, the SIMD available is a portable subset rather than every instruction your processor offers, and data has to be moved into the module. Expect a fraction off native performance rather than an order of magnitude, and much better than the equivalent plain JavaScript loop.

Can WebAssembly read my files without permission?

No. A module has no access to the file system, the network or the page by default. It only sees the memory and the functions the host page explicitly gives it, so it can only process a file that you chose and the page handed over.

Does using WebAssembly make my images upload anywhere?

Not by itself. A module runs locally on data the page gives it and cannot open a network connection on its own. Whether an image is transmitted depends entirely on what the surrounding page does, not on the presence of WebAssembly.

Sources

Where the facts on this page come from. Every link opens the specification, standard or documentation the claim was read at.

Now do it to a photo

Photomop is a photo studio that runs on your own device. Resize, crop, compress, convert, batch edit, remove a background and change one all work in the browser tab you are reading this in, at full resolution and with no watermark. The on-device page shows you how to check that the photo stays put.