Most developers have done this at least once.
You get a messy API response.
You need to inspect a JWT.
You have a webhook payload, a log object, or a config file that is hard to read.
So you open a JSON formatter, paste the content, and move on.
That habit is convenient. But it also deserves a second look.
Not every JSON tool behaves the same way. Some tools process your input entirely in the browser. Some send content to a server. Some store snippets for sharing. Some extensions have permissions that are broader than you expect.
The problem is not that every online formatter is unsafe.
The problem is that you often do not know what happens after you paste.
What you should avoid pasting blindly
Before using any random online tool, be careful with:
production JWTs
API responses containing user data
logs from real systems
config files
webhook payloads
database URLs
cloud keys
internal endpoints
tenant IDs
error traces from production systems
A JSON payload does not need to contain an obvious password to be sensitive.
Sometimes the risky part is context: user IDs, internal URLs, tokens, customer data, or system structure.
A quick DevTools check
You can do a basic check with your browser’s DevTools.
Open the JSON tool.
Open DevTools.
Go to the Network tab.
Clear existing requests.
Paste a harmless test JSON first.
Run format, validate, diff, decode, or whatever action the tool provides.
Watch the Network tab.
Look for POST, PUT, fetch, XHR, or beacon requests after your input.
Inspect request payloads if they exist.
Check whether your pasted JSON appears in any request.
Do this with harmless test data first.
If the tool uploads the test JSON, do not paste production content into it.
What to look for
A few signs deserve attention:
POST requests after you paste or click format
request bodies containing your JSON
share-link features that save snippets
server-side validation APIs
analytics events that include pasted content
extension background requests that are not clearly explained
Analytics by itself is not the same thing as pasted-content upload.
A tool can have normal page analytics and still avoid sending your JSON payload.
The important question is narrower:
Is my pasted content included in a network request?
That is what you are trying to verify.
Browser extensions need the same scrutiny
Extensions can be useful, but they deserve the same level of inspection.
A JSON formatter extension may need content scripts or host access to detect JSON pages and format them. That does not automatically mean it is malicious.
But the extension should explain:
why each permission exists
whether it loads remote code
whether it injects ads or affiliate scripts
whether it uploads JSON content
where the source code can be audited
If an extension handles developer data, its permission model should not be vague.
How SafeJSON approaches this
I built SafeJSON around one idea:
Do not ask developers to trust a privacy claim. Give them a way to verify it.
SafeJSON’s core tools process pasted JSON locally in the browser and do not upload pasted content for core operations.
That includes common workflows like formatting, validating, viewing, parsing, JSON Diff, JWT decoding, JSONPath queries, and schema validation.
The important part is not just the claim.
The important part is that you can check it yourself.
Open DevTools → Network, paste JSON, run the tool, and inspect whether pasted content is uploaded.
I wrote a full step-by-step guide here:
https://www.safejson.dev/security/check-json-formatter-upload
There is also a dedicated verification page:
https://www.safejson.dev/privacy/verify-local-processing
And for the browser extension permissions:
https://www.safejson.dev/extension/permissions
Final thought
The goal is not to stop using web tools.
The goal is to stop pasting sensitive developer data into tools whose behavior you have never checked.
A quick Network tab check takes less than a minute.
For production JSON, JWTs, logs, configs, and API payloads, that minute is worth it.
Top comments (0)