Is It Safe to Paste Production Data Into Online Tools?
Pasting a production JWT, an API response or a .env file into an online tool is a data disclosure, and whether it matters depends on whether that tool sends what you pasted to a server. Most developers have done it. Most have never checked.
This is not a theoretical concern. In March 2026 a widely used JSON Formatter Chrome extension was found to be serving adware — a tool people had trusted with pasted data for years. The incident was significant enough that a GitHub list of provably local developer tools was created in response to it.
What are you actually disclosing?
More than the payload, usually. The things developers paste into formatters and decoders are rarely inert:
- JWTs contain the subject, issuer, scopes and expiry — and if the token has not expired, it is a working credential.
- API responses routinely contain customer names, email addresses, internal IDs and pricing.
.envfiles and config contain database URLs, secrets and API keys, complete and ready to use.- Stack traces expose file paths, framework versions and internal hostnames.
- SQL exposes schema, table names and sometimes literal values from production.
A pasted JWT is not a description of a credential. It is the credential.
What happens to data you paste into an online tool?
Either it is processed in your browser and goes nowhere, or it is sent to a server and processed there. There is no third option, and the difference is invisible from the interface.
If it goes to a server, it may be written to request logs, captured by an APM trace, cached by a CDN, retained in backups, or read by analytics. None of that requires bad intent — it is what ordinary infrastructure does with ordinary requests. A stated retention policy is a promise you cannot audit.
There is also a third-party dimension. A tool page loaded with several analytics and advertising scripts has given those scripts the ability to read the page — including, potentially, what you typed into it.
How do I check before I paste?
Open developer tools, go to the Network tab, filter to Fetch/XHR, then paste and run the tool. If your data appears in an outgoing request, it left. If no request fires, it did not.
Two refinements worth knowing:
- Load the page, then disconnect. A client-side tool keeps working offline; a server-side one fails immediately. This is the fastest test and needs no DevTools at all.
- Check the site's Content-Security-Policy with
curl -I https://example.com/ | grep -i content-security-policy. Theconnect-srcdirective lists every destination the browser will permit. If the list is short and specific, exfiltration is constrained by the browser rather than by policy. Most sites do not publish one at all.
Filevane's privacy proof page shows the site's own header and names all six permitted destinations, none of which accepts pasted content.
Which tools should I be most careful with?
Rank by what the input is worth, not by how the tool looks.
| Input | Risk | Why |
|---|---|---|
.env / config file |
Highest | Live secrets, immediately usable |
| Unexpired JWT | Highest | A working credential, not a description of one |
| API response with customer data | High | Personal data, possible regulatory exposure |
| Private key, certificate | Highest | Never paste these anywhere, ever |
| SQL with literals | Medium-high | Schema plus real values |
| Stack trace | Medium | Internal paths and versions |
| Public API sample | Low | Already public |
| Your own scratch JSON | Low | Nothing at stake |
Decoding a JWT is the case most worth changing your habits over. It is a routine debugging action, it feels harmless because you are only reading it, and the thing you pasted is a live authentication token.
Filevane's JWT Decoder runs entirely in the browser for exactly this reason. Note also what decoding does not do: it reads the header and payload, which are base64url text, not encryption. A JWT must never carry a secret, because anyone holding the token can read its contents regardless of tooling.
Is a browser extension safer than a website?
Usually the opposite. An extension with permission to read page content has far broader access than a single web page, it updates automatically without you reviewing the change, and extensions are bought and sold — a well-reviewed tool can change hands and change behaviour in one silent update.
That is precisely the shape of the March 2026 JSON Formatter incident: not a tool that was always malicious, but one that became so after people had already learned to trust it.
If you use extensions for this, review their permissions periodically and prefer ones that are open source and actively maintained.
What should I do at work?
A short policy that avoids most of the problem:
- Redact before pasting. Replace real values with placeholders. Structure is almost always what you need to inspect, not content.
- Use offline tooling for secrets.
jq, your editor's formatter, or a local script. Never an online tool for a private key. - Prefer client-side tools and verify the claim once, then reuse that tool.
- Treat an unexpired token as a credential. If you paste one somewhere you are unsure about, rotate it.
- Check whether your organisation already has a policy. Many do, and pasting customer data into a third-party site may breach it regardless of the tool's behaviour.
Does this mean online tools are bad?
No — it means the question is which one, not whether. Client-side tools are genuinely private, frequently faster than a server round trip, and keep working offline. The problem is not the medium; it is that most tools do not tell you which kind they are, and the interface looks identical either way.
The reasonable position is to check once and then use the tool freely. Thirty seconds in the Network tab settles it permanently.
Format and decode locally
JSON Formatter · JWT Decoder · HMAC Generator · BCrypt Generator
All run entirely in your browser. Nothing you paste is transmitted, the tools keep working with your connection switched off, and the Content-Security-Policy that enforces it is published so you can verify the claim rather than trust it.
Tools used in this guide
Frequently asked questions
Is it safe to paste production data into an online JSON formatter?
Only if the formatter processes the data in your browser. If it sends the payload to a server, that data can be written to request logs, captured by monitoring, cached, or retained in backups — none of which you can audit, and none of which requires bad intent on the operator's part. Check by opening developer tools, filtering the Network tab to Fetch/XHR, and watching whether your input appears in an outgoing request.
How do I check whether a tool sends my data to a server?
The quickest test needs no developer tools at all: load the page, disconnect from the internet, then use the tool. A client-side tool keeps working; a server-side one fails immediately. For a more precise check, open the Network tab, filter to Fetch/XHR and look for your input in an outgoing request. You can also inspect the site's Content-Security-Policy header, whose connect-src directive lists every destination the browser will permit.
Is decoding a JWT in an online tool risky?
It is the case most worth changing your habits over. Decoding feels harmless because you are only reading the token, but an unexpired JWT is a working credential rather than a description of one — anyone who obtains it can use it until it expires. Use a decoder that runs in the browser, and if you have pasted a live token somewhere you are unsure about, rotate it.
Is a browser extension safer than a website for developer tools?
Usually the opposite. An extension with permission to read page content has much broader access than a single web page, it updates automatically without review, and extensions change ownership. In March 2026 a widely used JSON Formatter Chrome extension was found serving adware, having been trusted with pasted data for years. Prefer open-source extensions, and review permissions periodically.
What data should never be pasted into an online tool?
Private keys and certificates, under any circumstances. Beyond those, treat env files and unexpired tokens as the highest risk because they are immediately usable, and API responses containing customer data as high risk because of the personal information involved. Public API samples and your own scratch JSON carry essentially no risk.
What is the safest practice at work?
Redact before pasting — structure is usually what you need to inspect, not real values. Use local tooling such as jq or your editor for anything containing secrets. Prefer client-side tools, verify the claim once, then reuse that tool. Treat any unexpired token you have pasted somewhere uncertain as compromised and rotate it. Check your organisation's policy too, since pasting customer data into a third-party site may breach it regardless of the tool's behaviour.
Does encryption in transit protect what I paste?
Only from parties between you and the server. HTTPS prevents interception, but it does nothing about the server itself, which is the party receiving and processing your data. If a tool sends your payload to a server, transport encryption means the disclosure is private to that operator rather than public — which is better, but is not the same as the data never leaving your device.