💻 Coding

JSON Formatter

Paste JSON to validate and pretty-print it instantly, with clear error messages if something's wrong.



    
0 B
Original Size
0 B
Formatted Size

About the JSON Formatter

Formatting here just means handing your text to the browser's native JSON.parse and printing the result back out with JSON.stringify, so what counts as valid is whatever the JavaScript engine itself accepts, nothing more lenient. A failed parse shows you the engine's own error message rather than a generic one, and the Minify toggle collapses the same data down to a single whitespace-free line.

Why using the strict native parser is actually the point

Some JSON viewers are deliberately lenient, silently accepting trailing commas, unquoted keys, single-quoted strings, or inline comments, all common in relaxed formats like JSON5 or JSONC, or just in casual hand-typed JavaScript object literals. This tool doesn't do that. Because it hands your input directly to the browser's own JSON.parse, exactly what would run in any real JavaScript application or API endpoint, if this tool accepts your JSON, a production JSON.parse call will accept it too, and if it rejects it, so will your actual code. That strictness is a feature for validation purposes specifically, a lenient formatter that "fixes" small syntax issues on the fly would give you false confidence about JSON that's actually invalid.

How raw error positions get translated into line and column numbers

JavaScript's native JSON parse errors report a plain character offset into the string, something like "Unexpected token } in JSON at position 142", which is genuinely hard to locate by eye in a large pasted document. This tool extracts that position number from the error message with a regex, then walks the input text counting newline characters up to that point to calculate an actual line and column number, appending something like "(line 8, column 3)" to the error. That conversion turns a raw byte offset into something you can actually use to find the problem in your editor.

A genuine JavaScript quirk: numeric-looking keys can get silently reordered

JavaScript objects preserve the insertion order of string keys, with one specific exception in the language spec: keys that look like non-negative integers (like "2" or "10") are automatically sorted numerically ascending and placed before all other keys, regardless of what order they appeared in the source. That means JSON like {"b": 1, "2": 2, "a": 3, "1": 4} round-trips through this formatter as {"1": 4, "2": 2, "b": 1, "a": 3}, the numeric keys jump to the front in ascending order. This isn't a bug in the tool, it's standard, specified JavaScript object behavior that any code parsing and re-serializing your JSON with JSON.parse/JSON.stringify would also exhibit.

Duplicate keys silently collapse to the last one

If your input JSON has the same key repeated more than once inside an object, like {"name": "A", "name": "B"}, JSON.parse doesn't error and doesn't preserve both, it silently keeps only the last occurrence. The formatted output will only ever show one value per key, with no warning that a duplicate existed in your original input. This is standard JSON.parse behavior, not something this tool could detect or preserve differently while still using the native parser, so if duplicate keys are a concern, it's worth checking your source data for them separately before relying on this tool's round-trip.

A practical limitation with very large integers

JSON numbers get parsed into JavaScript's standard double-precision floating point format, which can only represent integers exactly up to 2^53 − 1 (about 9 quadrillion). Large IDs beyond that range, the kind generated by some database systems, snowflake-style unique IDs, or 64-bit integer fields, can silently lose precision when round-tripped through this formatter, coming out as a slightly different number than what went in. If your JSON contains very large integer IDs and exact precision matters, verify them against the original source rather than trusting the formatted output for those specific values.

Frequently Asked Questions

Why does this formatter reject JSON with trailing commas or comments?

It uses the browser's native, spec-strict JSON.parse, the same parser real applications and APIs use. If this tool rejects your input, production code would too, which makes it a genuinely useful validator rather than a lenient viewer that might silently accept invalid JSON.

Why does the error message include a line and column number?

JavaScript's native parse error only reports a raw character position, which is hard to locate in a large document. This tool converts that position into a line and column number by counting newlines up to that point, making the error location much easier to find in your editor.

Why did the key order in my JSON change after formatting?

JavaScript objects preserve string key order, but keys that look like non-negative integers get automatically sorted numerically ascending and moved before all other keys, per the language specification. This is standard JavaScript behavior, not a bug in this tool.

What happens if my JSON has the same key twice in one object?

JSON.parse silently keeps only the last occurrence and discards earlier duplicates, with no warning. The formatted output will show just one value per key, so check your source data separately if duplicate keys matter to you.

Can very large integer IDs lose precision when formatted?

Yes, JSON numbers parse into JavaScript's standard floating-point format, which only represents integers exactly up to about 9 quadrillion (2^53 - 1). Larger IDs, like some database or snowflake-style identifiers, can come out slightly different than the original value.

Do Minify and Format ever show inconsistent versions of my data?

No, both are generated by re-stringifying the same already-parsed JavaScript value, just with different JSON.stringify arguments. Since they share one source of truth, the minified and formatted outputs always represent identical underlying data.