I don't think the answer is "never use web tools". They are genuinely useful. The answer is to know which kind of tool you are using and match it to the data. Here is the mental model I use.

Three kinds of "online" JSON tool

1. Server-side tools. Your text is sent to a backend, processed and sent back. Formatting, conversion and validation may all happen remotely. These can be perfectly fine for public sample data. They are the wrong place for anything sensitive, because you cannot see what is logged or kept.

2. Fully client-side tools. The page loads once and everything happens in your browser's JavaScript. Your JSON never needs to travel anywhere. These are the safest web option, though you are still trusting the code the page loaded.

3. Local-first tools with optional remote features. This is the category most modern tools actually fall into. Core work such as parsing, formatting, tree views and conversion runs in the browser, while specific features call an external service. AI-assisted repair, sharing links and cloud sync are typical examples. The term comes from the Ink & Switch essay on local-first software, which argues that your data should live primarily on your own device, with the network as an enhancement rather than a requirement.

The third category is where people get confused. "Local-first" is not the same as "100% local". If you click the button that sends your broken JSON to an AI model, it leaves the browser. That is usually documented. Whether you read it is another matter.

How to tell which kind you're using

You don't have to trust marketing copy. You can check:

• Open DevTools → Network and clear it. Paste your JSON and use the feature. If no request carries your payload, the work happened locally. Repeat for each feature you plan to use, not just the first one.
• Go offline. Load the page, disconnect, and try again. Features that still work are local. Features that fail are not.
• Read the privacy page for specifics. Look for named third parties (an AI provider, an analytics service) and for which features use them.

This takes about two minutes and answers the question better than any badge on a landing page.

Matching the tool to the data

My rough rules:

For the last row, no web tool is the right answer, however it is built. Your editor and jq are already on your machine and are not going anywhere.

Redact before you paste

When I do need a visual tool for real data, for example to see a deeply nested response as a table, I redact first. A small jq filter does it:

jq 'walk(if type == "object" then
  with_entries(if (.key | test("email|token|secret|password"; "i"))
    then .value = "REDACTED" else . end)
else . end)' response.json > safe.json

It is not perfect. It matches key names, not values. But it removes the obvious hazards and keeps the structure intact, which is usually what you need to debug.

What I actually use

For terminal work, jq covers most things. For visual inspection of large payloads I use a browser toolkit at https://jsonswiss.com/. It describes its core features as running in the browser (tree and table view, formatting, validation, conversions), and it is explicit that AI-assisted repair goes through an AI provider. That is a good example of honest local-first design: the default path is local, and the remote path is opt-in and labelled. I still apply the table above. The data decides, not the tool.

The short version

• "Online tool" covers three very different architectures.
• Local-first means local by default, not never remote.
• Two minutes in the Network tab tells you more than the marketing does.
• Sensitive data stays in local tools, and you redact before visualising.

None of this is complicated. It just has to become a habit before the day it matters.