Ask any backend engineer what they do when a 4 KB JSON blob comes back malformed from a production API. Most of them, honestly, will paste it into the first "JSON formatter online" that Google returns. It is a two-second habit built up over a decade, done ten times a day, and almost never mentioned in an architecture review. It is also, quietly, one of the most common ways sensitive data leaves your network.
This post is written for CISOs, DPOs, IT managers, and anyone else who has ever asked "what data actually goes to that site?" and not gotten a clean answer. The short version: on most free online formatters, everything the engineer pastes is uploaded to a third-party server, may be logged, may be cached, and is completely outside your data-processing agreements. There is a fix, and it is not a policy document nobody reads.
What actually happens when someone pastes JSON into a random site
Open the network tab on almost any "format my JSON" tool built before 2020. Paste a payload. You will usually see one of two things: an XHR POST to /api/format with the entire body in the request, or a WebSocket frame sent to a formatting backend. Either way, the payload leaves the browser. Whatever was in it — customer emails, internal user IDs, API tokens in an Authorization header your engineer forgot to strip, a Stripe charge ID, a JWT that is still valid for 20 more minutes — is now on a server owned by a stranger.
That stranger may be well-intentioned. Many of them are. But "well-intentioned" is not a compensating control. The site has no DPA with you, no defined retention window, no incident-response commitment, and no obligation to tell you if their database gets dumped on a forum. From a compliance standpoint, every paste is an unauthorized cross-border data transfer.
Why the policy approach doesn't work
The traditional response is to write a policy: "employees must not paste production data into third-party tools." Everyone signs it during onboarding. Nobody reads it during a Sev-2 incident at 2 a.m. when the payload from the payments provider is malformed and the customer is on the phone.
Blocking those domains at the proxy is worse — it teaches engineers to use their phone hotspot instead, which removes the paste from your logs entirely and gives you no visibility at all. The only workable answer is to give people something equally fast that doesn't leave the network. If the sanctioned tool is one bookmark away and works in three seconds, engineers will use it, because the alternative is nothing personal — it is just muscle memory looking for the lowest-friction option.
What "runs in the browser" actually means for your DLP posture
A browser-only tool loads JavaScript once and then does the work locally. When your engineer pastes JSON, the formatting, validation, and diffing all happen inside the tab's sandbox. Nothing is uploaded, because there is no server endpoint to upload to.
You can verify this in about ninety seconds. Open the tool, open the browser's network tab, paste a large payload, and watch. If no request goes out during the paste or the format action, you are looking at a real client-side tool. If a request goes out with your payload in the body, it is not. This is the single test every IT-vetted tool should pass, and it is testable by anyone with a browser — no vendor call required.
For your DLP stack, a real client-side tool has a very tidy property: the outbound network profile is a static list of the domains the page loads assets from (usually just the tool's own domain and a CDN for fonts). You can allow-list those in your egress rules and get exactly zero data-exfil surface from the tool itself. Compare to a cloud formatter, where the exfil surface is "whatever the vendor's backend does next," which you cannot audit.
A three-question vendor test for any utility site
1. During normal use (paste, format, download), does the network tab show a request whose body contains user data? If yes, it is not client-side. Full stop.
2. Does the page load third-party scripts from analytics, ads, or session-replay vendors? Session-replay tools in particular (Hotjar, FullStory, LogRocket) record everything typed on the page — including whatever your engineer just pasted. A truly private tool ships with none of these.
3. Is there a Content-Security-Policy header restricting where the page can send data? A tool that ships a strict CSP is telling you, cryptographically, that even if it wanted to exfiltrate your paste it can't. This is the strongest signal a security team can get from a free tool.
What to hand your team
Rather than a policy, hand engineers a single-page internal bookmark: "For JSON, CSV, base64, hashing, PDFs, images — use these tools. They run in the browser. No paste leaves your machine." Pick tools that pass the three-question test above. Bluebird is one option, built exactly for this: 300+ utilities, all client-side, no telemetry, strict CSP, no auth required. There are others; the point is not the vendor, it is the property.
Pair the bookmark with a fifteen-minute lunch-and-learn showing the network-tab test on both a good tool and a bad tool. Engineers respect proof. Once they've seen a payload actually leave the browser on the bad tool, they don't need a policy to stop using it.
If you want the paperwork trail: an IT-admin allow-listing document (domains, CSP, no analytics, no telemetry) is usually enough for a DPO to sign off. If you need help drafting one for a client-side tool, our /it-admin page has a template you can adapt.
The uncomfortable truth
Most "we had a data leak" incidents in mid-sized companies are not a hacker in a hoodie. They are an engineer pasting a payload into a random site under time pressure, three years ago, and the site's database eventually leaking. You will never find that in an audit log, because you don't have one. The fix is not more training. The fix is making the safe option the fast option.
