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