Zum Hauptinhalt springen
ToolsByUs

JSON-Tools

Diese JSON-Tools laufen vollständig in Ihrem Browser. Fügen Sie ein Dokument ein oder ziehen Sie es hinein – geparst, verglichen, neu formatiert oder geprüft wird es auf Ihrem eigenen Rechner; die Payload wird nie hochgeladen. Jedes Tool implementiert RFC 8259 streng, statt sich auf JSON.parse des Browsers zu verlassen, sodass Fehler Zeile und Spalte angeben.

22 ToolsNur lokal

Vergleichen

Formatieren

Prüfen

Umwandeln

Analysieren

Wann sollten Sie ein browserbasiertes json-Tool verwenden?

Fast jedes JSON-Tool im Web ist ein Formular, das Ihr Dokument an einen Server schickt. Bei einem Snippet aus einem Tutorial ist das in Ordnung. Bei der echten Payload, die Sie gerade debuggen, ist es das so gut wie nie: JSON aus der Produktion enthält gern Access-Tokens, Kundendaten, interne Hostnamen und Konto-Bezeichner, und wer sie in einen unbekannten Endpunkt einfügt, übergibt all das an das Zugriffsprotokoll von jemand anderem. In einem regulierten Umfeld ist das kein Ermessensspielraum, sondern ein meldepflichtiger Vorfall.

Die Tools hier nehmen den Server vollständig aus der Gleichung. Die Seite, die Sie laden, ist statisches HTML und JavaScript; wenn Sie ein Dokument einfügen, wird es von Code geparst, der bereits in Ihrem Tab läuft. Es gibt keinen Request zu inspizieren und keinen Endpunkt, dem Sie vertrauen müssten – eine viel stärkere Position als das Versprechen, nicht hinzusehen.

Diese Entscheidung macht sie auch schneller. Kein Upload, keine Warteschlange, kein Roundtrip: Ein Dokument von 2 MB wird in der Zeit formatiert, in der sich die Anzeige neu zeichnet – nicht in der Zeit, die zwei Atlantiküberquerungen dauern. Und es bedeutet, dass die Tools im Flugzeug funktionieren, in einem abgeschotteten Firmennetzwerk und in einem VPN, das alles blockiert, was es nicht kennt.

Die Engines sind von Hand geschrieben statt aus Paketen zusammengesetzt – wichtiger, als es klingt. Der Parser ist iterativ statt rekursiv, meldet bei einem tief verschachtelten Dokument also einen Fehler, statt den JavaScript-Call-Stack sprengen zu lassen: Es gibt einen Test in der Suite, der ihm zwanzigtausend Verschachtelungsebenen vorsetzt. Jeder Schlüssel aus Ihrem Dokument wird über eine Own-Property-Prüfung zugewiesen, sodass eine Payload mit __proto__ das Verhalten der inspizierenden Seite nicht verändern kann. Das sind keine theoretischen Sorgen; das sind die beiden Arten, an denen JSON-Tools tatsächlich scheitern.

Wo es einen Standard gibt, wird er exakt eingehalten: RFC 8259 für die Grammatik, RFC 6902 für Patch-Dokumente, RFC 7386 für Merge-Patches und JSON Schema Draft 2020-12 für Inferenz und Validierung. Muss ein Tool eine Entscheidung treffen, die der Standard offenlässt – wie beim Vergleichen Array-Elemente einander zugeordnet werden, ob Schlüssel in der Ausgabe sortiert werden –, wird sie als Einstellung angeboten statt fest einprogrammiert, und die Referenztabelle auf jeder Seite erklärt, was die Einstellung in den Randfällen bewirkt.

Wenn Sie nicht wissen, wo Sie anfangen sollen: JSON validieren für ein Dokument, das sich nicht parsen lässt; JSON vergleichen für zwei Dokumente, die übereinstimmen sollten und es nicht tun; JSON formatieren für etwas Unlesbares; und JSON-Schema generieren, wenn Sie die Form einer Response beschreiben müssen, die Sie nicht selbst geschrieben haben.

Häufig gestellte Fragen

Mit welchem JSON-Tool finde ich heraus, warum meine Payload abgelehnt wird?

Beginnen Sie mit dem JSON-Validator. Er meldet den ersten Syntaxfehler mit exakter Zeile und Spalte und einem Caret-Zeichen unter dem problematischen Zeichen, und er sortiert die häufigsten Ursachen getrennt ein – ein Komma zu viel, eine Zeichenkette in einfachen Anführungszeichen, ein Schlüssel ohne Anführungszeichen, eine unpassende Klammer, eine Byte-Order-Mark oder ein typografisches Anführungszeichen, das aus einer Textverarbeitung eingefügt wurde. Ist das Dokument nahe an gültig, behebt die Ein-Klick-Reparatur es und zeigt Ihnen genau, was sie geändert hat, bevor Sie sie übernehmen.

Warum meldet der JSON-Vergleich keine Änderungen, obwohl die beiden Dokumente verschieden aussehen?

Weil die Reihenfolge der Objektschlüssel in JSON bedeutungslos ist. RFC 8259 definiert ein Objekt als ungeordnete Sammlung; {"a":1,"b":2} und {"b":2,"a":1} sind dasselbe Dokument, und ein semantischer Diff sagt genau das. Ein zeilenbasiertes Tool wie Unix diff vergleicht den serialisierten Text und meldet jeden umsortierten Schlüssel als Änderung – deshalb ist es auf formatierten API-Antworten fast nutzlos.

Gibt es eine Größenbeschränkung?

Tools, die auf dem Main-Thread laufen, schließen bei 8 MB – dem Punkt, ab dem ein einzelnes Parsing den Tab wie kaputt wirken lässt. Der JSON-Vergleich verlagert die Arbeit in einen Web Worker und akzeptiert bis zu 100 MB. Oberhalb dieser Grenzen lehnt das Tool mit einer klaren Meldung ab, statt einzufrieren – ein Vergleich mit 50 MB dauert weiterhin seine Zeit, aber die Oberfläche bleibt bedienbar, während er läuft.

Können diese Tools etwas mit JSONC anfangen – JSON mit Kommentaren?

Der JSON-Formatierer kann das. Er akzeptiert // und /* */-Kommentare sowie überzählige Kommas in der Eingabe und kann sie in der Ausgabe entfernen – genau das, was man für tsconfig.json, .eslintrc.json und ähnliche Konfigurationsdateien will. Der Validator ist absichtlich strenger: Er hält das Dokument exakt an RFC 8259 fest, denn wenn Sie wissen wollen, ob eine API eine Payload akzeptiert, ist eine nachsichtige Antwort die falsche.

Kann ich diese Tools offline benutzen?

Ja. Laden Sie eine beliebige Tool-Seite einmal, und sie arbeitet weiter, auch ohne Netz – trennen Sie das WLAN und probieren Sie es aus. Auf der anderen Seite gibt es nichts, womit man kommunizieren könnte: Die Website ist ein statischer Export ohne API-Routen, und jede Engine ist JavaScript, das bereits in Ihrem Tab läuft.

Was gibt es sonst noch auf ToolsByUs?

ToolsByUs – JSON-Tools