WebGPU and WASM in a Browser Background Remover.

Separate the model from the execution provider

The model describes the computation used to predict a mask. The execution provider determines how that computation runs on the device. Changing the provider does not automatically select a better model or increase the input resolution. It can change performance and compatibility, but the resulting application still needs to prepare the image and interpret the output correctly.

Backdropless uses ONNX Runtime Web to execute its pinned U2netp graph. The app attempts a WebGPU session and falls back to WASM when GPU setup or execution fails. Both paths process the image locally. The fallback is therefore a compatibility route, not permission to upload the photograph to a remote inference service when the device lacks a GPU capability.

Capability is more specific than a browser name

WebGPU availability depends on the browser, device and runtime environment. MDN documents its secure-context requirement and limited availability. The presence of an API entry point also does not guarantee that every model operator will execute successfully. A tool must handle failure at session creation and at inference, rather than assuming that an initial feature check proves the whole path.

This is why a browser label alone is a weak compatibility promise. A managed device, driver configuration or restricted environment can behave differently from a developer’s machine. Users need a clear progress or error message and a usable fallback when one exists. An unsupported path should not leave a permanent spinner that looks like ongoing processing.

Understand the first-run delay

A cold run includes loading application code, obtaining model weights and creating an inference session before the actual mask computation. A warm run may reuse some of those assets or state. Timing only the second run and calling it a universal processing time would hide the first-use experience. Network and device conditions also differ between people.

Our public model page therefore avoids a fixed speed promise. The test evidence records actual successful outputs, while the page explains the model download and known visual limits. A small model download is useful for this product, but file size alone does not determine latency or quality. The user still needs to inspect the result after the computation finishes.

Worked example: a GPU fallback

Imagine a browser that exposes WebGPU but cannot create a compatible session for the model. The application catches that failure and creates a WASM session. It then runs the same selected image through the local model and returns a mask to the editor. The meaningful success condition is an inspectable result and a working export, not the mere presence of a GPU-related property.

A second failure can occur after a session was created, during execution. The application also needs to handle that case. If the fallback cannot complete, it should explain that local removal failed while keeping the original safe. A manual editing path or a different device may be appropriate, but the interface should not silently substitute an unrelated remote service.

Memory use is part of compatibility

A compressed source file can decode into a much larger pixel buffer. The model input, full-size source, mask, preview and brush history can coexist in memory. A batch can multiply those demands if it is not processed carefully. This is one reason the Backdropless workspace has explicit size limits and processes batch images sequentially.

A maximum accepted image size is not a guarantee that every device has enough available memory at that size. Other tabs and applications affect the environment. If a device struggles, use a smaller source or close unrelated heavy work, while preserving the original. A clear local failure is preferable to pretending that a browser editor has unlimited resources.

Test the actual fallback path

A useful test disables or denies the GPU route and verifies that removal still produces a downloadable image. It should inspect the output, not merely assert that a fallback function was called. Network failure and model-download failure are separate cases because neither execution provider can run without valid model data. Those conditions need understandable messages as well.

The same principle applies to cached assets. A cached model can reduce repeat downloads, but storage may be cleared or unavailable. The application should treat caching as an optimization rather than a prerequisite for correctness. Local inference and reliable offline installation are different product promises, and this browser tool makes only the former.

Choose based on the editing result

For the person using the tool, the practical questions are whether the source opens, the mask is useful, the controls respond and the export is correct. An execution-provider label can help diagnose a problem, but it should not replace those checks. A fast wrong mask is still wrong, and a slower correct workflow may be more useful for the task.

Try a representative image on the actual device. Review fine edges and transparent materials separately from performance. If the result needs extensive repair, a different capture setup or model may matter more than the execution provider. The linked evaluation shows the shipped model’s actual behavior so that the decision can rest on visible evidence rather than an acronym.

Separate compatibility from availability

A model-download failure is not a verdict on the device’s GPU. A cached model may run after a temporary connection problem, while a fresh session cannot begin without the required assets. Record which stage failed: source opening, model retrieval, session creation, inference or export. That sequence gives a support report useful evidence and avoids sending the user through unrelated browser settings. The visible error should describe the failed stage without suggesting that the photograph must be uploaded elsewhere.