The text is parsed with the browser's own JSON parser, which is the same one your code will use, so anything accepted here will be accepted there. Beautifying re-prints the parsed data with two-space indentation; minifying re-prints it with no whitespace at all. Both produce the same data, and both report the root type, the key or item count, and the byte size.
When parsing fails, the message is turned into a line and column rather than a character offset, because an offset in a 40,000-character payload tells you nothing. It is strict JSON throughout: comments, trailing commas, single quotes and unquoted keys are all rejected, exactly as they would be by an API.
Reading the result honestly
-
The output is a re-print, not your text:
the data is parsed and written out again, so whitespace, line breaks and formatting choices are replaced rather than tidied.
-
Duplicate keys silently collapse:
JSON allows them and the parser keeps the last one. If a payload had two keys of the same name, only one survives the round trip and nothing warns you.
-
Very large integers lose precision:
anything beyond about sixteen digits is rounded, because numbers are parsed as doubles. Identifiers of that size belong in strings.
-
Numeric-looking keys are reordered:
a key such as "2" is moved ahead of ordinary text keys when the object is written out. The data is identical; the order is not what you pasted.
Parsed by the same engine your code will use
Text is parsed with the browser's own JSON parser, the same one any JavaScript running elsewhere will use, so anything the [msm_tool slug="json-formatter"] accepts is exactly what real code accepts too. Beautifying re-prints the parsed data with two-space indentation; minifying re-prints it with none at all — both represent identical data, differing only in how it is laid out.
Duplicate keys collapse without a warning
JSON's grammar permits the same key to appear more than once in an object, and the parser keeps only the last occurrence — the earlier ones are silently discarded rather than merged or flagged. A payload built with an accidental duplicate key loses data on the round trip with nothing in the output to indicate it happened.
Very large integers quietly lose precision
Numbers are parsed as doubles, which rounds anything beyond roughly sixteen digits rather than preserving it exactly. An identifier that size needs to travel as a string rather than a bare number, since the numeric form cannot actually hold it intact through a JSON round trip.
Numeric-looking keys get reordered
A key such as `"2"` is moved ahead of ordinary text keys when the object is written back out, because that ordering is part of how the underlying language itself handles property keys that look like non-negative integers. The data is completely unchanged; only the order it appears in differs from what was originally pasted in.
Errors point at a line and column, not an offset
A raw character offset means very little in a payload tens of thousands of characters long, so a parse failure is translated into a line and column instead — almost always enough on its own to find a stray comma or a missing quote without hunting through the whole file.
Strict JSON throughout, deliberately
Comments, trailing commas, single quotes and unquoted keys are all rejected outright, exactly as a real API would reject them. A file that needs any of those is JSON5 or JSONC rather than JSON, and accepting it here would only hide a problem that the actual consuming code will not forgive.