Browser Support and Performance for Client-Side Background Removal

What the Browser Has to Provide

A client-side background remover runs inside a web page, so every capability it needs must be exposed by the browser rather than installed. Four matter, and a device missing any one cannot run the tool.

WebAssembly runs the model in the browser's own sandbox, which keeps a client-side tool's footage on your device; bgremover.ai instead uploads it to our GPU servers, as how background removal works explains. Inference is mostly matrix multiplication, so it wants a GPU: WebGL exposes one through a graphics API, WebGPU through a compute API.

Without either, inference falls back to the CPU. Something must also encode finished frames into a file: MediaRecorder, the wider route, or WebCodecs, the finer one. The fourth requirement, memory for decoded frames, is the most underestimated.

Three Execution Paths

WebGL is a workaround rather than a design: the API was built to draw triangles, and moving data through textures costs time. It stays the practical default. WASM competes for the main thread unless the work moves to a worker, and BEN2 needs FP16 WebGPU, so recent desktop GPUs only.

Availability decides this, not preference: a tool implementing only WebGPU is fast where it runs and absent everywhere else.

Why the First Run Is Slower

1. 1 The model downloads once

   Before any frame is processed.

2. 2 It initialises and warms up

   Then the first frame goes through.

3. 3 Later clips skip both

   Served from cache, so only initialisation remains.

A client-side tool should therefore load the model on a user gesture, not on page load: megabytes of WebAssembly arriving as you land would make the page feel broken for anyone who came to read.

The Arithmetic of Decoded Frames

A decoded video frame is uncompressed pixels, so resolution dominates memory.

Those figures are arithmetic, not measurements, and compressed file size is a poor guide. Nothing needs every frame decoded at once, but the pipeline holds a working set: the frame decoding, the one being segmented, its mask, the composite, and the encoder's buffer.

Multiply a few frames by 33 MB at 4K and a tab's budget starts to matter, especially on a phone. If a long high-resolution clip fails or the tab reloads, cut resolution rather than length: halving each dimension quarters the memory.

What Determines Processing Time

These are relationships, not numbers: a time measured on one laptop tells you nothing about a phone.

• Frame countDuration times frame rate; 60 fps doubles 30 fps.
• ResolutionDrives decode, composite and encode; inference stays fixed.
• Execution pathWebGPU, WebGL and WASM-SIMD differ on one machine.
• Device classDesktop, laptop and phone GPUs are three machines.
• Model choiceMatting costs more per frame than MediaPipe.
• Thermal stateSustained GPU work on a warm phone is throttled.

Browser Support Matrix

Per-browser verification belongs here before the site claims universal support. The claim we can make untested is architectural: a client-side tool needs WebAssembly and a GPU path, not WebGPU. bgremover.ai needs WebCodecs, which it uses to prepare the upload and build the export.

The Honest Mobile Picture

For a client-side tool, MediaPipe selfie segmentation's small footprint is what makes mobile browsers viable at all. A few megabytes with modest memory demands fits a phone's tab budget; a desktop-GPU model does not. bgremover.ai sidesteps this by running its model on GPU servers; the phone still decodes and encodes the clip.

We will not claim universal mobile support before testing per browser. Mobile is harder: less memory per tab, aggressive eviction, thermal throttling. Shorter clips at lower resolution are the reliable path, and stills through the photo background remover cost one frame.

Frequently Asked Questions