DEV Community: Saba Khan

How I built a browser-side background remover (and benchmarked Canvas vs WebAssembly)

Saba Khan — Thu, 25 Jun 2026 09:58:00 +0000

I had 300 product photos sitting in a folder. White backgrounds, mostly. I needed them on transparent backgrounds for a client's Shopify store. The obvious move: upload them to some online background remover. Five minutes, done.

Then I thought about it. These were unreleased product shots. Uploading them to a random server felt wrong. Plus, I'd have to do this every month when new products came in. I wanted something that ran locally.

Browsers can do this now. The question was how well.

Two approaches, one browser tab

There are two practical ways to remove backgrounds in the browser without sending pixels to a server:

Canvas API pixel bashing. You load the image onto a <canvas>, grab the pixel data with getImageData(), and manually set alpha values. Pick a reference color from the background, calculate each pixel's distance from it, threshold it. This is fast and needs zero dependencies. But it only works on uniform backgrounds.

WebAssembly + ML model. You compile a segmentation model to WASM, load it, and run inference in the browser. ONNX Runtime Web makes this practical. It handles hair, fur, complex edges — but you're downloading an 8+ MB model and burning more CPU.

I built both and ran them through 500 test images. Here's what happened.

Canvas approach: fast and dumb

The code is straightforward. Load the image, sample a pixel from a corner (assuming that's the background), and set alpha to zero for every pixel within a threshold:

function removeBackgroundCanvas(image, threshold = 40) {
  const canvas = document.createElement('canvas');
  canvas.width = image.width;
  canvas.height = image.height;
  const ctx = canvas.getContext('2d');
  ctx.drawImage(image, 0, 0);

  const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
  const data = imageData.data;

  // Sample background from top-left corner
  const bgR = data[0], bgG = data[1], bgB = data[2];

  for (let i = 0; i < data.length; i += 4) {
    const dr = data[i] - bgR;
    const dg = data[i + 1] - bgG;
    const db = data[i + 2] - bgB;
    const distance = Math.sqrt(dr * dr + dg * dg + db * db);

    if (distance < threshold) {
      data[i + 3] = 0; // Set alpha to 0
    }
  }

  ctx.putImageData(imageData, 0, 0);
  return canvas;
}

This works surprisingly well on studio-lit product photos. A white or light-gray background gets nuked in about 15 milliseconds per image on my laptop. No dependencies, no loading spinners, no model downloads.

The problem: as soon as the background isn't uniform — a gradient, a textured wall, someone's shirt that's close to the wall color — it falls apart. You get jagged edges, halos, or chunks of the subject vanishing.

WebAssembly approach: accurate and heavy

For real images, you need a model that understands what's foreground and what's not. MediaPipe's selfie segmentation model runs in the browser and can be loaded via ONNX Runtime Web:

import * as ort from 'onnxruntime-web';

async function removeBackgroundML(image) {
  const session = await ort.InferenceSession.create('model.onnx');

  // Preprocess: resize to model input size, normalize
  const tensor = preprocessImage(image, 256, 256);

  const results = await session.run({ input: tensor });
  const mask = results.output.data; // Float32Array, 256x256

  // Apply mask as alpha channel
  return applyMaskToImage(image, mask);
}

The catch: the model file is 8.3 MB. First load takes about 1.2 seconds on a fast connection. Inference takes roughly 180-220 milliseconds per image. You're also pulling in onnxruntime-web which adds about 2 MB to your bundle.

But the output is dramatically better. Hair strands, fur, transparent objects — things the Canvas approach can't touch — get handled reasonably well.

The benchmark

I ran 500 images through both approaches on a 2023 MacBook Pro (M2, 16 GB RAM):

Metric	Canvas	WebAssembly
Time per image	12-18 ms	180-220 ms
Model load time	0 ms	1,100 ms
Memory peak	24 MB	180 MB
Works on uniform bg	Yes	Yes
Works on complex bg	No	Yes (mostly)
Handles hair/fur	No	Yes
Bundle size added	0 KB	~10 MB

The Canvas approach is basically free — you're already paying for image decoding, and the pixel loop runs at native speed once the JIT kicks in. On 500 images, total processing time was under 8 seconds.

The WebAssembly approach took about 95 seconds for the same batch, plus the initial model download. But it handled 412 out of 500 images correctly, versus 187 for Canvas.

What I ended up doing

I combined both. The tool tries the Canvas approach first. If more than 30% of edge pixels end up partially transparent — a sign of a non-uniform background — it falls back to the ML model. This hybrid approach averages about 40 ms per image on typical product photo batches.

If you need a browser-based background remover that handles both simple and complex images, this one runs entirely on your machine. The UI is in Spanish, but drag-and-drop needs no translation.

A few things I learned that aren't obvious from the docs:

getImageData() triggers a GPU-to-CPU readback on most browsers. If you're processing multiple images in sequence, batch your Canvas operations before reading pixels back, or you'll pay the sync cost every time.
ONNX Runtime Web has two backends: wasm and webgl. The WebGL backend is 3-5x faster for inference but only works if WebGL is available. Always check ort.env.wasm.numThreads and set it to navigator.hardwareConcurrency — otherwise you'll leave cores idle.
For product photos, 256x256 model input is enough. Going to 512x512 buys you noticeably better edges but roughly 4x the inference time. Not worth it unless you're doing professional retouching.

If you just need to quickly strip a background from a photo, try the Canvas approach first. It's simpler than you think. If it doesn't work, the browser can run a real ML model now — you just need to wait a second.

I reverse-engineered browser image compression — here's the actual code

Saba Khan — Sun, 21 Jun 2026 06:26:24 +0000

I had 200 product photos to compress for a client's e-commerce site. The Photoshop batch processor worked, but launching a 2 GB application to run one command felt like using a flamethrower to light a candle. I wanted something that ran directly in the browser — no installs, no uploads to some random server.

How browser image compression actually works

There are three real approaches:

Approach	How it works	Upside	Downside
Canvas API	Draw image to `<canvas>`, export with `toBlob()`	Zero dependencies, works everywhere	Limited to Canvas-supported formats
WebAssembly	Compile libjpeg-turbo or libwebp to WASM	Full control over compression params	Heavy bundle (~500 KB), complex setup
OffscreenCanvas + Workers	Do Canvas compression on background threads	Non-blocking UI, batch-friendly	Browser support still patchy

I picked Canvas. For 90% of real-world cases — product photos, blog images, user uploads — it handles the job without adding a 500 KB WASM binary to your bundle.

The code

Here is the core function:

function compressImage(file, { quality = 0.7, maxWidth = 1920, format = 'image/webp' } = {}) {
  return new Promise((resolve, reject) => {
    const reader = new FileReader();

    reader.onerror = reject;
    reader.onload = (e) => {
      const img = new Image();
      img.onerror = reject;
      img.onload = () => {
        let { width, height } = img;
        if (width > maxWidth) {
          height = Math.round(height * (maxWidth / width));
          width = maxWidth;
        }

        const canvas = document.createElement('canvas');
        canvas.width = width;
        canvas.height = height;

        const ctx = canvas.getContext('2d');
        ctx.drawImage(img, 0, 0, width, height);

        canvas.toBlob(
          (blob) => {
            if (!blob) return reject(new Error('toBlob returned null'));
            resolve(blob);
          },
          format,
          quality
        );
      };
      img.src = e.target.result;
    };
    reader.readAsDataURL(file);
  });
}

Wiring it up to a file input:

const input = document.querySelector('#image-input');

input.addEventListener('change', async (e) => {
  for (const file of e.target.files) {
    const originalSize = file.size;
    const compressed = await compressImage(file, { quality: 0.6, format: 'image/webp' });

    console.log(
      `${file.name}: ${(originalSize / 1024).toFixed(0)} KB → ${(compressed.size / 1024).toFixed(0)} KB ` +
      `(${((1 - compressed.size / originalSize) * 100).toFixed(0)}% smaller)`
    );
  }
});

A bug I hit: the PNG default trap

canvas.toBlob(callback) without a format argument defaults to image/png. PNG is lossless — your "compressed" image ends up larger than the original JPEG. I spent 20 minutes wondering why my 2 MB file turned into a 4 MB blob.

Always pass the format explicitly. 'image/webp' is the right call in 2026 — every browser supports it now.

Batching without freezing

For multiple files, fire them all at once with Promise.all:

async function compressBatch(files, opts) {
  const blobs = await Promise.all(
    Array.from(files).map(f => compressImage(f, opts))
  );
  // blobs ready — download individually or pack into a zip
  return blobs;
}

For 100+ images, move the canvas work into a Web Worker with OffscreenCanvas. The API looks almost identical but runs off the main thread. No more frozen tabs.

Real numbers

I grabbed 50 product photos from an e-commerce catalog (average 2.4 MB JPEG, 3000×3000 px):

Quality	Format	Avg output	Reduction	Visual quality
0.9	JPEG	310 KB	87%	Same as original on screen
0.7	JPEG	145 KB	94%	Slightly softer edges at 200% zoom
0.7	WebP	98 KB	96%	Matches JPEG 0.9 to the naked eye
0.5	WebP	62 KB	97%	Fine for thumbnails, too aggressive for product pages

Total time for 50 images: 4.2 seconds (Chrome 126, M1 Mac). That is under 85 ms per image.

For the e-commerce project, WebP at quality 0.7 was the clear winner. 96% smaller files, zero visible difference on a 27-inch display.

What the Canvas approach cannot do

PDF compression, background removal, and format conversion (PNG to SVG, etc.) all need different pipelines. You can build those with WebAssembly, but that belongs in a separate article.

What I took away from this

Browser image compression works better than most people assume. You do not need a server, a library, or Photoshop. Roughly 50 lines of JavaScript gets you 96% compression with no visible quality loss.
canvas.toBlob() without a format argument will burn you. Always pass 'image/webp' or 'image/jpeg' explicitly.
Web Workers make batch processing genuinely usable on 50+ images without freezing the tab.

I put all of this into a tool at ComprimeFotos. The UI is in Spanish (I originally built it for a Spanish-speaking audience), but the tool itself needs no translation — drag an image, it compresses, you download. No signup, no ads, no uploads.

My first post on DEV.to

Saba Khan — Sun, 21 Jun 2026 05:59:37 +0000

I’m a web development enthusiast who likes recording daily coding practice and sharing practical web tech knowledge.
In the future, I will keep posting tutorials about front-end development and programming tips here, and look forward to communicating with all developers.