On-device background removal, verifiably local

"Runs in your browser" is a claim most tools ask you to take on trust. The background remover and the cutout inside the thumbnail maker are built so that you do not have to. The segmentation models are files this site serves from its own /vendor/ directory; your browser downloads them and executes them locally; and the only network traffic a photo ever causes is that download — towards your device, never away from it. This guide explains what the three models are, what each first-use download contains byte for byte, how to watch the whole thing happen in your browser's developer tools, why the largest model analyses at 512×512 on the CPU provider, and what the tool does when a model will not load. Every figure below is measured or computed at build time from the same vendored files and tested code the tools use, so this page cannot disagree with them.

Three models, three tiers

The remover offers three on-device engines, and the picker lists them in this order. Each option carries a download label produced by the tested tier catalog from byte counts measured at build time — the label is what the tier will actually fetch the first time you use it.

The first tier runs a person-segmentation model — the same one behind the maker's cutout toggle — so it is tuned for photos of people. The second runs an interactive model that segments whatever subject sits at the point you click. The third runs a dichotomous image segmentation model built for subject-versus-background cutouts of any kind, and it is the largest download by design. All three hand back the same thing: a per-pixel confidence mask at the photo's own resolution, which one shared refinement step turns into the alpha channel of a transparent PNG. The runtime versions in this table are read from the project's dependency manifest at build time, and the test suite pins them exact.

What each download actually contains

The tier labels are sums, not estimates. At build time the tool page — and this guide — measures each file the SIMD runtime path fetches with the file system and formats the totals with the same function the picker uses. The vendored provenance note records a second, no-SIMD copy of the MediaPipe runtime that the MediaPipe loader selects on browsers without WebAssembly SIMD; it is not part of these totals. These are the files, with their sizes as measured for this build:

A blank Size cell means the file is smaller than the formatter's one-decimal resolution — it would otherwise print as 0.0 MB — so that row's byte count stands alone; the bytes are still part of the tier total.

The two MediaPipe tiers share one runtime, so the arithmetic is short. Fast mode is the runtime binary and loader (11.5 MB) plus the selfie model (0.2 MB), which the catalog reports as ~11.7 MB on first use. "Click the subject" is the same runtime plus the MagicTouch model (6.2 MB), reported as ~17.7 MB on first use — the two tiers request the same runtime files, so the second tier adds only its model file to what the browser must fetch when the runtime is still cached. Best quality uses a different runtime entirely: the BiRefNet_lite export (59.1 MB) plus the onnxruntime-web binary and loader (27.8 MB), reported as ~86.9 MB on first use. The megabytes are SI megabytes of one million bytes, rounded to one decimal, which is why the raw byte counts sit beside them.

Self-hosted under /vendor/, with provenance

None of these files comes from a CDN or any third-party host. The MediaPipe runtime and both .tflite models live under /vendor/mediapipe/; the BiRefNet_lite model and the onnxruntime-web runtime live under /vendor/birefnet/ and /vendor/onnxruntime/. Each directory ships a provenance note alongside the files — source URLs, versions and repository revisions, checksums, the derivation and verification chain for the ONNX export, and the full license text — and, for the BiRefNet_lite model and the onnxruntime-web files, a test suite pins every vendored byte size and the runtime version, so those notes cannot silently drift from what is served. Self-hosting is what makes the privacy claim checkable rather than merely stated: if the only host your browser talks to is this one, there is no third party to receive an image. Running WebAssembly required exactly one addition to this site's Content-Security-Policy, 'wasm-unsafe-eval' in script-src, verified against a server sending the production headers.

Verify it yourself in DevTools

The methodology page describes the check in one sentence; here it is as a procedure, with what you should expect to see at each step.

1. Open the background remover (or the maker), then open your browser's developer tools and switch to the network panel. Clear it so only new requests show.
2. Choose a photo. The file is read by local JavaScript and shown from memory; no request appears that carries it.
3. Pick a tier and run the cutout. You will see requests to this site's /vendor/… paths — the files in the table above for that tier — and none to any other host.
4. Compare the decoded resource (content) size column with the byte counts above — the transfer column is smaller when the server compresses a file. They are the same files.
5. Adjust the edge, paint with the restore or erase brush, and download the PNG. Each of those is canvas work in your tab; none of them produces a request.

What you will not see is any request that sends the image: no upload, no request to a third-party domain, no image bytes leaving the page. The "on first use" wording on the picker is literal — the model files are ordinary static assets, fetched the first time a tier runs.

The 512×512 constraint and the CPU-only decision

Best quality runs BiRefNet_lite as a 512×512 ONNX export with 4-bit-quantized weights. That input size is not a stylistic choice but a measured constraint: the full 1024×1024 export needs roughly 6 GB of working memory at inference, which exceeds the ~4 GB WebAssembly heap every browser gives a page — so the previous 1024 artifact failed for everyone, and the shipped one was verified to actually run and to reproduce the reference model's masks (the mask-parity measurements are in the provenance note). The consequence for you is simple: the model looks at a 512×512 version of the photo, and the confidence mask it returns is scaled back up to the photo's real dimensions and refined there, so the PNG you download has the same pixel size as the file you chose.

The model executes on onnxruntime-web's WASM CPU provider inside a worker thread, so the page stays responsive while it works. The WebGPU provider was tested and produced silently wrong output for this model on the pinned runtime version — inference resolved as if nothing had failed and returned a useless mask — so it is deliberately not used. A quality tier that quietly returns an empty mask would be worse than a slightly slower one that is right. That decision is revisited only when a runtime upgrade passes a known-answer check, never by assumption.

When a model will not load

A model file can fail to arrive (a blocked request, a proxy, an interrupted connection), a runtime can fail to start, or an inference can fail part-way. In the maker, if the model fails to load, the cutout toggle disables with a message and the rest of the editor keeps working — nothing else on the page depends on the model. The remover's engines follow the same doctrine: a failure is thrown honestly to the page rather than swallowed. The MediaPipe engines clear a failed load so the next attempt retries from scratch; the best-quality engine goes further — a failed download or session creation clears its singleton, and a failed inference disposes the session and clears the singleton before the error reaches the page, so a retry never reuses a dead session. It also tags each failure with the phase it happened in — download, session creation, or inference — so the status message can say what actually went wrong rather than blaming your connection for an out-of-memory error. On the remover the Remove button comes back after a failure, so you can try again.

Input rules, computed from the engine

Before any model runs, the file is checked by a pure function with its own tests. It accepts image/png, image/jpeg, image/webp and refuses anything over 20 MiB (20,971,520 bytes — the "20 MB" the error message names). Rejections name the actual problem: the real type of an unsupported file, the real limit for an oversized one, and a distinct message for a zero-byte file, which is a common symptom of a failed download or cloud sync. The verdicts below were produced by calling that function at build time:

The download is always a PNG, a lossless format with a real alpha channel, and its name is derived from your file's name: extension stripped, anything that is not a letter or digit collapsed to single hyphens, cut to 60 characters, with -cutout.png appended. Letters outside ASCII survive; a name with nothing usable falls back to image. An 80-character base name comes back as 60 characters plus the suffix.

If you choose a solid background instead of transparency, the color is normalised to lowercase six-digit hex before it is drawn; anything the normaliser cannot read is rejected so the tool falls back explicitly rather than feeding garbage to the canvas:

Where the cutout lands

Fast mode is the same engine that powers the cutout inside the thumbnail maker, where the result is placed over the maker's own gradients, outlined text, and shapes. The maker's canvases, described by the tested ratio engine, are:

Do the cutout on the remover page if you only want the PNG; do it in the maker if you are building the whole thumbnail on the 1280×720 canvas. The size rules for the finished image are on the size guide, and YouTube thumbnail sizes, explained covers why 1280×720 is the size that satisfies every upload path; the other mechanisms are under guides.

Common misreadings

• "Local means no download." Local means the model runs on your device, which is exactly why it must first reach your device. The download is the model, not your photo.
• "The 512×512 model produces a 512×512 cutout." The model analyses at that size; the mask is scaled back to the photo's real dimensions and refined there, and the PNG matches your input's pixel size.
• "The GPU would be faster, so it should be on." On the pinned runtime version it produced silently wrong output for this model. Correct output on the CPU provider wins over wrong output delivered quickly.
• "A big model download means the site is collecting something." Watch the network panel: the requests are static files from this site to you, and nothing travels the other way.

Frequently asked questions

Every figure on this page is measured from the vendored files or computed by the tested engines at build time. The segmentation runs locally in your browser and photos are never transmitted; see the methodology page for how the engines are tested.