Der Text wird mit dem browsereigenen JSON-Parser gelesen, demselben, den auch Ihr Code verwendet – was hier angenommen wird, wird dort ebenfalls angenommen. Das Verschönern gibt die gelesenen Daten mit zwei Leerzeichen Einrückung neu aus, das Verkleinern gibt sie ganz ohne Leerraum aus. Beide liefern dieselben Daten und melden Wurzeltyp, Anzahl der Schlüssel oder Elemente sowie die Größe in Bytes.
Schlägt das Lesen fehl, wird die Meldung in Zeile und Spalte übersetzt statt in einen Zeichenversatz, denn ein Versatz in 40.000 Zeichen sagt nichts. Es gilt durchgehend striktes JSON: Kommentare, nachgestellte Kommas, einfache Anführungszeichen und Schlüssel ohne Anführungszeichen werden abgelehnt, genau wie eine API es täte.
Das Ergebnis ehrlich lesen
-
Die Ausgabe ist ein Neusatz, nicht Ihr Text:
Die Daten werden gelesen und neu geschrieben, sodass Leerraum, Zeilenumbrüche und Formatierungsentscheidungen ersetzt und nicht aufgeräumt werden.
-
Doppelte Schlüssel verschwinden stillschweigend:
JSON erlaubt sie, und der Parser behält den letzten. Hatte eine Nutzlast zwei gleichnamige Schlüssel, überlebt nur einer den Durchlauf, und nichts warnt Sie davor.
-
Sehr große Ganzzahlen verlieren an Genauigkeit:
Alles jenseits von etwa sechzehn Stellen wird gerundet, weil Zahlen als Gleitkommawerte gelesen werden. Kennungen dieser Länge gehören in Zeichenketten.
-
Zahlenartige Schlüssel werden vorgezogen:
Beim Ausgeben rückt ein Schlüssel wie „2“ vor die gewöhnlichen Textschlüssel. Die Daten bleiben gleich, die Reihenfolge nicht die eingefügte.
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.