This is one of the most-asked questions in the JSON-tooling corner of the internet right now, and the answer is more nuanced than a yes or no. So let's break it down: what JSONFormatter.org actually is, what the November 2025 disclosure changed, whether it has been fixed, and — most importantly — when you should still avoid it.

The very short version

If you do not have time to read the rest:

• For non-sensitive JSON (a sample payload you do not care about, learning, demos): JSONFormatter.org works fine and the surface-level risk is low.
• For anything with credentials, config files, customer data, or internal API responses: do not paste it there. Use a client-side tool that has no server to leak from. (More on alternatives here.)
• Whatever you do, never use the "Save / share link" feature on any sensitive content, on any tool.

What JSONFormatter.org actually is

JSONFormatter.org is one of the most-trafficked programming-tool websites on the internet — third-party estimates (Semrush) put it at around 2.5 million visits per month. It has been around since the early 2010s, dominates the search term "json formatter," and offers formatting, validation, and conversion to/from XML, CSV, YAML, and a few other formats.

Crucially, it (and its sibling site CodeBeautify.org) ships a "Save" feature that generates a shareable URL for whatever you have pasted. That feature is the entire reason this article exists.

What happened in November 2025

On November 25, 2025, security research firm watchTowr Labs published findings showing that JSONFormatter.org and CodeBeautify.org had been exposing user-pasted data through their "Recent Links" feature. The pages were on publicly enumerable URLs and had been for years.

watchTowr reported capturing over 80,000 files (about 5 GB), and the contents were exactly what you would fear:

• AWS access keys and secrets, including credentials for AWS Secrets Manager.
• SSH private keys.
• Database connection strings with embedded passwords.
• API tokens for SaaS services.
• Production configuration files.
• Internal API responses, sometimes with PII.

The story was picked up by The Hacker News, BleepingComputer, SecurityWeek and others. Read the full technical write-up in our breach breakdown.

Was it a "hack"?

This is the part that confuses people. No, it was not a breach in the sense of an attacker exploiting a vulnerability. The leak was the design. The "Save" feature was built to send your input to a server and store it under a URL. Those URLs were public. The only thing researchers did was enumerate URLs that the sites themselves were publishing.

That distinction matters because it changes what "fixed" even means.

Is it fixed now?

After the disclosure, the affected sites reportedly started removing or restricting the public-facing "Recent Links" feature. That is a reasonable mitigation for the specific data-exposure vector that watchTowr found. It does not change the underlying architecture: the tool still sends your data to a server whenever you use the Save / share feature, and any future misconfiguration on that server could re-expose it.

The honest assessment: for the specific incident reported, yes, the most obvious leak vector appears to have been closed. For the general class of risk — "your data leaves your machine and is stored on a third-party server" — the architecture has not changed.

So… is it safe?

Here is a decision rule that holds up regardless of what the sites do next:

1. If the JSON you are about to paste is something you would happily post on a public forum, using JSONFormatter.org is fine. The risk surface is small and the convenience is real.
2. If the JSON contains anything you would not post publicly — credentials, internal API responses, customer data, internal hostnames, anything under NDA — do not paste it there. The tool has a server-side code path that has demonstrably leaked data in the past.
3. If you are not sure which bucket you are in, default to option 2. The cost of being wrong in the cautious direction is inconvenience. The cost of being wrong in the other direction is a credential rotation and possibly an incident.

How to check any JSON tool, in 30 seconds

You do not have to take our word for any of this. You can verify a tool's behavior directly:

1. Open your browser's DevTools (F12 on most browsers) and switch to the Network tab.
2. Paste a unique, recognizable string into the tool — for example {"TESTMARKER_abc123": true}.
3. Trigger the main action (Format, Validate, Save, whatever the tool does).
4. Watch the Network panel. If you see a request whose body or URL contains your marker, the tool is sending your data to a server. If you see no such request, processing is local.

On a fully client-side tool, the Network panel will show only the initial page load and static asset fetches — no requests carrying your input. This is exactly what you should see on our security page, and the test we encourage every visitor to run before pasting anything sensitive.

What to do if you have already pasted sensitive data

If you have used JSONFormatter.org (or CodeBeautify.org) to format anything containing credentials — especially before November 2025 — assume it was exposed and rotate it. Practical steps:

1. Rotate the credential. New API key, new database password, new SSH key. This is by far the most important step.
2. Audit logs on the affected account for unexpected access in the period since you pasted it.
3. Switch to a client-side tool for any future sensitive formatting.

The takeaway

"Is JSONFormatter.org safe?" is the wrong question. The right question is "is this specific paste something I am willing to risk being public?" If yes, the site is convenient and the risk is acceptable. If no — and most production JSON falls into this bucket — use a tool whose architecture makes the leak class impossible.

If you want that tool to be this one, the editor is open and waiting. No signup, no upload, no share-link feature to misconfigure — and here is how to verify it.