TOML zu JSON umwandeln

Was macht der TOML-zu-JSON-Konverter?

Der Konverter liest TOML 1.0 und gibt drei Zielformate aus (JSON, JSON5 oder YAML) je nachdem, wofür das Ergebnis weiterverwendet werden soll. Anders als typische Konverter, die alle TOML-Werte in einen flachen JSON-Strom drücken, behält dieser Konverter die strukturellen Informationen, die TOML vom JSON unterscheidet: vier Datetime-Typen, Kommentare und nachvollziehbare Hierarchie.

Pure-client. Jede Eingabe bleibt in deinem Browser. Keine Anmeldung, kein Server-Upload, kein Tracking, du kannst das mit den Browser-Dev-Tools im Netzwerk-Tab selbst überprüfen.

Drei Eigenschaften unterscheiden ihn von den Standard-Konvertern:

• Datetime-Sidecar. Die vier TOML-Datetime-Typen (mit/ohne Zeitzone, nur Datum, nur Uhrzeit) bleiben über einen {$type, value}-Wrapper erhalten, beim Rückweg JSON → TOML wird das passende Format wiederhergestellt.
• Comment-Preservation. Wer JSON5 als Ausgabe wählt und den Kommentar-Toggle aktiviert, bekommt TOML-#-Kommentare als //-Zeilen in den passenden JSON5-Positionen wieder.
• Cargo/pyproject-Hinweise. Wenn dein TOML ein Cargo-Manifest oder pyproject.toml ist, blendet der Konverter Sanity-Hinweise ein, Pflichtfelder, unbekannte Schlüssel, ohne die Datei zu blockieren.

Wie funktioniert die Datetime-Fidelity?

TOML 1.0 unterscheidet vier Datetime-Typen, JSON kennt nur Strings. Beispiel: 2026-05-17 ist in TOML ein LocalDate, also „dieser Tag, ohne Zeitzone-Kontext”. 2026-05-17T14:30:00+02:00 ist eine OffsetDateTime, also „dieser Moment in Berliner Sommerzeit”. 14:30:00 ist eine LocalTime, also „diese Uhrzeit, ohne Datum”. Wenn du diese vier Typen ohne Sondermaßnahmen in JSON konvertierst, sind sie alle nur noch Strings, der Unterschied geht verloren, der Rückweg ist nicht mehr eindeutig.

Der Datetime-Sidecar-Toggle löst das. Ist er aktiv, wird jeder Datetime-Wert in ein kleines Wrapper- Objekt verpackt: {"$type":"toml/local-date","value":"2026-05-17"}. JSON-Konsumenten können den Wrapper lesen wenn sie wollen, oder einfach .value rausziehen. Beim Rückweg JSON → TOML erkennt der Konverter das $type-Feld und stellt die korrekte TOML-Syntax wieder her.

Wer den Sidecar nicht braucht, zum Beispiel weil das JSON von Hand gelesen wird oder die Daten in eine Datenbank fließen, die ISO-Strings akzeptiert, deaktiviert den Toggle. Dann werden alle vier Datetime-Typen zu plain ISO-Strings, mit dem Trade-off des Informationsverlusts.

JSON, JSON5 oder YAML: welches Format passt?

JSON ist der Standard und der Default. Für Maschinen-zu-Maschinen-Kommunikation, REST-APIs und Daten-Pipelines ist es die richtige Wahl. Der Output ist bytes-clean, JSON-Spec-konform und in jedem Parser einlesbar.

JSON5 ist eine praktische Erweiterung der JSON-Syntax, die Kommentare, trailing-Kommas und unquoted Object-Keys erlaubt. Viele Build-Tools (TypeScript-tsconfig.json, Babel-Config, Webpack-Config) lesen JSON5 nativ. Wenn du TOML zu JSON5 konvertierst und den Kommentar-Toggle aktivierst, bekommst du eine Datei mit dem gleichen strukturellen Inhalt wie das TOML-Original, plus aller #-Kommentare als //-Kommentare. Praktisch wenn die Datei in einem JSON5-aware Build-Tool weiterlebt.

YAML ist die populärste Alternative zu TOML für Konfigurationsdateien. Wer von TOML zu YAML migrieren will (Kubernetes-Configs, Ansible-Playbooks, GitHub-Actions-Workflows), wählt YAML als Ausgabeformat. Der Konverter strippt automatisch die Datetime-Sidecars, weil YAML die vier Zeitstempel-Typen nicht differenziert, du bekommst plain ISO-Strings im YAML-Output.

Ein Migrations-Tipp: TOML → JSON5 ist verlustfrei (mit Sidecar + Kommentaren). TOML → YAML ist mit Verlust der Datetime-Typen. Wer also „nur kurz YAML sehen will” nutzt YAML, wer wirklich migrieren will, prüft die Datetime-Felder per Hand nach.

Wie helfen die Cargo.toml- und pyproject.toml-Hinweise?

Wenn der Konverter ein [package]-Block (Rust) oder ein [project]-Block (PEP 621) erkennt, blendet er einen Hinweis-Banner ein. Der Banner ist nicht-blockierend, er schreibt dir nicht vor, wie das Manifest aussehen muss, er weist nur auf Auffälligkeiten hin.

Cargo-Hinweise (laut Cargo Manifest Reference):

• Fehlende name oder version im [package]-Block, beide sind Pflicht.
• Falsch typisiertes edition, sollte ein String wie "2021" sein, kein Integer.
• Unbekannte Top-Level-Schlüssel außerhalb der Cargo-Standard-Tabellen ([dependencies], [dev-dependencies], [build-dependencies], [features], [workspace], [bin], [lib], [profile], [patch], [badges]).

pyproject-Hinweise (laut PEP 621):

• Fehlender name im [project]-Block, Pflicht.
• Fehlende version ohne dynamic = ['version']-Eintrag, eines von beiden braucht es.
• Fehlendes requires-python, empfehlenswert, aber nicht Pflicht.
• Unbekannte Top-Level-Schlüssel außerhalb von [project], [build-system], [tool], [dependency-groups].

Der Sinn dieses Features: schneller Sanity-Check beim Schreiben oder Editieren von Manifesten, ohne dass du cargo check oder python -m build --dry-run lokal aufrufen musst. Wenn die Hinweise auftauchen, weißt du sofort, was du übersehen hast.

Wie visualisiert der Hierarchie-Tree die TOML-Struktur?

TOMLs größte UX-Schwäche ist die Lesbarkeit verschachtelter Tabellen. [server.database.replica] liest sich auf den ersten Blick wie drei separate Tabellen, ist aber eine einzige tief geschachtelte Hierarchie. Bei vielen [[products]]-Einträgen verliert man schnell die Übersicht, welcher Wert in welchem Element steht.

Der Hierarchie-Tree im Side-Panel löst das. Sobald TOML geparst ist, zeigt der Tree die komplette Struktur als kollabierbaren Baum mit Typ-Badges: str, int, float, bool, table, aot[] für Array-of-Tables, dt+offset / dt / date / time für die vier Datetime-Typen. Bei aot[] werden die einzelnen Array-Elemente als products[0], products[1] angezeigt, du siehst sofort, welches Element welche Eigenschaft trägt.

Bei langen Strings wird ein Preview gekürzt ("Lorem ipsum..." → "Lorem ipsum dolor sit am…"), damit der Tree übersichtlich bleibt. Bei verschachtelten Tabellen sind die Kinder einklappbar.

Was ist absichtlich nicht gebaut?

• Keine TOML-Validierung gegen vollständige Schemas. Cargo- und pyproject-Hinweise sind Heuristiken, keine vollständige Manifest-Validierung. Wer das braucht, nutzt cargo check oder validate-pyproject lokal. Das Tool ist ein Konverter, kein Linter.
• Kein TOML-Format-Auto-Fix. Key-Sortierung, Tabellen-Gruppierung, Whitespace-Reformat, alles Aufgaben, die ein dedizierter Formatter besser löst. Der Konverter respektiert die Eingabe- Struktur, ändert sie nicht.
• Keine v0.5-Backwards-Compat-Mode. TOML 0.5 hatte einige Quirks (homogene Arrays, andere Datetime- Syntax). Wir parsen v1.0-strikt und reichen tolerante Fehler-Hinweise raus, wer noch eine v0.5- Datei hat, aktualisiert sie zu v1.0 (die Spec ist seit 2021 stabil).
• Kein Server-Side-Big-File-Pipeline. Pure-client bedeutet, dass die Datei lokal verarbeitet wird. Bis ca. 10 MB ist das in jedem modernen Browser unproblematisch. Größere TOML-Dateien existieren in der Praxis fast nie, das ist kein typischer TOML-Use-Case.
• Keine syntax-erhaltende AST-Edit-UI. Wer TOML programmatisch ändert und exakt die ursprüngliche Formatierung erhalten will (z.B. dieselbe Whitespace-Konvention), nutzt einen TOML-Editor wie Taplo lokal. Wir parsen zu einem AST und re-emittieren, Whitespace-Erhaltung ist nicht das Ziel.

Wo finde ich mehr Details?

• TOML 1.0 Spec, die offizielle Spezifikation
• TOML auf Wikipedia, Geschichte und Eigenschaften
• JSON5 Spezifikation, die JSON-Erweiterung mit Kommentaren
• Cargo Manifest Reference, Rust-Manifest
• PEP 621, pyproject.toml-Standard
• validate-pyproject, vollständige PEP-621-Validierung