Models and hardware

The background remover runs one of two open segmentation models client-side, and picks for you based on your hardware. On a desktop Chromium browser with WebGPU and half-precision shader support it runs BiRefNet lite on the graphics card. Everywhere else it runs IS-Net general-use on the processor. There is no model picker, because the right answer depends on your device, not on your photo.

Which model runs on my device?

	GPU path	CPU path
Model	BiRefNet lite (Zheng et al., 2024)	IS-Net general-use (Qin et al., 2022)
Weights	fp16 ONNX, 512×512 input	int8-quantised ONNX, 1024×1024 input
Download	98.5 MB, once	45.9 MB, once
Runtime	ONNX Runtime Web, WebGPU build	ONNX Runtime Web, WebAssembly build
Passes per photo	Two: whole frame, then zoomed on the subject	One
Typical time per photo	1 to 3 seconds	10 to 30 seconds
Licence	MIT	Apache-2.0
AI upscale	Available	Not available

The status line above the preview says GPU or CPU after each cutout, so you can see which one ran.

How does the tool choose?

It checks four things, in the worker, before loading anything:

1. WebGPU and shader-f16. The browser must expose a WebGPU adapter, and that adapter must support the shader-f16 feature, because the BiRefNet weights are half precision.
2. A Chromium engine. Chrome, Edge, Opera or Samsung Internet on a desktop OS. ONNX Runtime's WebGPU backend is built and tested against Chromium's implementation; Safari and Firefox fail in ways that only show on the first image, so they get the CPU path even when they expose WebGPU.
3. Not a phone or tablet. A 98 MB download on mobile data, and a model that can exhaust a mobile tab's memory, are worse than a slower result. iPads that report themselves as a Mac are caught by their touch points.
4. At least 4 GB of memory, where the browser reports navigator.deviceMemory. A lower figure sends the device to the CPU path.

All four true: GPU path. Any one false: CPU path. When the GPU device is created, the tool asks for the adapter's own maximums (storage buffers per shader stage, buffer sizes, workgroup sizes) rather than the spec's defaults, since the model needs more than the minimums.

What happens if the GPU path fails?

It falls back to the CPU model without asking you to do anything:

• If creating the GPU session fails (a driver bug, a lost device, not enough memory), the CPU model loads instead and a warning goes to the browser console.
• If a GPU run throws, or returns a mask that is empty, NaN or one flat value, the photo is re-run on the CPU model and the rest of the session stays on it.

The second check exists because a GPU backend can fail silently. ONNX Runtime's older JavaScript WebGPU backend had a shader that did not compile on Apple GPUs and, instead of throwing, returned an empty mask. A real mask of a real photo always varies, so a flat one is treated as a failure.

Why BiRefNet lite at 512 and not the 1024 export?

The 1024 export concatenates 1,024 patch tensors in a single graph node, and that node needs more storage buffers per shader than WebGPU allows on Apple GPUs (10). Every Mac failed on the first image and fell back to the CPU. The 512 export fits.

To win back the lost detail, the GPU path runs the model a second time on a crop around the subject:

• The crop is the subject's bounding box, padded by 12% of its longer side.
• It is skipped when the subject already fills 85% of the frame, when the crop would be under 32 pixels, or when a loose crop holds a sparse subject (glasses frames, a bicycle), where a second pass can lose thin parts.
• The two masks are merged on a 1024×1024 grid, with the zoomed pass winning inside the crop and an 8 pixel feather at its inner edge so no seam shows.

IS-Net already takes a 1024 input, and a second 1024 pass on a processor would double a wait that is already the longest part, so the CPU path does one pass.

Why is the CPU path single-threaded?

WebAssembly threads need SharedArrayBuffer, which browsers only enable on cross-origin isolated pages. Toolz.dev does not send the headers that turn cross-origin isolation on, so ONNX Runtime runs on one thread. That is most of the difference between 1 second on a GPU and 10 to 30 seconds on a CPU.

Where is the model stored?

In the browser's Cache Storage, in a cache named toolz-ai-models-v1, keyed by the model's URL. The files come from Hugging Face, pinned to a specific commit so the weights never change under you; the CPU model has a second mirror in case the first is unreachable. When the page preloads the model it also asks the browser to make its storage persistent (Storage Standard), so the model is not evicted under storage pressure. The browser may say no, in which case the model downloads again after an eviction.

To free the space, clear site data for toolz.dev in your browser settings. The next photo downloads the model again.

Why not RMBG-1.4?

The model most in-browser background removers ship, BRIA RMBG-1.4, is released for non-commercial use only. Toolz.dev is a commercial product, so it uses models under MIT (BiRefNet) and Apache-2.0 (IS-Net), plus BSD-3-Clause for the Real-ESRGAN upscaler. IS-Net is the same architecture RMBG-1.4 is built on.

For how the model output becomes clean edges, continue to Edge quality. For a guided walk through the whole pipeline, read how AI background removal works.