Zum Inhalt springen
100% lokal

JSON zu Zod-Schema

Generiere ein Zod-Validierungsschema und TypeScript-Typen aus einem JSON-Beispiel, mit Format- und Enum-Erkennung.

Eingabe
Ausgabe

JSON zu Zod-Schema

Fügen Sie ein JSON-Beispiel ein — eine API-Antwort, eine Konfigurationsdatei, einen Datenbankzeileninhalt — und erhalten Sie ein einsatzbereites Zod-Schema in TypeScript. Typen werden für jedes Feld hergeleitet: primitive Typen werden auf z.string(), z.number() und z.boolean() abgebildet, Array-Felder erhalten den hergeleiteten Elementtyp, und ein Wert, der zwischen Vorkommen variiert, wird zu z.union(). Ein String, der wie eine E-Mail-Adresse, eine URL, eine UUID oder ein ISO-Datum aussieht, erhält den passenden Validierungscode — .email(), .url(), .uuid(), .date() oder .datetime() — anstelle eines einfachen z.string().

Geben Sie ihm ein Array von Objekten mit derselben Form, wie beispielsweise Zeilen von einem Listenendpunkt, und der Generator führt jedes Element zusammen, bevor er das Feld typifiziert: Ein Schlüssel, der in einigen Zeilen fehlt, wird zu .optional(), ein Schlüssel, der manchmal null ist, wird je nach gewählter Einstellung zu .nullable() oder .optional(), und ein Feld, das einen kleinen Wertebereich wiederholt — eine Status- oder Rollenspalte — wird zu einem ordentlichen z.enum() anstelle eines offenen Strings. Aktivieren Sie „Verschachtelte Objekte aufteilen“, um jedes verschachtelte Objekt in seinen eigenen benannten Export zu ziehen, anstatt einen tief verschachtelten Literal zu haben. Aktivieren Sie „Strikte Objekte“, um jeden Schlüssel abzulehnen, den das Beispiel nie gezeigt hat — das ist nützlich zum Abfangen von Tippfehlern und unerwarteten API-Feldern beim Parsieren statt später im Prozess.

Benennen Sie das exportierte Schema so, wie es Ihr Code erwartet, und fügen Sie optional export type X = z.infer<typeof X> direkt darunter hinzu, damit der Laufzeit-Validatorand der Compile-Zeit-Typ aus derselben Quelle stammen und sich nie stillschweigend auseinander entwickeln können.

Alles läuft lokal in Ihrem Browser. Das JSON, das Sie einfügen — API-Antworten mit Token, Benutzerdatensätze, interne Payloads — wird vollständig auf Ihrem Gerät geparst und typifiziert und wird niemals hochgeladen. Fügen Sie ein Beispiel ein, kopieren Sie das generierte Schema in Ihr Projekt und beginnen Sie zu validieren, was Sie parsen.

Häufige Fragen

Wie entscheidet es sich zwischen .optional() und .nullable()?
Ein Schlüssel, der in einigen Array-Beispielen fehlt, ist immer .optional() — es gibt keine andere Möglichkeit, einen fehlenden Schlüssel zu erlauben. Ein Schlüssel, der vorhanden ist, aber manchmal null ist, ist mehrdeutig, daher entscheidet die Option „Null-Behandlung“: nullable tippt es genau mit .nullable(), optional behandelt einen null-Wert wie einen fehlenden.
Wie werden verschachtelte Objekte behandelt?
Standardmäßig wird ein verschachteltes Objekt inline typifiziert, genau dort, wo es erscheint. Aktivieren Sie „Verschachtelte Objekte aufteilen“, um jeder verschachtelten Form ihren eigenen export const ...Schema zu geben, und identische Formen teilen automatisch ein Schema anstatt es zu duplizieren.
Wann wird ein Feld z.enum() statt z.string()?
Wenn „Enums erkennen“ aktiviert ist und ein Feld einen kleinen Satz unterschiedlicher Stringwerte — 2 bis 5 — über ein Array von Beispielen wiederholt, wie eine Status- oder Kategoriespalte. Ein Feld mit nur eindeutigen Werten oder zu vielen unterschiedlichen Werten bleibt z.string().
Was macht die Option „Strikte Objekte“?
Sie fügt .strict() zu jedem generierten z.object() hinzu, sodass das Parsen fehlschlägt, wenn die Eingabe einen Schlüssel enthält, den das Beispiel nie gezeigt hat — nützlich zum Abfangen von Tippfehlern oder unerwarteten API-Ergänzungen, anstatt sie stumm zu ignorieren.
Wird mein JSON irgendwo hochgeladen?
Nein. Das Schema wird vollständig in Ihrem Browser generiert — Ihr JSON verlässt Ihr Gerät niemals.