"It all runs in the browser" has become the security-marketing phrase of the decade. Every vendor says it. Almost none of them explain what it means. This post is a working IT-admin's field guide: what the claim can mean, what it usually means, how to verify it in under two minutes, and what to put in your allow-list and CSP once you have.
The three flavours of "runs in the browser"
Flavour one, the real one: all processing happens in the user's browser tab using JavaScript, WebAssembly, or WebGL. The user's file is read into memory, transformed, and written back — the bytes of the file never leave the machine. Network requests during the operation are limited to loading the tool's own code and static assets. This is what a properly built client-side tool looks like.
Flavour two, the mostly-in-the-browser one: the tool renders in the browser and does small work locally, but calls out to a server for the actual heavy operation. "AI background remover" is the archetype — the UI is client-side, but the image is uploaded to a GPU server. This is not client-side; it is a normal SaaS with nicer chrome.
Flavour three, the misleading one: the tool uploads the file to a server, processes it there, and downloads the result, but marketing calls this "in-browser" because the user never leaves the browser tab. This is either lazy copywriting or deliberate obfuscation. Either way, treat it as a full server-side data processor and require the paperwork.
The two-minute verification test
Open the tool in Chrome or Firefox. Open DevTools (F12), go to the Network tab, and clear it. Load a small test file — a 10 KB image or a two-page PDF is ideal. Click the tool's main action button. Then look at the network activity.
If the only requests you see are for JavaScript, CSS, fonts, and small analytics pings, the tool is genuinely client-side. If you see a request with a payload similar in size to your test file — anything from "multipart/form-data" to a large POST body — the file has been uploaded, regardless of what the marketing page says. This test is definitive and takes ninety seconds.
A more advanced version: turn on the DevTools "Preserve log" checkbox and set the network filter to "Fetch/XHR". Now every server call is visible, and you can compare against the vendor's claimed data flow. If the vendor says "we never store your file" but there is clearly a POST to /upload during your test, you have a factual disagreement to raise before signing anything.
What to put in your allow-list
A genuinely client-side tool has a tidy network profile: the tool's own domain, a CDN or two for fonts and libraries, and optionally a lightweight analytics domain. That's it. You can allow-list those four to six domains in your egress proxy and be done. No sub-processor list, no evolving vendor infrastructure, no surprises during an audit.
For a vendor that publishes an "IT admin" page — Bluebird's is at /it-admin — you should be able to copy-paste the domain list directly into your allow-list rules. If the vendor cannot give you a stable list of domains their page loads from, that itself is a red flag: it usually means they load third-party ad or analytics scripts that change monthly.
What a strict Content-Security-Policy tells you
A Content-Security-Policy header on the tool's response tells the browser which domains the page is allowed to send data to. A strict CSP (e.g. connect-src 'self' https://fonts.googleapis.com) is a cryptographic guarantee that even if the JavaScript wanted to exfiltrate your data, the browser will refuse to send it. It is the strongest technical assurance you can get from a free tool without doing a code audit.
When evaluating a vendor, curl the tool's URL and check the Content-Security-Policy response header. If it's absent, the tool has no self-imposed restriction on where it can send data — you are trusting the developer's discipline, not the browser's enforcement. If it's present and narrow, you have a defensible answer for your auditor.
Why this matters beyond paperwork
The reason to care about all of this is not because auditors demand it — it's because "runs in the browser" tools are the only ones that scale gracefully as your headcount grows. A cloud tool costs per user per month, requires per-user provisioning, needs SSO integration, and adds a new vendor to your annual review cycle. A browser-only tool costs zero to allow-list once, works for every employee immediately, has no login to manage, and has no annual review because there is no ongoing data-processing relationship to review. It is genuinely the simpler answer, once you learn to spot the real ones.
And that recognition — real vs mostly vs fake — takes about a week of testing to build up. After that, it becomes an obvious sniff-test you can teach to anyone on your team in an afternoon.
