Wann nimm Zod statt einem plain Interface?

Nimm **Zod** (oder Yup, Valibot, ArkType), wenn Daten **von aussen in deine App kommen**: API-Response, Formular, **localStorage**, Query-Parameter. Ein TS-Interface ist **zur Compile-Time geloescht**, stoppt keinen Server, der Muell zurueckgibt. Ein **Zod-Schema laeuft zur Runtime**: `schema.parse(data)` und du kriegst entweder ein typisiertes Objekt oder einen echten Fehler. Mit **`z.infer `** auch den statischen Typ, also **eine Quelle der Wahrheit** fuer Runtime und Compile-Time. Plain Interfaces bleiben gut fuer interne Typen, die keine Grenze ueberschreiten.

Warum macht der Generator fuer jedes verschachtelte Objekt einen eigenen Typ?

**Lesbarkeit und Wiederverwendung.** Inline-Typen verschachteln visuell so: `{ customer: { id: number, name: string, address: { street: string, city: string } } }`, eine Klammernwand. Benannte Typen lassen dich die Struktur scannen: **`Customer`**, **`Address`**, **`Order`**, du siehst sofort, was in den Daten ist. Wiederverwendung gratis: haben zwei Stellen die **gleiche Shape** (z.B. `billingAddress` und `shippingAddress`), erkennt der Generator das **Duplikat** strukturell und nutzt das gleiche **`Address`**-Interface.

Meine API gibt manchmal `null`. Soll ich optional markieren?

Drei Optionen, drei Bedeutungen: - **`field: string`**: Feld ist **immer da, immer String**. Wenn der Contract das garantiert. - **`field: string | null`**: Feld ist **immer da**, Wert kann **`string`** oder **explizit null** sein (wie "noch kein Wert"). Wenn null was bedeutet. - **`field?: string`**: Feld **fehlt manchmal komplett** im Objekt. Wenn die API den Key weglaesst. Der Toggle **"Optional basierend auf null"** gibt dir die dritte Form: nimmt an, **null = fehlend**. Aus, wenn dir der Unterschied **fehlend** vs. **explizit null** wichtig ist (z.B. in JSON Patch oder MongoDB-Updates).

Was macht "aehnliche Shapes mergen" wirklich?

Sagen wir dein JSON ist `[{ "id": 1, "name": "A" }, { "id": 2, "title": "B" }]`. Zwei Objekte, das zweite hat **`title`** wo das erste **`name`** hat. **Merging aus**: Array-Typ wird **`(Item1 | Item2)[]`**, zwei Typen, du musst vor dem Lesen narrown. **Merging an**: du kriegst **einen** **`Item`**-Typ mit **`id: number, name?: string, title?: string`**, beide Felder optional. Merging ist freundlicher fuer echte API-Responses, wo das Backend lazy Felder addiert und alte Records Nulls haben. Permissiver: ist der Unterschied wichtig (verschiedene `type`-Discriminator), Merging aus und Discriminated Union von Hand.

Leeres Array `[]` in JSON: welchen Typ kriege ich?

Ein leeres Array enthaelt **keine Element-Werte**, der Generator **kann den Element-Typ nicht raten**. Per Default **`unknown[]`** (mit "Use `unknown`") oder **`any[]`**. **Wichtig: `any[]` laesst dich jede Methode aufrufen ohne Warnung** (haeufige Runtime-Bug-Quelle); **`unknown[]` zwingt dich zum Narrowing** (`if (typeof x === "string")`). **Tipp**: kennst du den Element-Typ, aber das Sample-JSON hat zufaellig ein leeres Array, **bearbeite den Typ nach Generierung von Hand** (`Tag[]` statt `unknown[]`), oder **paste ein reicheres Sample** mit mindestens einem Element.

Wie stecke ich den Zod-Output in ein existierendes Formular?

Drei Zeilen oben drauf: ```ts import { useForm } from 'react-hook-form'; import { zodResolver } from '@hookform/resolvers/zod'; import { rootSchema, type Root } from './generated'; const { register, handleSubmit, formState } = useForm ({ resolver: zodResolver(rootSchema), }); ``` Du kriegst **Validierungsfehler automatisch** (kein "name must be a string"-Boilerplate) und **typisierte Form-Werte** gratis.

Mein JSON hat doppelte Keys mit verschiedenen Typen. Woher?

JSON erlaubt keine doppelten Keys auf gleicher Ebene (der Parser behaelt den **letzten Wert**), du siehst das nicht direkt. Aber haben **verschiedene Array-Elemente ein Feld mit verschiedenen Typen** (z.B. `[{ "id": 1 }, { "id": "two" }]`), produziert der Generator eine **Union**: **`id: number | string`**. **Meist ein Zeichen, dass deine API messy ist**: id sollte ein Typ sein. Backend fixen, neu generieren. Willst du wirklich beides, sind Unions genau dafuer, der Typ ist korrekt.

Schafft der Generator tief verschachteltes JSON?

Ja. Der Walker ist **depth-first** ohne eingebautes Rekursions-Limit, tief verschachtelte Objekte (10+ Ebenen) generieren sauber. **Eine Sache**: rekursive Strukturen (Baum, wo jeder Node ein Array von Kindern gleichen Typs haelt) werden per Default als **separate Typen pro Ebene** ausgegeben. Willst du einen echten rekursiven Typ (**`type Node = { children: Node[] }`**), passe die Namen nachher an, der Generator kann "das ist derselbe Typ wie der Parent" nicht aus einem JSON-Sample erkennen.

JSON-Schema-Output: welcher Draft und AJV-kompatibel?

Output ist **Draft 2020-12** (neuester stabiler Draft), nutzt **`$defs`** (moderner Ersatz fuer `definitions`) und **`$ref`** fuer geteilte Shapes. **AJV** unterstuetzt 2020-12 ueber **`ajv-2020`**: `import Ajv from "ajv/dist/2020"`. **OpenAPI 3.1 ist kompatibel**, Schema direkt in **`components.schemas`** deiner Spec. **OpenAPI 3.0** nutzt aelteren Flavor (`$defs` zu `definitions` swappen, ein paar Keywords anpassen), einfacher: Spec auf 3.1 upgraden.

JSON zu TypeScript - kostenlos

export interface Customer { id: number; name: string; email: string; verified: boolean; phone?: null; } export interface Item { sku: string; title: string; qty: number; price: number; tags: string[]; } export interface Item2 { sku: string; title: string; qty: number; price: number; tags: unknown[]; } export interface Item3 { sku: string; title: string; qty: number; price: number; tags: string[] | unknown[]; } export interface Totals { subtotal: number; shipping: number; tax: number; grand: number; } export interface Root { id: string; created_at: string; customer: Customer; items: Item3[]; totals: Totals; notes?: null; }

Aus einem JSON-Sample fertige TypeScript-Typen machen

Du hast eine JSON-Response von einer API und brauchst einen TypeScript-Typ dafuer. Jetzt. Ohne jedes Feld von Hand zu tippen, ohne ein verschachteltes Objekt drei Ebenen tief zu vergessen, ohne zu uebersehen, dass das Feld manchmal `null` ist. JSON links pasten, sauberes `interface` rechts bekommen.

Der Generator erkennt verschachtelte Objekte und gibt jedem einen eigenen Typ-Namen. Er laeuft durch Arrays, sucht den Element-Typ und gibt `User[]` statt einer langen Inline-Shape. Sind Keys mal fehlend oder mal null, fuegt er ein `?` dran. Enthaelt dein Array Objekte mit leicht verschiedenen Feldern, mergt er sie zu einer Super-Shape und markiert die Unterschiede als optional.

Vier Output-Formate: ein TypeScript-`interface`, ein TypeScript-`type`-Alias, ein Zod-Runtime-Schema (mit `z.infer` fuer den statischen Typ), oder ein JSON-Schema-Dokument (fuer OpenAPI, AJV, Contract-Tests). Alles im Browser, nichts verlaesst die Maschine.

So nutzt du das Tool

JSON pasten im linken Panel. Das Default-Sample ist eine typische API-Order-Response, damit du den Generator sofort siehst.
Output-Format waehlen: interface (Alltag), type-Alias (fuer Unions oder Mapped Types), Zod (wenn du auch Runtime-Validierung brauchst) oder JSON Schema (fuer OpenAPI und Contract-Tests).
Root-Typ-Namen setzen (Default `Root`). Gute Namen: `User`, `Order`, `ApiResponse`. Der Generator nutzt deinen Namen oben und leitet Child-Namen aus den Keys ab (`customer` -> `Customer`).
`unknown` statt `any` fuer sicherere Typen: leere Arrays werden `unknown[]` statt `any[]`, das Typsystem zwingt dich zum Narrowing vor der Nutzung.
Optional basierend auf null wenn deine API manchmal `"phone": null` schickt: der Generator macht `phone?: string` statt `phone: string | null`. Aus, wenn du explizites null im Typ willst.
Keys zu camelCase wenn dein JSON snake_case nutzt (`created_at`) und dein TS-Code camelCase (`createdAt`). Der Original-Key bleibt im Kommentar.
Aehnliche Shapes mergen wenn ein Array Objekte mit leicht anderen Feldern enthaelt. Aus: verbose Union. An: eine saubere Shape mit `?`-Markern auf den Unterschieden.
Klick `Kopieren` fuers Clipboard oder `Runterladen` als `.ts`-Datei (oder `.json` fuer JSON Schema). In dein Projekt pasten, fertig.

Wann das nuetzlich ist

Fuenf Situationen, in denen das 10 Minuten Tipparbeit spart:

Neuen API-Endpoint anschliessen. Du hittest `/api/orders` und kriegst eine fette JSON-Response. Hier pasten, in drei Sekunden `Order`, `Customer`, `Item` Interfaces. In `types.ts` kippen, dein Code autocomplettet jedes Feld korrekt.
Untypisiertes JavaScript zu TypeScript migrieren. Alter Code liest JSON und ratet die Shape. Ein Beispiel hier pasten, Typen kriegen, oben in die Datei, der Compiler findet jede Stelle, die ein fehlendes oder falsches Feld anfasst.
Zod-Schema fuer ein Formular bauen. Du kennst die Shape (aus einem JSON-Sample), brauchst Runtime-Validierung. Switch zu Zod, kriegst `z.object({...})` mit den richtigen Primitive-Validatoren, in deine Form-Library (React Hook Form, Formik, TanStack Form) packen.
OpenAPI-Spec aus echter Response schreiben. Das Backend gibt schon JSON, du musst es in OpenAPI beschreiben. Switch zu JSON Schema, kriegst Draft-2020-12-Dokument mit `$defs`, in die Response-Section deines Endpoints. Fertig.
Contract mit Frontend-Team teilen. Du hast einen JSON-Payload, musst der anderen Seite sagen, was zu erwarten ist. Interface generieren, in Slack oder Doc, beide Teams haben die gleiche Wahrheit.

Mit echter Spec arbeiten? Nimm OpenAPI zu TypeScript fuer volle Request/Response-Typen oder GraphQL zu TypeScript fuer SDL.

Fragen und Antworten

Fuer reine Objekt-Shapes funktional identisch in TypeScript: beide beschreiben Felder, beide unterstuetzen Autocomplete, beide werden gleich gecheckt. Der Unterschied: `interface` kann erweitert werden (`interface User extends Person`) und dateiuebergreifend gemerged (Declaration Merging). `type` ist flexibler: kann eine Union sein (`type Status = "active" | "off"`), ein Mapped Type, eine Intersection. Fuer den Output ist interface der sicherere Default, das schreiben die meisten Teams von Hand. `type` wenn du gleich danach mit Unions oder Utility-Types kombinieren willst.

Aus einem JSON-Sample fertige TypeScript-Typen machen

So nutzt du das Tool

JSON pasten im linken Panel. Das Default-Sample ist eine typische API-Order-Response, damit du den Generator sofort siehst.

Output-Format waehlen: interface (Alltag), type-Alias (fuer Unions oder Mapped Types), Zod (wenn du auch Runtime-Validierung brauchst) oder JSON Schema (fuer OpenAPI und Contract-Tests).

Root-Typ-Namen setzen (Default `Root`). Gute Namen: `User`, `Order`, `ApiResponse`. Der Generator nutzt deinen Namen oben und leitet Child-Namen aus den Keys ab (`customer` -> `Customer`).

`unknown` statt `any` fuer sicherere Typen: leere Arrays werden `unknown[]` statt `any[]`, das Typsystem zwingt dich zum Narrowing vor der Nutzung.

Optional basierend auf null wenn deine API manchmal `"phone": null` schickt: der Generator macht `phone?: string` statt `phone: string | null`. Aus, wenn du explizites null im Typ willst.

Keys zu camelCase wenn dein JSON snake_case nutzt (`created_at`) und dein TS-Code camelCase (`createdAt`). Der Original-Key bleibt im Kommentar.

Aehnliche Shapes mergen wenn ein Array Objekte mit leicht anderen Feldern enthaelt. Aus: verbose Union. An: eine saubere Shape mit `?`-Markern auf den Unterschieden.

Klick `Kopieren` fuers Clipboard oder `Runterladen` als `.ts`-Datei (oder `.json` fuer JSON Schema). In dein Projekt pasten, fertig.

Wann das nuetzlich ist

Fuenf Situationen, in denen das 10 Minuten Tipparbeit spart:

Neuen API-Endpoint anschliessen. Du hittest `/api/orders` und kriegst eine fette JSON-Response. Hier pasten, in drei Sekunden `Order`, `Customer`, `Item` Interfaces. In `types.ts` kippen, dein Code autocomplettet jedes Feld korrekt.
Untypisiertes JavaScript zu TypeScript migrieren. Alter Code liest JSON und ratet die Shape. Ein Beispiel hier pasten, Typen kriegen, oben in die Datei, der Compiler findet jede Stelle, die ein fehlendes oder falsches Feld anfasst.
Zod-Schema fuer ein Formular bauen. Du kennst die Shape (aus einem JSON-Sample), brauchst Runtime-Validierung. Switch zu Zod, kriegst `z.object({...})` mit den richtigen Primitive-Validatoren, in deine Form-Library (React Hook Form, Formik, TanStack Form) packen.
OpenAPI-Spec aus echter Response schreiben. Das Backend gibt schon JSON, du musst es in OpenAPI beschreiben. Switch zu JSON Schema, kriegst Draft-2020-12-Dokument mit `$defs`, in die Response-Section deines Endpoints. Fertig.
Contract mit Frontend-Team teilen. Du hast einen JSON-Payload, musst der anderen Seite sagen, was zu erwarten ist. Interface generieren, in Slack oder Doc, beide Teams haben die gleiche Wahrheit.

Mit echter Spec arbeiten? Nimm OpenAPI zu TypeScript fuer volle Request/Response-Typen oder GraphQL zu TypeScript fuer SDL.

Fragen und Antworten

JSON zu TypeScript

Aus einem JSON-Sample fertige TypeScript-Typen machen

So nutzt du das Tool

Wann das nuetzlich ist

Fragen und Antworten

Passende Tools

JSON-Formatter

JSON / YAML / TOML Konverter

JSON ↔ CSV Konverter

JSON zu TypeScript

Aus einem JSON-Sample fertige TypeScript-Typen machen

So nutzt du das Tool

Wann das nuetzlich ist

Fragen und Antworten

Passende Tools

JSON-Formatter

JSON / YAML / TOML Konverter

JSON ↔ CSV Konverter