Skip to content
jsonbeautifiers
English

Do not trust us. Check.

Every JSON tool says your data is safe. In November 2025 two of the largest ones leaked more than 80,000 saved pastes. This page is how you find out whether a claim like ours means anything.

The 30-second check

  1. Open your browser's developer tools and go to the Network tab

    F12 on Windows and Linux, or Option-Command-I on a Mac. Tick "Preserve log" so nothing disappears on navigation.

  2. Reload this page, then clear the log

    You will see the page itself, one stylesheet, two font files and, on a tool page, the editor and worker scripts, every one of them served from this domain. You will also see the Google Analytics tag, which is the only third-party request on this site and the only one worth a second look.

  3. Now go to a tool and paste something. Anything. Ten megabytes of it

    Format it, convert it, break it and validate it, and watch the Network tab. The only requests are the analytics pings, and you can open any of them: they carry the page URL, your screen size and a visitor id. Ten megabytes of JSON does not fit in one, and it is not in one. Nothing else is sent, while you type, when you click, or when you leave.

The part that makes it a guarantee

Watching the Network tab tells you what happened this time. The header below tells you what is possible at all. Look at the response headers for any page on this site, in the same Network tab, and you will find it.

Content-Security-Policy
default-src 'self';
connect-src https://*.google-analytics.com https://*.analytics.google.com https://*.googletagmanager.com;
script-src 'self' https://www.googletagmanager.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https://*.google-analytics.com https://*.googletagmanager.com;
font-src 'self';
form-action 'none';
frame-ancestors 'none';
base-uri 'self';
object-src 'none';
worker-src 'self' blob:

The line that matters is connect-src. It is an allowlist, and it names the analytics endpoint and nothing else. Every other outbound request this page could attempt is refused: no fetch, no XMLHttpRequest, no WebSocket, no EventSource, no sendBeacon to anywhere your document could land.

That is not a statement about our intentions. It is a rule the browser enforces on any code running on this page, including code we might add by mistake tomorrow, including a compromised dependency, and including the analytics script itself, which can reach Google and nothing else. If something on this site ever tried to send your payload somewhere, the browser would block it and log a violation in your console.

You can prove it to yourself. Open the console on any page here and run fetch('https://example.com'). It will be refused, and the browser will tell you why.

What we gave up to be able to say this

A header this narrow has costs, and it is worth being explicit about them, because they are the reason most sites do not ship one. It has exactly one exception, and that is the first entry below.

One exception: analytics
Google Analytics counts page views, and it is the single host the allowlist permits. It sees the page you are on, where you came from, your language, your screen size and a visitor id. It does not see the editor, and the same header that lets it talk to Google is what stops it, or anything else here, talking to anywhere else.
No advertising
An ad tag is a third-party script that makes network requests and reads the page. It is incompatible with everything on this page, and adding one later would forfeit the claim permanently rather than partially.
No file upload and no load-from-URL
Files are read with the browser's FileReader, which never sends anything. Loading a document from a remote URL is not offered at all, because browsers block cross-origin fetches and the only way to make it work is to proxy the request through a server. That server is precisely what we are arguing against.
No accounts, no saved links, no sharing service
A "save this snippet" feature is a database of other people's payloads. That is exactly the feature that leaked 80,000 pastes in November 2025, and the exposed data included Active Directory credentials, cloud access keys and banking records.
No fonts or styles from a CDN
Every font, stylesheet and script other than the analytics tag is served from this domain. A font request to a third party is still a request to a third party, and it carries your IP address and the page you are on.
Nothing is logged to the console
Not your input, not your output, not "helpfully" inside an error handler. The build fails if a log statement gets near user content.

What this does not protect you from

Being straight about the limits is part of the claim being worth anything.

  • A browser extension with permission to read page content can read this page, like any other. No website can prevent that.
  • Anyone with access to your machine can see what is on your screen and in your localStorage.
  • Our hosting provider can see that your browser requested a page, along with your IP address, because that is what serving a page is. They cannot see what you paste, because it is never sent.
  • If you copy the output and paste it somewhere else, that is between you and wherever you paste it.

Questions

Why should I believe any of this?
You should not. That is why this page exists. Every claim on it is something you can check yourself in under a minute, using tools already in your browser. A promise on a privacy policy is worth nothing; a Content-Security-Policy header is enforced by the browser regardless of what our code tries to do.
What about a browser extension reading my data?
An extension with permission to read page content can read anything on any page, including this one. No website can prevent that, and any site claiming otherwise is wrong. What we can do is make sure the page itself has nowhere to send your document, and that is what the connect-src allowlist does.
Does anything get stored?
Your current draft and your tool settings are kept in localStorage, on your own device, so a refresh does not lose your work. Drafts over 512 KB are not stored at all. Clearing site data removes everything, and nothing is ever transmitted.
Why is there no "load from URL" feature?
Because it cannot be built honestly. Browsers block cross-origin fetches, so the only way to offer it is to run the request through a server, which means the URL and its response pass through us. Every site that offers this feature has that server. Declining to build it is the point.
What does the analytics see?
Google Analytics 4 records the page you are on, where you arrived from, your language, your screen size, a coarse location from your IP address and a visitor id kept in a cookie. It does not record what you paste, and it could not: the document lives in the editor and in the worker that formats it, and the analytics script can reach neither. Blocking cookies for this domain, or any content blocker, switches it off entirely and every tool keeps working.

Go and try it

Open the Network tab first, then paste something large enough that you would notice it being uploaded.

Open the beautifier