← All articles
Updated May 29, 202612 min read

Don't Paste Sensitive JSON Into Online Tools: Use Local Parsers

Sensitive JSON can leak through formatter logs, analytics, caches, tickets, screenshots, and browser extensions. Learn what not to paste, how to verify browser-local tools, and how to redact safely.

A JSON formatter feels harmless until the payload contains a bearer token, a customer email, a webhook secret, or a database connection string. The developer just wants to fix a parse error. The online tool may see an entire production request body.

Treat pasted JSON as sensitive by default. Use a browser-local tool or local command-line parser when the data comes from production, logs, support tickets, API responses, JWTs, cookies, configuration files, or customer records. If the tool sends the JSON to a server, you have shared the data with that service.

Quick Rule

If the JSON contains anything you would not put in a public issue, Slack screenshot, or search-indexed page, do not paste it into a server-side formatter.

Use this decision table:

JSON contains Safer workflow
API keys, bearer tokens, cookies, JWTs, session IDs Do not paste; rotate if already exposed.
Customer names, emails, addresses, phone numbers, IDs Redact first, then use a browser-local or approved internal tool.
PHI, financial records, legal records, regulated data Use approved internal tooling and follow compliance policy.
Webhook bodies and signatures Use local tools; signatures and event IDs can be sensitive.
Error logs with headers or request bodies Redact secrets before formatting, diffing, or sharing.
Database exports or admin API responses Work locally; sample the shape instead of copying the whole dump.
Synthetic examples with fake values Online tools are lower risk, but browser-local is still cleaner.

The shape of the JSON is usually all you need for debugging. Real values are rarely necessary.

What Sensitive JSON Looks Like

Sensitive JSON is not only obvious fields such as password.

Common examples include:

  • Authorization headers: Authorization: Bearer ..., API keys, OAuth tokens, refresh tokens, session cookies.
  • JWTs: normal signed JWTs are Base64url-encoded, not encrypted. Anyone with the token can decode the header and payload.
  • Customer records: names, emails, phone numbers, addresses, billing IDs, account IDs, organization IDs.
  • Webhook events: event IDs, signatures, customer IDs, order details, retry metadata.
  • Configuration files: database URLs, hostnames, feature flags, private service endpoints, queue names, cloud resource IDs.
  • Logs: request bodies, response bodies, headers, query strings, internal trace IDs, stack traces.
  • Exports: admin search results, table dumps, support snapshots, analytics events, audit trails.

Here is the uncomfortable version of a normal debug payload:

{
  "user": {
    "id": "usr_1847",
    "email": "ada@example.com"
  },
  "headers": {
    "authorization": "Bearer eyJhbGciOiJIUzI1NiIs..."
  },
  "databaseUrl": "postgres://app:secret@example.internal:5432/main",
  "featureFlags": {
    "betaBilling": true
  }
}

You may only care that featureFlags.betaBilling is present. The formatter can still receive the token, email, and connection string.

How Online JSON Tools Can Leak Data

Online JSON tools vary. Some run entirely in the browser. Some POST your text to an API. Some process locally but still load scripts that can observe the page. The risk comes from the full path your pasted data can take.

Server request bodies

If the tool sends your JSON to /api/format, /api/validate, /repair, or a similar endpoint, your payload becomes an HTTP request body handled by someone else's infrastructure.

That body may pass through:

  • Application servers.
  • Reverse proxies.
  • CDN edge nodes.
  • Load balancers.
  • Serverless function logs.
  • Error tracking.
  • Analytics and product telemetry.

Even if the operator does not intend to store your data, systems around the request can capture it.

Logs and error tracking

Logging is where "we do not store your data" often becomes fuzzy. A parser error, timeout, or exception can include the submitted body or a preview of it in:

  • Application logs.
  • Debug logs.
  • Sentry, Bugsnag, Rollbar, Datadog, CloudWatch, or Splunk events.
  • Developer console output from a support session.
  • Retained request samples used for troubleshooting.

A rejected JSON payload can be more likely to appear in error tooling because it is the thing that caused the exception.

Analytics, ads, and third-party scripts

Client-side processing is not enough if the page also runs third-party JavaScript that can read the input field. Any script executing in the same page context can potentially inspect the DOM, observe events, or receive error breadcrumbs.

For low-risk fake data, this may not matter. For tokens, PHI, production logs, or customer exports, use a tool you trust operationally, not just one with a reassuring headline.

Share links and cached results

Some tools create shareable URLs for formatted JSON. If the URL contains the data or points to a stored result, that value can leak through browser history, chat previews, logs, crawler access, or accidental sharing.

Avoid share links for real payloads. Share a scrubbed sample instead.

Screenshots, tickets, and chat

Local parsing protects the parsing step. It does not protect what happens next.

Developers often paste formatted output into:

  • GitHub issues.
  • Jira tickets.
  • Slack or Teams threads.
  • Pull request comments.
  • Support emails.
  • Screenshots and screen recordings.

Redact before sharing. A local tool can keep the payload off a formatter's server, but it cannot stop a token from appearing in a screenshot.

Browser-Local Tools: What They Actually Mean

A browser-local JSON tool parses, formats, repairs, validates, diffs, or decodes data using JavaScript running in your browser tab. Your input stays in page memory and no request containing the input is sent to a server.

The local flow looks like this:

const value = JSON.parse(inputText);
const output = JSON.stringify(value, null, 2);
render(output);

A server-side flow looks like this:

const response = await fetch("/api/format", {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify({ input: inputText })
});

The second version sends your payload across the network. The first version does not.

Browser-local is a strong privacy improvement, but it is not magic. The page code, browser extensions, injected corporate security tools, and anything you share after formatting can still matter. For highly regulated or highly sensitive data, use an approved internal tool or a local CLI workflow.

How to Verify a JSON Tool Runs Locally

Do not rely only on marketing copy. Check the browser.

  1. Open DevTools.
  2. Go to the Network tab.
  3. Enable Preserve log.
  4. Clear the existing network entries.
  5. Paste a unique harmless test value, such as {"probe":"local-test-4937"}.
  6. Run the operation: format, repair, validate, diff, decode, or convert.
  7. Filter by Fetch/XHR and inspect request payloads.
  8. Search the network log for local-test-4937.

If any outbound request contains that value, the operation is not fully local.

You may still see requests for static JavaScript, CSS, fonts, analytics pings, or page assets. The key question is whether your JSON payload appears in a request body, query string, path, error event, or analytics payload.

For a stricter check, disconnect from the network after the page loads and run the tool again. A truly local formatter, validator, viewer, or decoder should still perform the operation after its assets are already loaded.

A Practical Redaction Workflow

When you only need to inspect structure, replace values before formatting or sharing:

{
  "user": {
    "id": "usr_REDACTED",
    "email": "user@example.test"
  },
  "headers": {
    "authorization": "Bearer REDACTED"
  },
  "items": [
    {
      "sku": "SKU-EXAMPLE",
      "price": "19.99"
    }
  ]
}

Preserve the shape, not the secrets.

For repeat work, use a redaction helper before the JSON leaves your editor:

const SENSITIVE_KEYS = new Set([
  "authorization",
  "access_token",
  "refresh_token",
  "token",
  "apikey",
  "api_key",
  "password",
  "secret",
  "client_secret",
  "cookie",
  "set-cookie",
  "email",
  "phone",
  "ssn"
]);

function redactJson(value) {
  if (Array.isArray(value)) {
    return value.map(redactJson);
  }

  if (value && typeof value === "object") {
    return Object.fromEntries(
      Object.entries(value).map(([key, child]) => {
        const normalized = key.toLowerCase();
        return [
          key,
          SENSITIVE_KEYS.has(normalized) ? "[REDACTED]" : redactJson(child)
        ];
      })
    );
  }

  return value;
}

const redacted = redactJson(JSON.parse(inputText));
console.log(JSON.stringify(redacted, null, 2));

This is intentionally conservative, not perfect. For regulated data, combine key-based redaction with an allowlist: keep only fields that are needed for the debugging question and drop everything else.

Local CLI Alternatives

For sensitive payloads, the safest workflow is often boring local tooling:

python3 -m json.tool response.json
jq . response.json
jq 'del(.headers.authorization, .cookie, .setCookie)' response.json

For JWT payload inspection, decode locally and remember that decoding is not verification:

node -e 'const t=process.argv[1].split(".")[1]; console.log(JSON.stringify(JSON.parse(Buffer.from(t,"base64url").toString()), null, 2))' "$JWT"

For browser work, use browser-local tools. For production incidents, regulated data, or credentials, prefer approved internal tooling, local files, or a locked-down development environment.

What to Do If You Already Pasted a Secret

Do not spend an hour debating whether the tool probably stored it. Treat exposed credentials as compromised.

  1. Rotate the API key, token, cookie secret, webhook secret, or password.
  2. Revoke active sessions if a session token or cookie was pasted.
  3. Search logs and tickets for copied copies of the same value.
  4. Check whether the tool created a share link or browser history entry.
  5. Notify your security or compliance team if customer data, PHI, regulated data, or production credentials were involved.
  6. Replace the debugging sample with a scrubbed version for future work.

For JWTs, remember that Base64url encoding is not encryption. Anyone with the token can decode the header and payload. See Base64 Is Not Encryption and How to Decode a JWT.

Team Policy That People Will Actually Follow

A useful policy is short enough to remember:

  1. Assume pasted JSON is sensitive.
  2. Use browser-local or local CLI tools by default.
  3. Use approved internal tools for production and regulated data.
  4. Never paste tokens, cookies, private keys, or production secrets into unknown tools.
  5. Redact before screenshots, tickets, chats, docs, or pull requests.
  6. Rotate anything secret that was pasted into a third-party server-side tool.

Teams can make this easier by maintaining an approved tool list and a few scrubbed sample payloads. A real-looking fake payload saves time when someone only needs to reproduce a parse error or show a nested shape.

Regulatory and Contract Boundaries

This article is practical engineering guidance, not legal advice. The operational point is simple: if personal data, protected health information, or regulated business data leaves your approved processing boundary, your obligations may change.

Under GDPR-style controller/processor models, a third-party service that processes personal data on your behalf can become part of the data-processing chain. Under HIPAA, services that create, receive, maintain, or transmit electronic protected health information for a covered entity or business associate generally need the right business associate arrangement. Your organization may also have customer contracts, DPAs, SOC 2 controls, internal data-classification rules, or incident-notification requirements.

The safe developer habit is to avoid creating that question in the first place. Keep production JSON local or inside approved systems.

What fixjson.org Does

fixjson.org tools are designed around browser-local processing. JSON repair, formatting, validation, viewing, diffing, YAML conversion, JWT decoding, Base64 encode/decode, URL decode, and JSON stringify all run in the browser with JavaScript.

You can verify this yourself:

  1. Open the tool.
  2. Open DevTools -> Network.
  3. Clear the log and enable Preserve log.
  4. Paste a unique test string.
  5. Run the operation.
  6. Confirm no request payload contains your input.

Use the same caution after the operation: redact before you share output in a ticket, screenshot, chat, or document.

Frequently Asked Questions

Is it safe to paste sensitive JSON into online tools?

Only if the tool processes the JSON locally in your browser and the page environment is trusted. Server-side formatters, validators, repair tools, and diff tools can expose input through request bodies, logs, analytics, caches, support access, or share links.

How do I check whether a JSON tool runs locally?

Open DevTools, go to Network, enable Preserve log, clear the log, paste a unique harmless test value, run the tool, and search requests for that value. If your input appears in a request body, query string, path, or analytics event, it is not fully local.

What JSON fields should I redact before sharing?

Redact authorization headers, cookies, JWTs, access tokens, refresh tokens, API keys, passwords, private keys, emails, phone numbers, addresses, customer IDs, account IDs, webhook signatures, database URLs, and internal hostnames unless they are fake sample values.

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

Rotate it immediately. Treat tokens, cookies, API keys, webhook secrets, and passwords as compromised once they have been pasted into a third-party server-side tool or shared link.

Are JWTs safe to paste if they are signed?

No. A normal signed JWT is integrity-protected, not encrypted. Anyone with the token can decode the header and payload, and anyone who can use the token before it expires may be able to authenticate as that subject.

Is browser-local processing enough for regulated data?

Not always. Browser-local processing reduces network exposure, but your organization may require approved tools, audit controls, DPAs, BAAs, or internal environments for regulated or contractual data. Follow your policy.

Can browser extensions or third-party scripts see pasted JSON?

They can in some environments. Scripts running in the page context and powerful browser extensions may inspect DOM input or page activity. For highly sensitive data, prefer local CLI tools or approved internal tools.

How can my team avoid accidental JSON leaks?

Maintain an approved-tool list, use browser-local or local CLI tools by default, provide scrubbed sample payloads, redact before screenshots and tickets, and rotate any secret that was pasted into an unapproved tool.

Related Tools & Guides

Sources

Last reviewed July 2026.