Browser vs Cloud: Why Running AI in Your Browser Matters for Image Privacy

Published: 28 July 2026 · 7 min read

When you use an AI image tool — background removal, upscaling, object recognition — the AI model is running somewhere. The question is where. For almost every AI tool you use online, the answer is "on a GPU server in a data center, probably in Virginia or Oregon." For a small but growing number of tools, the answer is "in your browser, on your device, using WebAssembly."

The architectural difference between these two approaches has implications for privacy, speed, cost, and capabilities. Here's how they actually work, and why it matters.

How server-side AI image processing works

The flow is straightforward:

  1. You upload an image via a web form. The browser sends a POST request with the image data as the payload — typically as a multipart/form-data upload or a base64-encoded blob in a JSON body.
  2. The request hits a load balancer, which routes it to an application server (Node.js, Python/Flask, Go, etc.).
  3. The app server preprocesses the image — resizing, format conversion, normalization — and queues it for inference.
  4. A GPU worker (typically running on NVIDIA A10, A100, or T4 instances on AWS/GCP/Azure) loads the neural network model into VRAM and runs forward inference on the image tensor.
  5. The model outputs a segmentation mask (for background removal), an upscaled image (for super-resolution), or whatever the task requires.
  6. The result is post-processed, converted to the requested output format, and sent back to the browser as a download or display URL.
  7. The original uploaded image sits on the server until something deletes it — could be seconds, could be days, depending on the provider's data retention policy.

This architecture has real advantages. The GPU hardware is fast — an A100 can process dozens of images simultaneously at FP32 precision. The model can be arbitrarily large: 500MB, 1GB, even multi-gigabyte models are feasible when they live in a data center with hundreds of gigabytes of VRAM. The inference is predictable — you're not at the mercy of someone's 2018 Chromebook struggling with a 2.3GHz Celeron.

But it also means every image you process is now on someone else's computer. The company running the service has access to it. Their employees potentially have access to it. If they use AWS, Amazon's infrastructure processes it. If the service gets acquired, the new owner inherits the data. If there's a security breach, your images are in the blast radius.

How browser-based AI image processing works

The flow is simpler but technically harder to pull off:

  1. You select an image. The browser reads it from disk into memory using the File API — no network request is made.
  2. The image is decoded by the browser's built-in codec (JPEG/PNG/WebP/HEIC etc.) and drawn to an offscreen Canvas element.
  3. A JavaScript image processing library reads the pixel data from the canvas using getImageData(), which gives access to the raw RGBA buffer.
  4. The neural network model, which was downloaded once from a CDN on first use and cached by the service worker, is loaded by an ONNX runtime compiled to WebAssembly.
  5. The image tensor (a normalized, resized version of the pixel buffer) is fed into the model. Inference runs on the CPU or, if available, through WebGPU which can access the device's integrated or discrete GPU.
  6. The model outputs a mask (for segmentation tasks) or a processed image tensor, which JavaScript code converts back to pixel data, writes to a canvas, and offers as a download via canvas.toBlob().
  7. At no point does any image data leave the browser's memory space. The Network tab stays silent except for the initial model download.

The key enabler here is WebAssembly + ONNX Runtime Web. WebAssembly is a binary instruction format that runs at near-native speed in the browser. ONNX (Open Neural Network Exchange) is an open format for AI models that allows a model trained in PyTorch or TensorFlow to be exported and run anywhere. ONNX Runtime Web is a JavaScript library that loads ONNX models and executes them via WebAssembly, with optional WebGPU acceleration for operations that benefit from parallel GPU execution.

IMG.LY's ISNet — the model BackgroundDelete uses — was originally trained in PyTorch, exported to ONNX, quantized (reduced precision from FP32 to FP16 or INT8 to shrink model size), and optimized for the ONNX Web runtime. The 80MB "Best" model is the full FP32 version. The 40MB "Balanced" is FP16. The 4MB "Fast" is INT8 quantization. The quality difference between them is the precision loss from quantization — fewer bits per weight means coarser gradient decisions at object boundaries.

What you gain with browser-side processing

Zero-trust privacy. You don't have to trust the service provider's privacy policy because there's nothing to trust — they never receive your data. This isn't "we encrypt your data" or "we delete it after processing." It's "we never had it in the first place." For journalists, lawyers, medical professionals, people in countries with surveillance regimes, or anyone processing sensitive images, this distinction is everything.

Offline capability. After the model downloads once, the entire processing pipeline works without an internet connection. This matters in places with unreliable connectivity, on airplanes, in secure facilities where internet access is restricted, or when you're traveling and don't want to burn roaming data on image uploads.

No server costs for the operator. This is the economic reason browser-based AI is viable for free tools. Server-side inference costs real money — GPU instances run $1-4/hour, and processing thousands of images per day adds up. Browser-side inference costs the operator nothing after the CDN bandwidth for the initial model download. The user's device does the work. This is why BackgroundDelete can be free forever with no limits — there's no per-image cost to cover.

No queue, no throttling. Cloud AI services use queues to manage GPU capacity. During peak usage, free-tier users get deprioritized. Browser-based tools don't have queues because there's no shared resource to queue for. Your CPU/GPU is dedicated to your task.

What you lose

Model size is severely limited. A browser tab gets ~2-4GB of usable memory on a typical device. The model, the runtime, the image data, and the application all have to fit in that budget. Server-side models can be 500MB-2GB+ running on GPUs with 40-80GB of VRAM. Bigger models = more parameters = better quality, especially for edge cases. The WebAssembly quantized versions lose some fidelity — maybe 5-15% depending on the image and the task.

Inference speed varies wildly by device. On a 2024 MacBook Pro with an M4 chip, browser-based AI inference is fast — comparable to a mid-range server GPU for a single image. On a 2019 ThinkPad with integrated Intel graphics, it's noticeably slower. Server-side inference is consistent regardless of the user's device.

First-visit download. The model must download before first use. An 80MB download on a 5Mbps connection is about 2 minutes. On a 100Mbps connection, it's 7 seconds. After that, the service worker caches it and it loads from disk. But that first visit has a real cost in user patience.

Limited to what WebAssembly can do. Some AI operations — large matrix multiplications, certain attention mechanisms in transformers — benefit enormously from GPU parallelism. WebGPU is closing this gap, but server-side GPUs with CUDA-optimized kernels are still faster for large models. For the image segmentation models used in background removal, this gap is narrowing fast — the models are small enough and the operations are well-supported in WebAssembly SIMD instructions.

The trend line favors the browser

Three trends are making browser-based AI more capable every year:

1. WebGPU is going mainstream. Chrome shipped WebGPU in 2023. Firefox and Safari followed in 2024-2025. WebGPU gives browser applications direct access to the GPU's compute shaders — the same hardware that makes server-side CUDA inference fast. For image processing tasks (convolutions, matrix multiplies, pixel-wise operations), WebGPU can be 5-20x faster than WebAssembly CPU execution.

2. Model quantization is getting smarter. Techniques like GPTQ, AWQ, and GGUF quantization have shown that you can compress AI models to 4-bit or even 2-bit precision with surprisingly small quality loss. What required an 80MB FP32 model in 2023 might run at comparable quality in a 20MB INT4 model in 2026. Smaller models mean faster downloads and lower memory pressure.

3. Consumer hardware keeps improving. The M4 chip in a 2024 MacBook has a 16-core Neural Engine capable of 38 trillion operations per second. The Snapdragon X Elite in Windows laptops has a 45 TOPS NPU. These aren't just GPU improvements — they're dedicated AI accelerators that ONNX Runtime is starting to target through platform-specific execution providers.

The combination means that for an expanding set of AI image tasks — background removal, object detection, style transfer, super-resolution, denoising — browser-based processing is already good enough for professional use. For privacy-sensitive applications, it's the only responsible choice.

Server-side AI will always be better at the absolute frontier of model capability. The largest models, the newest architectures, the highest quality outputs — those will run in data centers for the foreseeable future. But the gap between "best possible" and "good enough" gets smaller every year. For most people, most of the time, the tradeoff — slightly lower absolute quality in exchange for complete privacy, zero cost, and offline capability — is the right one.

Try browser-based AI background removal →