Paste an HJSON config into jsonformatter.org and it dies on the first comment line. Paste an NDJSON export and you get one parse error for the whole file, no indication which of the 50,000 lines actually broke. Paste a merge-mangled package.json and it'll happily pretty-print your out-of-order dependencies without telling you they're out of order. None of that is a bug — it's a single-purpose JSON formatter doing exactly what it says on the tin. The problem is that "JSON formatter" is what people search for even when what they're holding isn't strict JSON.
Verdict: if your input is actually JSON — format, validate, minify, convert to XML/YAML/CSV — jsonformatter.org is fine, free, and there's no reason to switch. We don't build a competing generic formatter to win that case; ours does the same job at JSON Formatter. Where we'd rather you use our tools instead is the three JSON-adjacent formats jsonformatter.org doesn't parse at all: HJSON, NDJSON/JSONL, and package.json's specific conventions. One tool per dialect beats one parser trying to be generous with all of them.
Where the two actually differ
| JSONFormatter.org | iotools.cloud JSON tools | |
|---|---|---|
| Plain JSON format/minify/validate | Yes, with line-numbered errors and a "JSON Fixer" auto-repair | Yes, via JSON Formatter |
| Convert JSON to XML / YAML / CSV | Yes — dedicated converter pages | Yes — JSON to XML, JSON to CSV, JSON to YAML (and back via XML, CSV, YAML to JSON) |
HJSON (comments, unquoted keys, ''' blocks) | Not supported — hard parse error on comments | Yes — HJSON Formatter & Validator, both directions |
| NDJSON / JSONL (one JSON value per line) | Not supported | Yes — NDJSON Formatter & Validator, with a per-line valid/invalid report |
package.json key ordering + dependency sort | No — general formatter only, doesn't know npm conventions | Yes — package.json Formatter & Key Sorter |
| Sharing a formatted result | "Save" uploads to their server and generates a link | Copy, download, or send the result straight into another tool — never uploaded anywhere |
| Sign-up required | No for basic use; yes if you want saved links to stay private | Never |
Both sides convert JSON to XML/YAML/CSV, so that's not actually where they split. The real split is input dialects: jsonformatter.org speaks one — strict JSON — and fans it out to several outputs. We went the other way and built one tool per input dialect, because HJSON, NDJSON and package.json don't fail the same way, and a generic parser papering over all three just means worse error messages for each.
Before you reach for either tool: hitting jsonformatter.org's "Save" button without logging in makes the link public — their own help text admits it: "If JSON data is saved without login, it will become public." Don't paste a real API response or a token-bearing config into it. It's not a dig — it's the kind of thing you want to know before, not after. Nothing in the iotools.cloud JSON tools ever leaves your browser, so there's no equivalent save-and-leak to worry about.
HJSON: the comments aren't clutter, they're the reason you're using HJSON
// and # comments, unquoted keys, trailing commas, multi-line ''' strings — a strict JSON parser rejects all of it, and jsonformatter.org is a strict JSON parser. Feed it an HJSON config and you get a parse error, full stop, no partial credit. Our HJSON Formatter & Validator handles both directions, and we're upfront that HJSON → JSON is lossy in one specific way: comments have nowhere to go in JSON, so they're dropped, not silently mangled. That's not a caveat we're hiding — it's in the docs because it's the actual behavior.
NDJSON: a 50,000-line file deserves more than "line 12,847 is broken, good luck"
NDJSON/JSONL puts one JSON value per line — the format log pipelines and streaming APIs use so a consumer never has to hold the whole file in memory. Run a large NDJSON export through a formatter built for single-document JSON and you get exactly one error, wherever the parser first chokes, with zero visibility into what else is wrong further down. Our NDJSON Formatter & Validator validates every line on its own and hands back a table — line number, Valid/Invalid/Blank, the exact error — so you fix six broken lines in one pass instead of six separate crashes.
package.json: "valid JSON" was never the bar
A package.json mangled by three different npm install runs is still perfectly valid JSON, so a generic formatter pretty-prints it without complaint — dependencies scattered out of order and all, which is exactly what trips sort-package-json or an ESLint rule in CI five minutes later. Our package.json Formatter & Key Sorter reorders top-level fields to match what npm init produces and alphabetizes each dependency block, leaving fields it doesn't recognize — a custom config block, say — untouched instead of quietly dropping them.
FAQ
Does jsonformatter.org store my JSON data?
Not for normal parsing. Their own FAQ says it "processes data on a browser" and only stores anything once you hit "Save Online" — at which point it's written to their server and public by default, per the note above.
Can I validate an NDJSON or JSONL file with a regular JSON validator?
No. A standard JSON validator expects exactly one top-level value for the whole input and will reject an NDJSON file at the first line break. You need something that treats each line as its own document, like the NDJSON Formatter & Validator.
Is HJSON just JSON with extra syntax I can paste anywhere?
Backwards, actually — any strict JSON document is already valid HJSON, but HJSON with comments or unquoted keys will fail a strict JSON parser every time. The conversion only works going through an HJSON-aware tool.
None of this is a knock on jsonformatter.org for what it's built to do — plain JSON in, plain JSON out, it's solid. It just isn't built for the three dialects above, and for a lot of developers that's more of the job than "never."
Cover photo by Godfrey Atima via Pexels.