Background Remover

Runs entirely in your browser — verifiably

Many background removers upload your photo to a server, process it there, and meter the results with credits or watermarks. This one does not: it runs open-source segmentation models — Google's MediaPipe selfie segmenter for fast mode, the MagicTouch interactive segmenter for click-to-select (both Apache-2.0), and BiRefNet_lite (MIT, executed by the MIT onnxruntime-web engine) for best quality — inside your browser, from model files this site hosts itself — no signup, no watermark, no credits, and the photo is never uploaded. That is a checkable claim, not a slogan: open DevTools, watch the network panel while you process a photo, and you will see model files arrive from this site and no image bytes leave the page. The model versions, licenses, and provenance (including file hashes) are documented on the methodology page and pinned in the repository.

Read the guide: On-device background removal, verifiably local — the long-form walk-through of the three models, the DevTools check, and the memory measurement behind the 512×512 input. It sits alongside the rest of the guides; this page stays with the tool itself: what each control does, what the pipeline computes, and how to read what it gives you.

Three tiers, three downloads — measured, not quoted

Every quality option is a different model, and every model has to reach your device before it can run. The picker shows what that costs because the page measures it: at build time it reads the byte size of each vendored file from disk, adds up the files that tier fetches on a current browser, and hands the totals to the tested tier catalog, which formats them as SI megabytes (one megabyte = one million bytes), the basis the tier catalog uses. A second, no-SIMD build of the MediaPipe runtime (10.8 MB, measured the same way) is vendored beside the standard one under the same /vendor/ path and is left out of the totals. Nothing in the tables below was typed in.

Tier	What runs	First-use download
Fast — people (auto)	Google’s MediaPipe selfie segmenter — a person-segmentation model	~11.7 MB on first use
Click the subject	Google’s MediaPipe MagicTouch interactive segmenter — cuts out the subject you click	~17.7 MB on first use
Best quality — any subject	BiRefNet_lite (512×512 export, 4-bit weights) on onnxruntime-web, in a worker thread	~86.9 MB on first use

The totals decompose into shared and private parts. The two MediaPipe tiers share one WASM runtime and differ only in their model file; the best tier brings its own runtime as well as a far larger model, which is where nearly all of its size comes from:

"On first use" means what it says: each engine is fetched lazily, the moment you pick that tier and press the button, and never before — opening the page costs nothing but the page. Every one of these files comes from this site's own /vendor/ path; there is no third-party CDN in the chain, and a provenance note with source URLs, versions, and checksums ships next to each. The methodology page notes that, for the best tier's model and runtime, a test suite pins every vendored byte size and the runtime version; for every tier, the labels above are measured from the files on disk at build time, so the labels and the files cannot silently drift apart.

What happens when you press "Remove background"

The button starts a fixed sequence, and knowing it explains most of what you will see.

1. Acceptance. The file is checked by a pure function before anything decodes it: the type must be PNG, JPG, or WebP, and the size must be above zero and at or under the cap. The exact rejection messages are tabulated below.
2. Decode and scale. The photo is decoded locally and, if its longest edge exceeds the tool's processing limit, scaled down for processing; the status line reports the size it was scaled to, and the original file is never modified.
3. Segmentation. The chosen model runs — MediaPipe in the page for the two fast tiers, BiRefNet_lite in a worker thread for the best tier — and produces not a cutout but a per-pixel confidence between 0 and 1 that the pixel belongs to the subject. In click-to-select mode the MagicTouch model is given the point you clicked in the Original preview.
4. Refinement. That confidence is cached and handed to the pure refinement pipeline, which turns it into an alpha matte in four steps: binarize at a threshold; drop foreground islands and fill enclosed holes smaller than a fraction of the largest foreground region; feather the boundary with a symmetric linear ramp; and snap the ramp toward brightness edges in the photo with a guided filter restricted to the boundary band.
5. Your strokes. Restore and Erase strokes live in a separate layer that is merged on top of the refined alpha — after refinement — so they survive when the Edge slider re-runs the previous step.
6. Composite. The download redraws the photo through the merged alpha on a canvas — transparent, or over the solid colour you picked — and encodes a PNG.

Why not use the confidence as alpha directly? Because a pixel the model is only half sure about would be left half transparent, and a photo full of such pixels comes out as a semi-transparent smear rather than a cutout. Binarizing first produces a decision; the feather and the guided snap then give that decision a natural edge. Every one of those steps is plain arithmetic on typed arrays — deterministic, tested, and re-run on the cached confidence without touching the model.

Worked example 1: the feather ramp

Take a strip of 12 pixels, one row high, whose left half the model scored at 0.9 confidence and right half at 0.1. Refining it with the engine's defaults — threshold 0.5, feather half-width 3 px, island fraction 0.005 (the tool's Edge slider moves both the threshold and the feather half-width, and its midpoint sits at a wider feather than this engine default; the arithmetic is identical) — produces this alpha, computed here at build time by refineMask itself:

Read it as a ramp centred on the boundary between pixels 5 and 6: 6 pixels — twice the half-width — are partially transparent, and every pair sitting k steps inside and k steps outside sums to exactly 255 (149 + 106, 191 + 64, 234 + 21). That symmetry is what "symmetric feather" means on this page, and the build asserts it: if the engine ever lost the property, this page would fail to build rather than describe a pipeline that no longer exists.

Worked example 2: specks and pinholes

The despeckle step is relative, not absolute: the cutoff is the island fraction times the area of the largest foreground region, so it scales with the subject. Here is a 32×32 mask holding a 24×24 block (576 pixels), a 2-pixel speck floating away from it, and a 1-pixel hole inside it, refined with a hard edge (feather 0) so the result can be counted. The hole counts as background when regions are measured, so the largest foreground region is 575 pixels:

Quantity	Value
Foreground pixels before refinement	577
Island cutoff (0.005 × 575)	2.875 pixels
Speck pixels dropped	2
Hole pixels filled	1
Foreground pixels after refinement	576

The consequence for real photos: anything connected to the subject — hair, a strap, a held object — is part of the largest region and is never touched by this step. Anything disconnected and smaller than the cutoff is treated as noise, so a small separate object you wanted kept is exactly what the Restore brush is for. Holes are filled only when they are fully enclosed; a gap that reaches the image border is background, and stays background.

Worked example 3: the guided edge snap

The last step re-estimates only the band pixels — those whose alpha is neither 0 nor 255 — from the photo's luminance in a small window; fully opaque and fully transparent pixels are returned untouched. Apply it to the strip above against two synthetic photos: one flat mid-grey everywhere, and one bright up to pixel 6 and dark from pixel 7 — a brightness edge one pixel to the right of where the model put the boundary.

With nothing to snap to, the flat photo simply smooths the ramp. With a real edge, each band pixel is re-estimated from the brightness in its window rather than from the ramp: 3 rise (pixel 4: 191 → 196, pixel 5: 149 → 180, pixel 6: 106 → 163), 2 fall (pixel 3: 234 → 210, pixel 7: 64 → 30), and 1 is unchanged (pixel 8: 21). The steepest step in the result now sits between pixels 6 and 7 — the photo's edge — instead of being spread evenly around the model's boundary. A bright-side pixel can still fall (pixel 3: 234 → 210): its whole window is bright, so there is no edge to follow and the filter can only average there, exactly as it does on the flat photo. That is the whole trick — no second model, just the photo correcting the mask where the mask is uncertain.

Reading the Edge slider and the brushes

The Edge slider moves two of the three refinement parameters together — the binarize threshold (how confident a pixel must be to count as subject) and the feather half-width (how soft the boundary is) — and leaves the island fraction at the engine default of 0.005. Dragging right raises the threshold and widens the feather; dragging left does the opposite. It never re-runs the model — only the arithmetic above, on the cached confidence. If a wisp of hair vanishes as you drag right, that is the threshold tightening, not the model changing its mind — drag back, or paint it in. The brushes are deliberately blunt: Restore brings pixels back and Erase removes them, at the brush size you set; Undo reverses the last brush action, and Clear strokes removes them all (Undo brings them back). Strokes are stored separately and merged after refinement, so no slider position can wipe them out.

What the tool accepts — and the exact rejection messages

Acceptance is decided by validateImageFile, a pure function with its own tests, before a single pixel is decoded. The rows below were produced by calling it at build time: the accepted rows pass through the same guard the other tool pages use for their worked examples, and the rejected rows report the engine's own message verbatim.

Two readings of the cap. The limit is 20,971,520 bytes — "20 MB" counted in binary megabytes — while the download labels above use the decimal (SI) convention of the tier catalog; on that basis the same cap reads 21.0 MB. Neither is wrong; they are different units with the same name, and the tool shows each where it belongs. The zero-byte case gets its own message because an empty file is usually a symptom — a download that did not finish, or a cloud-synced placeholder — and "not supported" would send you looking for the wrong fix.

The download: filename and colour

The saved file is named from your original: extension stripped, any run of characters that are not letters or digits collapsed to a single hyphen, the base capped at 60 characters, and -cutout.png appended. Letters and digits from any alphabet survive; if nothing survives, the base falls back to image.

For a solid background, the colour you pick is normalised to lowercase six-digit hex before it reaches the canvas — three-digit shorthand is expanded, a missing hash is added, surrounding whitespace is trimmed, and anything that is not hex is rejected so the code falls back explicitly rather than drawing garbage:

Input	Normalised
"#FFF"	#ffffff
"f0a"	#ff00aa
" #123456 "	#123456
"red"	rejected (not a hex colour)
"#12345"	rejected (not a hex colour)

The output is a PNG in both cases because PNG carries a real alpha channel and JPG cannot. The solid-colour option re-composites the cutout over that colour on a canvas in your browser, which is why it is still a PNG.

How to verify the "never uploaded" claim yourself

1. Open your browser's developer tools, switch to the Network panel, and clear it.
2. Load a photo. Decoding is local, so no request to any server appears.
3. Pick a tier and press Remove background. Now you will see requests — and every one of them is a file under this site's /vendor/ path: the WASM runtime and a .tflite model for the two fast tiers, the .onnx model and the onnxruntime WASM runtime for the best tier. The file names match the parts table above, or the no-SIMD runtime build noted with it.
4. Drag the Edge slider, paint with a brush, download. No further requests: the refinement is arithmetic in the page, and the PNG is built on a canvas and handed to you as a local object.

Two supporting facts from the methodology page. Running WebAssembly needed exactly one Content-Security-Policy addition — 'wasm-unsafe-eval' in script-src — and nothing that would permit an upload. And the best tier is deliberately confined to onnxruntime's WASM CPU provider inside a worker thread: the WebGPU provider was tested and produced silently wrong output for this model on the pinned runtime version, so it is deliberately not used (the provenance note in the repository records what that output was: an all-background mask). The 512×512 input is the same kind of measured decision — the 1024×1024 export needs roughly 6 GB of working memory at inference, beyond the ~4 GB WebAssembly heap any browser gives a page — and the mask is scaled back to your photo's processed dimensions before refinement.

Where this tool is honestly weaker

Fast mode runs a person segmentation model. It performs best on photos of people — faces, head-and-shoulders shots, full figures — which is the thumbnail and promo use case this site exists for, and it remains people-tuned. For a sneaker, a dog, or any other subject, switch to “Click the subject”: it runs Google's interactive MagicTouch segmentation model, which cuts out whatever you point at — any subject, still entirely in your browser. The two fast modes are weaker on fine details like stray hair than heavyweight server-side services, which run much larger models on much larger hardware; that is the honest trade-off of keeping everything on your device — not a defect this page will pretend away. The refinement pipeline (a hard-edged cut with symmetric feathering, plus restore/erase brushes) is built to give a usable cutout without further work; whether it does for your photo is something you can see for yourself, for free.

“Best quality — any subject” narrows that gap by running a genuinely larger model on your device: BiRefNet_lite, a dichotomous image segmentation model designed for exactly this kind of subject/background cutout. The trade-off is stated right in the picker, from the real file sizes measured at build time: the tier is a ~86.9 MB on first use download (versus ~11.7 MB on first use for fast mode and ~17.7 MB on first use for click-to-select), and the analysis takes longer — real computation, run in a background thread so the page never freezes while it works. One more honest number: the model analyzes the photo at 512×512 — the browser-sized build of BiRefNet_lite, chosen because the full-resolution version needs more memory than any browser gives a web page (the exact measurements are pinned in the repository) — and the mask is then scaled back up to the dimensions it was processed at and refined there. What does not change is the boundary that matters: it is still 100% local, the photo still never leaves your browser, and no tier of this tool ever will upload it. Larger is not magic — even the best tier can miss wisps of hair — so the same Edge slider and brushes apply to its result too.

Fast mode is the same engine that powers the cutout inside the Thumbnail Maker (the other two modes are extras of this page) — use the maker when you want to place the cutout over gradients, outlined text, and shapes on a real thumbnail canvas.

Frequently asked questions

Use photos you have rights to. The file-acceptance rules, filename handling, and the download-size labels are pure, tested code, and every segmentation engine's model version, hash, and license are pinned in the repository and documented on the methodology page.