Paste an HJSON config — comments, unquoted keys, a trailing comma — into jsonformatter.org's parser and it errors out immediately, because HJSON isn't JSON and the tool doesn't parse it as anything else. Same story for an NDJSON log export or a package.json that got its keys shuffled by a merge: technically JSON-adjacent, not JSON, not handled. That's usually the moment someone goes looking for an alternative — not because JSONFormatter.org is bad at its job, but because a chunk of what developers actually paste into a "JSON formatter" this week isn't strict JSON at all.
Short answer: for plain JSON — format, validate, minify, convert to XML/YAML/CSV — jsonformatter.org is a solid, free, no-signup tool and there's no reason to switch. Where it runs out of road is the JSON-shaped formats that aren't JSON: HJSON configs, NDJSON/JSONL streams, and package.json's specific key ordering. iotools.cloud has a dedicated tool for each of those instead of trying to bolt them onto one generic formatter.
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 | No — out of scope, single-purpose by design |
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 | No sharing feature — nothing ever leaves the browser to begin with |
| Sign-up required | No for basic use; yes if you want saved links to stay private | Never |
The pattern is the trade-off: JSONFormatter.org spreads one tool across several output formats (JSON→XML, JSON→YAML, JSON→CSV). We went the other way and built a dedicated tool per input dialect, because the failure modes are different enough that a generic parser handles them badly.
Why the three extra formats aren't just JSON with a different hat
HJSON allows // and # comments, unquoted keys, trailing commas, and multi-line ''' strings — all things a strict JSON parser rejects outright. Converting HJSON → JSON is one-directional in a real sense too: comments have nowhere to go in JSON, so they're dropped, not preserved. A tool that only speaks JSON can't tell you that up front; ours does, in the docs and in the conversion itself, because it's the actual behavior, not a caveat someone forgot to mention.
NDJSON (newline-delimited JSON / JSONL) puts one full JSON value per line instead of wrapping everything in a single array — the format most log pipelines and streaming APIs use because a consumer can process one line at a time without holding the whole file in memory. Feed a 50,000-line NDJSON export into a normal JSON formatter and you get one giant parse error at whichever line broke first, with no way to see what else is wrong. Our NDJSON tool validates every line independently and returns a table: line number, Valid/Invalid/Blank, and the exact parser error for anything that failed — so you find all six broken lines in one pass instead of fixing them one crash at a time.
package.json is valid JSON, so a generic formatter will happily pretty-print one — but "valid JSON" isn't the bar anyone actually cares about here. The real annoyance is a package.json merged from three different npm install runs with dependencies scattered out of alphabetical order, tripping sort-package-json or an ESLint plugin in CI. Our formatter reorders top-level fields into the sequence npm init uses and alphabetizes each dependency block, while leaving fields it doesn't recognize (a custom config block, say) in place instead of dropping them.
If you save a result on JSONFormatter.org without logging in, it becomes a public link — their own help text says so: "If JSON data is saved without login, it will become public. To make json data private please login and save the links." Worth knowing before you paste a real API response or a config with a token in it into their Save button. None of the iotools.cloud JSON tools have a save/share feature that uploads anywhere — parsing and formatting happen entirely in your browser, so there's nothing to leak in the first place.
FAQ
Does JSONFormatter.org store my JSON data?
Not for normal parsing — their own FAQ states it "processes data on a browser" and doesn't store JSON unless you explicitly use "Save Online," at which point it's written to their server database and is public by default.
Can I validate an NDJSON or JSONL file with a regular JSON validator?
No — a standard JSON validator expects one top-level value (an object or array) for the whole input, and will reject an NDJSON file at the first line break. You need a validator that treats each line as its own JSON document, like the NDJSON Formatter & Validator.
Is HJSON valid JSON I can just paste into any JSON tool?
The reverse is true — any strict JSON document is valid HJSON, but HJSON with comments or unquoted keys will fail a strict JSON parser. Converting has to go through an HJSON-aware tool.
If your input actually is plain JSON, JSONFormatter.org will format it fine — that's not in question. The gap only shows up the moment what you're pasting stops being strict JSON, which for most developers is more often than "never."
Cover photo by Godfrey Atima via Pexels.