← All articles
Updated May 29, 20267 min read

Why You Shouldn't Paste Sensitive JSON Into Online Tools

JWT tokens, API keys, PII, and database exports are routinely pasted into online formatters. Here's what happens to that data on the server side — and why browser-native tools are the safer choice.

A developer hits a parse error, copies the JSON from the API response, and pastes it into the first online formatter that comes up in Google. The JSON contains user IDs, email addresses, session tokens, or an internal config file. This happens dozens of times a day across every engineering team. This article explains exactly what risks that creates — and why a browser-native tool eliminates them.

What Kind of Data Ends Up in Online JSON Tools

In practice, developers paste whatever is causing the immediate problem. That means:

  • JWT tokens — contain user identity claims, roles, and expiry. The signature prevents tampering, but the payload is Base64url-encoded plaintext: anyone who logs your token can read every field in it.
  • API responses with PII — names, email addresses, phone numbers, dates of birth, addresses. A single page of search results from a customer-facing API can contain hundreds of records.
  • Configuration files — database connection strings, third-party API keys, feature flag settings, internal service URLs.
  • Database exports — JSON dumps of entire tables, sometimes generated for debugging and pasted as-is.
  • Internal business data — pricing rules, contract terms, unreleased product data that has no public classification but is still sensitive.

None of these feel sensitive in the moment. The developer wants to understand the structure, not share data. But the act of pasting it into an online tool is indistinguishable from sending it to a third party.

What Happens When You Submit Data to an Online Tool

Most online formatters, validators, and diff tools work by sending your input to a server endpoint, processing it there, and returning the result. Even tools that claim to be "client-side" sometimes send data for logging, analytics, or error tracking. Here is what can happen to data along that path.

Server-side logging

Web servers log request bodies by default in many frameworks. A single POST of your JSON payload may end up in:

  • Application logs stored on disk or in a logging service (Datadog, Splunk, CloudWatch)
  • Error tracking tools (Sentry, Bugsnag) — especially if the parse fails
  • A database row in an "analytics" or "usage" table
  • CDN or load-balancer access logs that the tool operator may not even monitor

Log retention policies vary widely. Some tools keep logs for 90 days; others keep them indefinitely. In either case, the operator — and anyone who gains access to their systems — can read what you submitted.

Third-party analytics

Many online tools include third-party JavaScript for analytics or advertising. These scripts can observe network requests, form submissions, and input events. If a tool sends your data to its own server, the analytics layer can also see the HTTP transaction.

Caching and CDN storage

Some tools cache results keyed to the input content. If two users submit identical JSON, the second gets a cached response. The input may remain in the cache for hours or days. In pathological cases, incorrectly configured caches have made user submissions publicly accessible via a predictable URL.

Search engine indexing

Formatters that generate a shareable permalink (a URL containing or referencing your formatted JSON) have historically had their output crawled by search engines. Searching for a distinctive string from an internal config file and finding it on a JSON formatter's domain is an uncomfortable experience.

Regulatory Exposure

If your organisation processes personal data under GDPR, HIPAA, CCPA, or similar frameworks, pasting a user's data into a third-party online tool may constitute an unauthorised data transfer — even if it was accidental and the tool is reputable. The framework does not distinguish between intentional sharing and careless tooling choices. The question it asks is: did personal data leave the authorised processing boundary?

For HIPAA-covered entities specifically, sending protected health information to a third-party service that has not signed a Business Associate Agreement (BAA) is a reportable breach regardless of whether the data was misused.

How Browser-Native Tools Work Differently

Modern browsers are capable of running complex logic — parsing, validating, diffing, formatting, encoding — entirely within the JavaScript engine, with no network request required. A tool built on this model behaves like a local application that happens to be delivered over the web.

When you paste JSON into a browser-native tool:

  • The text goes into a JavaScript variable in your browser's memory.
  • A parser (also JavaScript) processes it in the same tab.
  • The output is rendered into the DOM.
  • No HTTP request is made to any server with your data as the payload.

The data never leaves your machine. It cannot be logged, cached, or indexed because it was never transmitted.

How to Verify a Tool Is Actually Local

Claims like "we never store your data" are common and unverifiable from the outside. The only reliable check is your browser's Network panel:

  1. Open DevTools (F12 or Cmd+Option+I).
  2. Go to the Network tab and tick Preserve log.
  3. Paste your JSON into the tool and trigger the operation (format, validate, etc.).
  4. Filter requests by XHR/Fetch. If any outbound request carries your input as a payload, the tool is not client-side.

A genuinely local tool will show no outbound POST or fetch carrying your data. You may see requests for static assets (CSS, JS files) or analytics pings, but none of those will contain your JSON payload.

// What a local tool does — no network call:
const result = JSON.parse(userInput);   // runs in the browser
render(result);                         // updates the DOM

// What a server-side tool does:
const res = await fetch('/api/format', {
  method: 'POST',
  body: JSON.stringify({ input: userInput }),  // your data leaves the machine
});

Practical Patterns: BAAs, WebCrypto, and Redaction Helpers

Three patterns close most of the remaining risk:

  • Business Associate Agreements (BAAs) for HIPAA-adjacent work — if your team handles protected health information, any third-party service that touches it needs a signed BAA on file. That's why pasting PHI into a random formatter, even one that "runs locally," is a documentation problem as much as a technical one.
  • Client-side WebCrypto — when you genuinely need to hash, sign, encrypt, or generate keys in the browser, the standard crypto.subtle API does it without a server round-trip. It's the right primitive for "decrypt this payload to look at it" without sending the ciphertext anywhere.
  • Redaction helpers — for debugging, run the JSON through a small redactor first that masks values at known sensitive keys (password, token, email, ssn) before pasting it anywhere. A twenty-line function beats discovering tokens in an analytics tool's request log.

Team Policies Worth Having

Individual awareness only goes so far. A lightweight policy covers the gap:

  • Classify before you paste. If the JSON contains names, emails, IDs, tokens, or keys — it's sensitive. Use a local tool or an approved internal one.
  • Maintain an approved tool list. A short list of verified local-first tools is easier to follow than a blanket "be careful" rule.
  • Never share production credentials in debugging sessions. Rotate any token or key that was pasted into an online tool, even if the tool appears safe.
  • Use scrubbed samples for debugging. Replace real user values with synthetic data before pasting. A structure with "email": "test@example.com"is just as useful for debugging a parse error as the real address.

Frequently Asked Questions

Is it safe to paste sensitive JSON into online tools?

Only if the tool processes everything in your browser. Server-side formatters can log, cache, or index your input — and pasting PII into a third party may itself breach GDPR or HIPAA, regardless of intent.

How do I check whether a JSON tool runs locally?

Open DevTools → Network, tick "Preserve log," and run the operation. If no outbound request carries your input as a payload, the tool is client-side. Static asset and analytics requests are fine; a POST of your JSON is not.

What should I do if I already pasted a token into an online tool?

Rotate it. Treat any credential or key that touched a third-party tool as compromised, even if the tool looks reputable. Remember a Base64-encoded token is still plaintext.

How can my team avoid this entirely?

Use browser-native tools, keep an approved-tool list, and debug with scrubbed sample data ("email": "test@example.com") instead of real records.

What fixjson.org Does

Every tool on fixjson.org — JSON repair, JSON diff, YAML formatter, JSON Stringify, Base64 encode/decode, and URL decode — runs entirely in your browser. The parser, the diff engine, and the formatters are all JavaScript executing locally. You can verify this in the Network tab: no POST request carries your input.

The site loads static assets (HTML, CSS, JS) once from a CDN. After that, it works offline. No input is sent to any server. No data is logged, stored, or shared.