Why You Should Format JSON Locally, Not in a Cloud Paste Tool

The thing I noticed at 1 AM

The first tool I built for this site was the JSON Formatter. The reason was a specific incident: I was debugging a REST API response at 1 AM, hit a malformed JSON string that was causing a silent parse failure, and pasted the whole response into one of the popular cloud formatters to see the structure. The response contained a user's authentication token and account ID.

I didn't think much about it in the moment. But the next day I looked at the formatter's URL. The formatted output was still live at a public URL with no expiry notice, no authentication, and indexed by search engines. The token was valid for another 6 hours.

That was the incident that made me build a local formatter. I want to be specific about the risk here, not just say "cloud formatters are bad" without explaining what actually happens.

What cloud paste formatters actually do with your data

When you paste JSON into a typical cloud formatter, the sequence is:

1. Your browser sends an HTTP POST to the service's API with your raw JSON as the request body.
2. The server parses and formats the JSON, then stores the result (usually with a generated ID) so it can serve the formatted view.
3. You get back a URL like formatter.example.com/view/a3f9c2 that serves your formatted output.

The storage duration varies. Some services delete after 24 hours. Some delete after 30 days. Some — particularly the ones that haven't been updated in years — don't expire links at all. A few index their content publicly for SEO purposes (every saved snippet is a unique URL with unique text content, which Google indexes).

Most cloud formatters have privacy policies that say something like "we may retain user content for service improvement purposes." That language is deliberately vague. It almost always means: your data sits on their servers, possibly indefinitely, possibly readable by their employees, and subject to whatever data breach incidents they might suffer in the future.

What categories of data actually end up in these tools

I asked several developer friends what they've pasted into JSON formatters in the last six months. The list was illuminating:

• Auth tokens and API keys (the most common)
• JWT payloads (which contain user IDs, roles, email addresses)
• Stripe webhook responses (contains payment amounts, customer IDs, partial card data)
• Salesforce API responses (customer records, deal sizes, contact details)
• Internal product analytics events (feature flags, A/B test assignments)
• Database query results serialized to JSON for debugging
• Configuration files that include database connection strings

Most developers doing this aren't being careless — they're in the middle of a debug session, they need to see the structure, and the cloud formatter is the fastest tool they know. The habit forms before the risk becomes obvious.

The GDPR and SOC 2 dimension

If you work on a product with EU customers, GDPR applies to any personal data processing you do — including sending that data to a third-party tool for formatting. Sending a customer's name, email, or account details to an unvetted cloud formatter counts as a data transfer to a third-party processor, and requires a Data Processing Agreement (DPA) with that third party.

No JSON formatter I've seen offers a DPA. Which means any developer at a GDPR-covered company who pastes customer data into a cloud formatter is creating a compliance incident — even if nothing bad ever comes of it technically.

For SOC 2 compliance, the same logic applies: you're transferring data to a vendor that hasn't been through your vendor security review process. If an auditor finds evidence of this (browser history, network logs), it's a finding.

How browser-based formatting actually works

A browser-based JSON formatter like the one on this siteworks entirely through the browser's JavaScript engine:

1. You paste or type JSON into a textarea.
2. The JavaScript calls JSON.parse()on the input, which validates and parses the JSON into a JavaScript object in your browser's memory.
3. Then JSON.stringify(parsedObject, null, 2) re-serializes it with standard 2-space indentation. (Or a custom indentation you choose.)
4. The result appears in the output panel. Nothing leaves your device.

You can verify this yourself: open the browser's Network tab (F12 → Network), paste a piece of JSON, and watch the network requests. You should see zero outgoing requests to external hosts. The only requests are for static assets (the JavaScript and CSS files that make the page work) which were fetched when you first loaded the page.

What you can't do in the browser (and alternatives)

Browser-based formatting has a few real limitations worth knowing:

• Large files. Parsing a 50 MB JSON file in-browser will be slow and may crash the tab on low-memory devices. For large files, use jq in the terminal: cat response.json | jq '.' is instant regardless of file size.
• Streaming JSON.Newline-delimited JSON (NDJSON), used by some APIs that stream results, requires line-by-line parsing. A simple browser formatter won't handle NDJSON correctly.
• JSON with comments (JSONC). Technically not valid JSON, but used in VS Code settings files and some config formats. Standard JSON.parse() rejects comments. You'd need a JSONC-aware parser or to strip comments first.
• Deeply nested structures.Some JSON formatters render a tree view with collapsible nodes. If your JSON has objects nested 20 levels deep, a flat formatted view is hard to navigate. VS Code's built-in formatter (Shift+Alt+F) handles deep nesting better than most browser tools because it integrates with the editor's folding.

The VS Code alternative (and why I still use the browser tool)

VS Code can format JSON natively: paste JSON into a new file, set the language to JSON (Ctrl+Shift+P → "Change Language Mode" → JSON), and press Shift+Alt+F. This is completely local, has excellent tree navigation, and handles large files well.

I still use the browser formatter for two reasons: speed and context switching. When I'm in the browser debugging an API call in the Network tab, copying the response body and switching to VS Code adds friction. Pasting into a tab I keep pinned in the browser is faster. The browser tool also works on shared devices and virtual machines where VS Code isn't installed.

The rule I now follow: if the JSON contains anything that looks like a token, a user ID, an email, or business logic — local only. VS Code or a browser-based tool. Never cloud.

Recognizing what's sensitive in a JSON response

Developers often paste data into formatters before reading it, which means they don't always know what's in it. Here's a quick mental checklist before pasting anything into a cloud tool:

• Does it contain any key named token, access_token, api_key, secret, password, or authorization? Treat as sensitive.
• Does it contain email addresses, phone numbers, names, or addresses? Treat as personal data (PII).
• Does it contain pricing, revenue, deal amounts, or internal product metrics? Treat as confidential business data.
• Does it contain internal hostnames, database names, or infrastructure details? Treat as sensitive.

If you can't tell at a glance — because the JSON is minified and opaque — use a local tool to format it first, then read it. Don't paste-to-read in a cloud tool.

What to actually do

Three options in order of convenience:

1. Browser-based local formatter. Open the formatter, pin the tab, use it whenever you need to inspect a response. Zero setup, works everywhere.
2. VS Code.Built-in formatter, excellent for large files and deeply nested structures. Best when you're already in the editor.
3. jq in the terminal. The most powerful option for scripting and large files. echo '{"a":1}' | jq '.' outputs formatted JSON. jq '.users[] | .email' extracts specific fields. Steep learning curve, completely local.

Related tools

• JSON Formatter and Validator — the tool this post is about. Also validates JSON schema and highlights syntax errors with line numbers.
• JSON to CSV converter — for when you want to open a JSON array in Excel or Google Sheets. Also runs entirely in the browser.
• Base64 encoder/decoder — JWT tokens are Base64-encoded; paste the payload segment here to decode it without sending it anywhere.

Written by Achraf A., founder of TheFreeAITools — built in Morocco. The JSON Formatter was the first tool I built on this site, motivated by the incident described above. It's been running client-side from day one.