Krunkit
WebAssembly
Image Processing
Performance
Web Development

How WebAssembly Powers Browser-Based Image Processing: A Technical Deep Dive

Explore how WebAssembly enables near-native image processing entirely in the browser. Learn how codecs like MozJPEG and OxiPNG are compiled to WASM, performance benchmarks versus server-side processing, and what the future holds.

Krunkit Team··13 min read

The Problem With Server-Side Image Processing

For most of the web's history, image processing has followed a predictable pattern: upload an image to a server, process it there, and download the result. This approach works, but it comes with inherent costs.

First, there is latency. Uploading a 5 MB photo over a typical connection takes several seconds. The server processes it (usually fast), then the user downloads the result. Round-trip times of 10–30 seconds for a single image are common, and they multiply with batch operations.

Second, there is cost. Image processing is CPU-intensive. Running encode/decode operations on server infrastructure means paying for compute, whether you are running bare metal, VMs, or serverless functions. At scale, this becomes a significant line item.

Third — and increasingly important — there is privacy. Every image uploaded to a server passes through network infrastructure, gets stored (even temporarily) on someone else's machine, and is subject to that service's data handling policies. For photos containing faces, documents, location-identifiable landmarks, or sensitive business content, this is a real concern.

WebAssembly changes this equation entirely. It brings the processing power to the user's browser, eliminating the upload, the server, and the privacy trade-off.

What WebAssembly Actually Is

WebAssembly (WASM) is a binary instruction format designed as a compilation target for high-level languages. It runs in a sandboxed virtual machine inside the browser, alongside JavaScript. But unlike JavaScript, it was designed from the ground up for predictable, near-native performance.

Key Characteristics

  • Binary format: WASM modules are distributed as compact .wasm files, not human-readable source code. This means smaller downloads and faster parsing compared to equivalent JavaScript.
  • Stack-based virtual machine: WASM executes instructions on a stack machine, similar to how the JVM works. This makes it efficient to compile to and efficient to execute.
  • Strongly typed: Every value and operation has an explicit type. There is no type coercion or dynamic dispatch overhead.
  • Sandboxed: WASM code runs in the browser's security sandbox. It cannot access the filesystem, network, or DOM directly — it must go through JavaScript interfaces.
  • Portable: The same WASM module runs on Chrome, Firefox, Safari, and Edge. Browser support reached 95%+ of global users by late 2024.

How It Compares to JavaScript

JavaScript engines like V8 (Chrome) and SpiderMonkey (Firefox) are extraordinarily optimized. For many workloads, JavaScript is fast enough. But image processing exposes JavaScript's weaknesses:

| Aspect | JavaScript | WebAssembly | |--------|-----------|-------------| | Numeric computation | JIT-compiled, but type checks add overhead | Statically typed, no type checking at runtime | | Memory access | Objects and arrays with bounds checking | Linear memory, direct byte-level access | | Startup time | Parse → compile → optimize (tiered) | Decode → compile (streamable, single pass) | | Peak throughput | ~60–80% of native for optimized hot paths | ~85–95% of native for compute-heavy workloads | | Predictability | JIT deoptimizations can cause pauses | Consistent performance, no deopt cliffs |

For pixel-by-pixel operations across millions of pixels, the consistent throughput and direct memory access of WASM make a measurable difference.

Compiling Image Codecs to WebAssembly

The real power of WASM for image processing is not writing new codecs — it is compiling battle-tested native codecs that have been optimized over decades. Tools like Emscripten make this possible by compiling C/C++ (and Rust) code to WASM.

MozJPEG → WASM

MozJPEG is Mozilla's fork of libjpeg-turbo, optimized for maximum compression efficiency. It produces JPEG files that are 5–15% smaller than standard libjpeg at equivalent visual quality, thanks to:

  • Trellis quantization
  • Optimized Huffman coding
  • Progressive scan optimization
  • Custom quantization tables

The compilation process looks roughly like this:

# Simplified Emscripten build for MozJPEG
emcc \
  -O3 \
  -s WASM=1 \
  -s ALLOW_MEMORY_GROWTH=1 \
  -s EXPORTED_FUNCTIONS='["_encode_jpeg", "_decode_jpeg", "_malloc", "_free"]' \
  -s EXPORTED_RUNTIME_METHODS='["ccall", "cwrap"]' \
  -I ./mozjpeg/include \
  mozjpeg/lib/*.c \
  wrapper.c \
  -o mozjpeg.js

The critical flags:

  • -O3 enables aggressive optimization (function inlining, loop vectorization)
  • ALLOW_MEMORY_GROWTH lets the WASM module allocate more memory as needed (images vary wildly in size)
  • EXPORTED_FUNCTIONS specifies which C functions are callable from JavaScript

The resulting .wasm file is typically 150–250 KB (gzipped), containing the full MozJPEG encoder and decoder.

OxiPNG → WASM

OxiPNG is a Rust-based PNG optimizer, a modern replacement for OptiPNG. It applies lossless optimizations:

  • Trying all PNG filter types and selecting the best per row
  • Optimizing DEFLATE compression with zopfli or libdeflater
  • Stripping unnecessary metadata chunks
  • Reducing bit depth where possible
  • Converting color types (e.g., RGBA to indexed when the image uses few colors)

Because OxiPNG is written in Rust, it compiles to WASM using wasm-pack and the wasm32-unknown-unknown target:

wasm-pack build --target web --release

Rust's WASM ecosystem is mature. The wasm-bindgen crate handles the JavaScript ↔ WASM interface, and the resulting modules are typically smaller than Emscripten-compiled C code because Rust does not need a C standard library runtime.

WebP and AVIF

Google's libwebp and the AOM's libavif follow similar compilation paths to MozJPEG. The libavif codec is notably more complex (it is built on the AV1 video codec) and produces larger WASM modules — around 400–600 KB gzipped. This is one reason why AVIF encoding in the browser is slower than other formats: the codec itself is more computationally demanding, and the WASM module is larger to download and compile.

The JavaScript ↔ WASM Interface

WASM modules cannot directly operate on JavaScript objects, DOM elements, or the Canvas API. The interface between JavaScript and WASM happens through linear memory — a flat, contiguous byte array that both JavaScript and WASM can read and write.

Here is the typical flow for encoding an image:

// 1. Get image data from Canvas
const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');
ctx.drawImage(sourceImage, 0, 0);
const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);

// 2. Allocate memory in WASM's linear memory
const inputPtr = wasmModule._malloc(imageData.data.byteLength);

// 3. Copy pixel data from JavaScript to WASM memory
wasmModule.HEAPU8.set(imageData.data, inputPtr);

// 4. Call the WASM encode function
const outputPtr = wasmModule._encode_jpeg(
  inputPtr,
  canvas.width,
  canvas.height,
  quality // e.g., 80
);

// 5. Read the encoded result back from WASM memory
const outputSize = wasmModule._get_output_size();
const encodedData = new Uint8Array(
  wasmModule.HEAPU8.buffer,
  outputPtr,
  outputSize
);

// 6. Create a downloadable blob
const blob = new Blob([encodedData], { type: 'image/jpeg' });

// 7. Free WASM memory
wasmModule._free(inputPtr);
wasmModule._free(outputPtr);

This copy-in, process, copy-out pattern is fundamental to WASM's security model. The WASM module never gets direct access to your image data in JavaScript's heap — it works on its own copy in linear memory.

The jSquash Approach

Projects like jSquash wrap this low-level interface into clean, high-level APIs:

import { encode } from '@jsquash/mozjpeg';

// Takes ImageData, returns an ArrayBuffer
const encodedBuffer = await encode(imageData, { quality: 80 });

Under the hood, jSquash handles memory allocation, data copying, WASM instantiation, and cleanup. This is the pattern Krunkit uses — the WASM codecs are loaded on demand via dynamic imports, and jSquash provides the interface.

Performance: Browser WASM vs. Server-Side

The question everyone asks: how does WASM in the browser compare to native code on a server?

Benchmark Setup

We measured encoding times for a 4000x3000 pixel photograph (12 megapixels, a common smartphone photo resolution) across different environments:

| Environment | JPEG (q80) | PNG (optimized) | WebP (q80) | AVIF (q60) | |------------|-----------|-----------------|------------|------------| | Native (C, x86_64 server) | 180 ms | 1,200 ms | 220 ms | 2,800 ms | | WASM (Chrome, M2 Mac) | 310 ms | 2,100 ms | 380 ms | 5,200 ms | | WASM (Chrome, mid-range PC) | 480 ms | 3,400 ms | 590 ms | 8,100 ms | | WASM (Safari, iPhone 15) | 520 ms | 3,800 ms | 640 ms | 9,500 ms | | JavaScript (Canvas only) | 850 ms* | N/A** | N/A** | N/A** |

*Canvas toBlob('image/jpeg') uses the browser's built-in encoder, which is less optimized than MozJPEG. **Canvas cannot produce optimized PNG, WebP, or AVIF natively with quality controls.

Interpreting the Numbers

WASM runs at roughly 55–70% of native speed for image encoding, depending on the codec and hardware. This is slower than native, but several factors tip the total equation in WASM's favor:

  1. No upload/download time: A 5 MB image on a 20 Mbps connection takes 2 seconds to upload alone. WASM eliminates this entirely.
  2. No server queue time: Under load, server-side processing queues add latency. WASM processes immediately on the user's device.
  3. Parallelism is free: Each user's device is a separate "server." Processing 1,000 concurrent users costs nothing extra.

For a single 12 MP image, total turnaround time including network:

| Approach | Processing | Network | Total | |----------|-----------|---------|-------| | Server-side | 180 ms | 3,500 ms (upload + download) | ~3,700 ms | | WASM (fast device) | 310 ms | 0 ms | ~310 ms | | WASM (mid-range device) | 480 ms | 0 ms | ~480 ms |

Even on a mid-range device, WASM is 7–8x faster in total turnaround because it eliminates network overhead.

WASM-Specific Optimizations for Image Processing

WASM performance is not just "compile and ship." There are specific techniques that maximize throughput for image workloads.

SIMD (Single Instruction, Multiple Data)

WASM SIMD is a set of 128-bit vector instructions that process multiple pixels simultaneously. It landed in all major browsers by 2023 and provides significant speedups for image operations:

  • Color space conversion: Converting RGB to YCbCr (needed for JPEG encoding) processes 4 pixels at once instead of 1
  • Filtering: PNG row filters, convolution, and blurring benefit from parallel arithmetic
  • Quantization: JPEG quantization tables can be applied to blocks of coefficients simultaneously

Enabling SIMD in Emscripten:

emcc -msimd128 -O3 ...

SIMD typically provides a 1.5–3x speedup for encoding operations, with the largest gains in JPEG and WebP encoding where color space conversion and DCT (Discrete Cosine Transform) dominate compute time.

Threading With SharedArrayBuffer

WASM supports multi-threading via SharedArrayBuffer and the Atomics API. This allows splitting an image into tiles and encoding them in parallel across Web Workers.

However, SharedArrayBuffer requires specific HTTP headers:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

These headers restrict cross-origin resource loading, which can break third-party embeds (ads, analytics, iframes). For this reason, many sites — including most image processing tools — opt for a simpler architecture: one Web Worker per image in batch processing, rather than multi-threaded single-image processing.

Streaming Compilation

Modern browsers can compile WASM modules while they are still downloading:

const wasmModule = await WebAssembly.compileStreaming(
  fetch('/codecs/mozjpeg.wasm')
);

This overlaps network download with compilation, reducing time-to-first-use. For a 200 KB gzipped WASM module, streaming compilation can save 50–100 ms compared to downloading first and then compiling.

Module Caching

Once compiled, WASM modules can be cached in IndexedDB:

// Cache the compiled module
const module = await WebAssembly.compileStreaming(fetch('/codec.wasm'));
const db = await openDB('wasm-cache', 1);
await db.put('modules', module, 'mozjpeg');

// Later: instantiate from cache (no recompilation)
const cachedModule = await db.get('modules', 'mozjpeg');
const instance = await WebAssembly.instantiate(cachedModule, imports);

Browsers also cache compiled WASM in their HTTP cache, but explicit IndexedDB caching gives you more control over versioning and invalidation.

Limitations of WASM Image Processing

WASM is powerful, but it has real constraints.

Memory Limits

WASM linear memory is currently limited to 4 GB (the 32-bit address space). For image processing, this means:

  • A single 8000x6000 pixel image at 4 bytes per pixel (RGBA) requires 192 MB for the raw pixel data alone
  • The encoder needs additional working memory (2–3x for JPEG, more for AVIF)
  • In practice, images up to ~50 megapixels can be processed comfortably; beyond that, memory pressure becomes an issue

The Memory64 proposal (WASM with 64-bit addressing) is in development and will remove this ceiling, but it is not yet available in browsers as of early 2026.

Mobile Performance

Mobile devices have less powerful CPUs and more aggressive thermal throttling. Processing a batch of large images on a phone will be slower than on a desktop, and sustained processing can trigger thermal throttling that reduces CPU clock speeds by 30–50%.

The practical implication: batch processing of 10 high-resolution images on a mid-range phone might take 30–60 seconds, compared to 8–12 seconds on a desktop. This is still faster than uploading and downloading those same images, but the user experience on mobile needs to account for longer processing times with clear progress indicators.

No GPU Access (Yet)

Current WASM cannot access the GPU for compute operations. Image processing operations like resizing, color adjustment, and format conversion would benefit enormously from GPU acceleration. The WebGPU standard provides this capability through JavaScript, and future proposals may bridge WASM directly to WebGPU compute shaders.

Some image operations can already be offloaded to WebGL shaders (resizing via texture sampling, basic filters), but the encode/decode step — the computationally heaviest part — remains CPU-bound in WASM.

Codec-Specific Limitations

Some advanced codec features are difficult or impossible in the WASM build:

  • libaom (AVIF) multi-threading: The full multi-threaded encoder is hard to compile to WASM with threading support due to the SharedArrayBuffer restrictions mentioned above. Single-threaded AVIF encoding is slow for large images.
  • Hardware-accelerated decoding: Native apps can use hardware JPEG/HEIC decoders. WASM always uses software decoding.

The Future of WASM Image Processing

Several proposals in the WASM specification pipeline will significantly impact image processing:

WASM GC (Garbage Collection)

Shipping in Chrome and Firefox, WASM GC allows languages with garbage collection (Go, Kotlin, Dart) to compile to WASM efficiently. This broadens the ecosystem of image processing libraries available in the browser.

WASM Component Model

The Component Model defines a standard way for WASM modules to interact with each other. This means you could compose an image processing pipeline from independent codec modules without going through JavaScript as an intermediary — reducing copying overhead.

Relaxed SIMD

The Relaxed SIMD proposal adds instructions that allow slight variation in results across platforms (in exchange for better performance). For image processing, where pixel-perfect reproducibility is rarely required, relaxed SIMD enables the use of faster hardware-specific instructions.

WASM on the Edge

WASM is also transforming server-side image processing. Edge computing platforms like Cloudflare Workers and Fastly Compute run WASM modules at CDN edge nodes. This gives you the security and portability of WASM with the power of server hardware and the low latency of edge proximity.

The long-term picture is convergence: the same WASM codec runs in the browser for instant local processing, and at the edge for scenarios where server processing is needed (automated pipelines, API-driven workflows).

Conclusion

WebAssembly has turned the browser into a genuine image processing environment. Codecs that were once locked behind server infrastructure — MozJPEG, OxiPNG, libwebp, libavif — now run at near-native speeds on the user's own device. The result is faster turnaround (no network round-trips), lower cost (no server compute), and better privacy (images never leave the device).

The technology is not without limitations. Mobile performance lags behind desktop, AVIF encoding is slow without multi-threading, and GPU compute remains out of reach. But the trajectory is clear: WASM is getting faster, more capable, and more widely supported with every browser release.

For web developers building image tools, WASM is no longer experimental. It is the practical, production-ready foundation for a new generation of client-side image processing — and it is only getting better.