A formatter leak that should change how you pick tools

In late November 2025, security firm watchTowr published a disclosure about two of the most popular online JSON formatter sites — jsonformatter.org and codebeautify.org. Both offered a "Recent Links" feature that let users share formatted output with a teammate. The URLs were predictable, which meant the saved content was effectively reachable to anyone who guessed the URL pattern.

Per the watchTowr report, the result was over 80,000 saved snippets, totaling 5 GB+ of data, sitting on the public internet without authentication. The content that researchers were able to retrieve included:

• Active Directory credentials
• Cloud access keys (AWS / Azure / GCP)
• Private keys and CI/CD secrets
• JWTs from production systems
• AWS Secrets Manager exports

Based on the content of individual snippets, the data appeared to originate from a wide range of organizations — government, finance, healthcare, aerospace. Full disclosure: watchTowr — "Stop Putting Your Passwords Into Random Websites".

Two things worth flagging up front:

1. The vulnerable surface was the saved-and-shared feature, not every act of pasting into the formatter. Plenty of online formatters do not retain saved content, and some have already responded to the disclosure. It is not a blanket "all online tools are leaking" story.
2. The lesson generalizes anyway: if a tool can persist your input on its servers, your threat model has to assume it might, until proven otherwise.

How to actually verify what a formatter does

Most developers I know pick a formatter the same way they pick a coffee shop: whichever is closest, whichever rendered first. The leak suggests we should be slightly more deliberate. A few questions you can answer in under a minute per tool:

• Open DevTools → Network, paste your input, hit format. Does any outgoing request carry a payload that contains your input or the converted output? If yes, your data left the browser. Hostnames matter — first-party analytics pings are different from a POST /api/format.
• Is there a "save and share" / "recent links" / "history" feature? If yes, your input is probably being stored, even if the URL looks ephemeral.
• Is the conversion logic open source? Not the marketing site — the actual parser. A static site that links to its own source repo is much easier to verify than a closed page.
• Is there a CLI version with the same engine? If yes, you can usually verify the parser end-to-end with offline tools (strace, tcpdump, sandboxed Docker run) before trusting the web version.

This is a generic checklist. It is not specific to any tool, including mine.

What I built, and what I am not claiming

For my own use I built FormatArc — a converter for JSON, YAML, CSV, Markdown, and HTML. The architecture choices are not novel; they just happen to make some of the questions above answerable:

• Next.js with output: "export" — pure static site, no server runtime
• All parsing in the browser (JSON.parse, js-yaml, papaparse, marked, turndown, remark)
• No /api/* routes in the project (you can grep app/ on the CLI repo for the same parser core)
• No persistence of input to localStorage or IndexedDB by design — input lives in React state and goes away with the tab

What I will not claim:

• "Zero network requests." Open DevTools and you will see chunk loads, fonts, the Next.js prefetch, and so on. The honest claim is narrower: no outgoing request whose payload contains the pasted input or the converted output. That is the one that matters for the leak threat model.
• "Works offline." I have not shipped a Service Worker, so a real offline guarantee does not exist. The right phrasing is "no upload of your data," not "works without network."
• "Bulletproof." Browser-side tools have their own failure modes — XSS in a parser, a compromised CDN, a malicious browser extension reading the DOM, a supply-chain hit on an npm dep. None of these are eliminated by removing the backend. The browser is a smaller blast radius, not zero.

A comparison that I think is actually verifiable

I tried to write this table in terms you can verify yourself rather than self-flattering bullet points:

If any cell is wrong by the time you read this, file an issue — I would rather correct it than carry a stale claim. The two competitor sites do change their feature sets.

When CLI tools are still the right answer

For shell pipelines, CI scripts, and anything bigger than a paste window, dedicated CLIs are usually still the right tool. jq, yq, csvkit, mlr, and pandoc cover the structured-query and large-file cases better than any browser tool. FormatArc is for the interactive, paste-and-go work where you specifically don't want the input ending up on someone else's server.

For the overlap case, you can use the same parser core from the CLI:

# One-shot convert
npx formatarc json-format '{"name":"FormatArc","tools":3}'

# Pipe-friendly
cat config.yaml | npx formatarc yaml-to-json > config.json

A note on npx: it is convenient but not a security guarantee on its own. Pin a version, audit the dependency tree, or install from source if you are running this inside a sensitive environment.

Try it, break it, tell me

• Web: https://formatarc.com
• Source: https://github.com/m-naoki-m/formatarc

If you find a case where the verification claims above do not hold — a request that leaks input, an edge case where the parser misbehaves, a YAML 1.1 vs 1.2 inconsistency — open an issue. I would rather hear it from you than learn it the hard way.