I found the exact pixel brightness where our background remover gives up
Our Remove White Background tool page says it turns a pixel transparent "whenever red, green and blue are all above 230." I read that line about four times and had the same thought every engineer has about a threshold written in someone else's prose: is that really true down to the integer, or is "above 230" more of a vibe than a rule?
So I made a test file instead of trusting the sentence.
Building a gradient that cannot lie
I opened a blank tab, drew an 8-step gray strip on a canvas, and set each block to a flat RGB value: 220, 225, 229, 230, 231, 235, 245, 255. Every channel equal, so it is pure gray, no color to confuse the colour key. Then I exported it as a 1.5 KB PNG and fed it straight into Remove White Background.
[[IMG:1]]
▲ The result preview, straight from the tool. Four blocks still gray, four blocks turned into the checkerboard pattern the tool uses for transparency. The red line is where I later confirmed the exact cutoff sits.
Reading the pixels back
A screenshot only tells you roughly where the line is. To get the actual number I downloaded the PNG the tool produced and read it back with a canvas getImageData call, one pixel per block:
- 220 → alpha 255 (fully opaque)
- 225 → alpha 255
- 229 → alpha 255
- 230 → alpha 255 (still opaque)
- 231 → alpha 0 (fully transparent)
- 235 → alpha 0
- 245 → alpha 0
- 255 → alpha 0
So "above 230" is not marketing rounding. It is a literal r > 230 && g > 230 && b > 230 style check, and the boundary sits precisely between 230 and 231. I did not expect a one-paragraph help text to be that exact, and honestly I half expected to find the real cutoff was 235 or 240 with the docs just rounding down for readability. It wasn't. It was right.
Why this matters if you actually use the tool
Once you know the number is literal, a few practical things follow:
- A product photo shot on an off-white backdrop (RGB around 235-245, which looks "white" to your eyes) will lose its background cleanly. A backdrop that reads closer to 220-229, like a slightly gray wall or a scan with a dim light source, will not budge at all, and you will see the original background still sitting there.
- White shirts, paper highlights and overexposed skin can cross 230 too, which is exactly the "light parts of the subject can become transparent" warning on the tool page. Now you know it is not a vague caveat, it is the same literal threshold working against you instead of for you.
- If your background is close but not quite making the cut, the fix isn't a different tool setting (there isn't one), it's lighting the original shot brighter or pre-processing contrast before you upload.
Checking the "no upload" claim at the same time
While I had the dev tools open for the pixel readback, I also had Playwright's request listener running from the moment the page loaded to after I downloaded the result. Total network requests fired by the page: zero. No POST with the file, no background fetch after processing. The tool's own page explains why: it's served with a Content-Security-Policy: connect-src 'none' header, which tells the browser to refuse any script-initiated network call from that page, image upload or otherwise. You can check this yourself with curl:
curl -sI https://toolsthatdontupload.com/tools/remove-background/ | grep -i content-security-policy
That's the mechanism, not just a promise in the copy.
What I'd actually change
This is a flat colour key, not a trained cutout model, and the tool page says so upfront. It is good at logos, scans and product shots on a genuinely white studio background. It is the wrong tool if your background is a room, a sky, or anything with texture, since there is no edge detection, just a brightness check per pixel. If you need that, a photo background is a different, much harder problem than this tool is trying to solve, and I'd rather it stay honest about that than fake intelligence it doesn't have.
Try it yourself: Remove White Background, no signup, the file never leaves your browser. If you want to verify any of our other tools the same way, the full list is here, and the method from this post (open dev tools, watch Network, check the CSP header) works on all of them.