JSON zu TypeScript: Interfaces und Typen generieren (Guide 2026)
Der schnellste Weg von JSON zu TypeScript: Fügen Sie Ihre Payload in einen JSON zu TypeScript Konverter ein und kopieren Sie das generierte Interface. Keine Installation, kein Upload, fertig in Ihrem Browser. Damit ist der Fall „Ich brauche jetzt sofort Typen“ abgedeckt.
Doch Typen zu generieren und gute Typen zu generieren sind zwei verschiedene Dinge. Ein Konverter muss raten: Ist dieses Feld optional oder fehlt es nur in einem Sample? Enthält dieses Array immer Strings, oder manchmal auch Zahlen? Soll der Datums-String zu einem Date werden? Dieser Guide zeigt, wie die Inferenz tatsächlich funktioniert, wann Sie zu interface und wann zu type greifen und welche echten Fallstricke entstehen, wenn Sie Live-API-Antworten in Typen verwandeln, denen Sie vertrauen können.
So wandeln Sie JSON in TypeScript um
Die Umwandlung von JSON in TypeScript erfolgt in drei Schritten:
- JSON einfügen. Geben Sie ein Objekt, ein Array oder eine rohe API-Antwort in das Eingabefeld ein. Die Umwandlung läuft sofort und vollständig clientseitig.
- Ausgabe anpassen. Wählen Sie
interfaceodertype, legen Sie einen Root-Namen wieUseroderApiResponsefest, schalten Sie das Schlüsselwortexportein oder aus und entscheiden Sie sich für?:oder| nullbei optionalen Feldern. - Kopieren oder herunterladen. Übernehmen Sie das generierte TypeScript mit einem Klick und fügen Sie es direkt in Ihre Codebasis ein.
Das war der transaktionale Weg. Der JSON zu TypeScript Konverter liest die Eingabe, leitet einen Typbaum ab und gibt rechts die Definitionen aus. Nichts verlässt die Seite. Im Rest dieses Guides geht es darum zu verstehen, was er produziert hat, damit Sie die Fälle korrigieren können, die er nicht erraten kann.
Wie JSON-Typen auf TypeScript abgebildet werden
Jeder JSON-Wert hat ein TypeScript-Pendant. Die Zuordnung ist meist eins zu eins:
| JSON-Wert | TypeScript-Typ |
|---|---|
"text" | string |
42, 3.14 | number |
true / false | boolean |
null | null |
[1, 2, 3] | number[] |
{ ... } | interface oder type |
Bei Objekten wird es interessant. Nehmen wir eine typische REST-User-Payload:
{
"id": 101,
"name": "Ada Lovelace",
"email": "ada@example.com",
"active": true,
"roles": ["admin", "user"]
}
Ein Konverter erzeugt aus diesem JSON das folgende TypeScript-Interface:
export interface User {
id: number;
name: string;
email: string;
active: boolean;
roles: string[];
}
Jeder Skalar wird auf seinen primitiven Typ abgebildet, und das roles-Array wird zu string[]. Fügen Sie das in Ihren API-Client ein, und Sie erhalten Autovervollständigung und Prüfungen zur Kompilierzeit gratis dazu.
Wie der Konverter Typen ableitet
Der spannende Teil ist der Inferenzalgorithmus. Vier Regeln decken nahezu jede Eingabe ab.
Strukturelle Inferenz: ein benanntes Interface pro Objekt
Jede eigenständige Objektform wird zu ihrem eigenen benannten Interface. Verschachtelte Objekte verschmelzen nicht zu Inline-Typen — sie werden in separate, referenzierte Definitionen herausgehoben:
{
"order": {
"id": "A-1",
"total": 42.5,
"customer": { "name": "Sam", "vip": false }
}
}
export interface Root {
order: Order;
}
export interface Order {
id: string;
total: number;
customer: Customer;
}
export interface Customer {
name: string;
vip: boolean;
}
Identische Formen werden dedupliziert, sodass sich zwei Felder mit derselben Struktur ein einziges Interface teilen, statt Kopien zu erzeugen.
Array-Zusammenführung: optionale Felder ableiten
Wenn Sie ein Array von Objekten übergeben, führt der Konverter sie Schlüssel für Schlüssel zusammen. Erscheint ein Schlüssel in manchen Elementen, in anderen aber nicht, wird er als optional markiert:
{
"users": [
{ "id": 1, "nick": "x" },
{ "id": 2 }
]
}
export interface Root {
users: User[];
}
export interface User {
id: number;
nick?: string;
}
id steckt in jedem Element, bleibt also erforderlich. nick fehlt beim zweiten User, wird also zu nick?: string. Genau deshalb reicht ein einzelnes Sample selten aus — siehe den Abschnitt zu den Fallstricken weiter unten.
Union-Typen für gemischte Arrays
Arrays müssen nicht homogen sein. Wenn Elemente unterschiedliche Typen haben, fasst der Konverter sie in einer Union zusammen:
{
"tags": ["a", "b"],
"meta": [1, "two"]
}
export interface Root {
tags: string[];
meta: (string | number)[];
}
tags besteht einheitlich aus Strings, also string[]. meta mischt eine Zahl und einen String und ergibt (string | number)[]. Ein leeres Array lässt sich überhaupt nicht ableiten und fällt auf unknown[] zurück. Das ist ehrlich, denn aus null Elementen gibt es nichts zu lernen.
Optional vs. null: ?: versus | null
Diese sehen ähnlich aus, bedeuten aber Unterschiedliches. Ein mit ?: markiertes Feld kann im Objekt vollständig fehlen. Ein mit | null typisiertes Feld ist immer vorhanden, kann aber den Wert null enthalten:
{ "score": null }
export interface Root {
score: number | null;
}
Hier ist score mit einem expliziten null vorhanden und wird daher als number | null typisiert. Der Wert existiert, er ist nur null. Stellen Sie das dem nick?: string aus dem Array-Beispiel gegenüber, bei dem der Schlüssel komplett fehlen kann. Greifen Sie zu ?:, wenn die API den Schlüssel weglassen kann, und zu | null, wenn sie den Schlüssel mit einem null-Wert sendet. Die meisten Konverter lassen Sie über einen Schalter steuern, wie dies dargestellt wird.
interface vs. type: Was sollten Sie verwenden?
Beide können eine Objektform beschreiben. So entscheiden Sie:
| Bedarf | Verwenden |
|---|---|
| Einfache Objektform aus JSON | interface |
Union (A | B) oder Intersection (A & C) | type |
| Declaration Merging / dateiübergreifendes Erweitern | interface |
| Mapped oder Conditional Types | type |
| Etwas sauberere Editor-Fehlermeldungen | interface |
Für Daten, die aus einem JSON-Objekt stammen, ist interface die konventionelle Wahl und liefert geringfügig schönere Compiler-Fehler. In dem Moment, in dem Sie eine Union brauchen — etwa ein Result, das entweder ein Erfolg oder ein Fehler ist — müssen Sie auf einen type umsteigen, denn Interfaces können keine Unions ausdrücken:
type ApiResult =
| { status: "ok"; data: User }
| { status: "error"; message: string };
Ein guter Standard: Generieren Sie ein interface für einfache JSON-Objekte und wandeln Sie es in einen type um, sobald die Form eine Union oder Intersection braucht. Das TypeScript Handbook behandelt die Grenzfälle, falls Sie den vollständigen Vergleich wünschen. Wenn Sie statt eines Interface einen json to typescript type-Alias benötigen, bieten die meisten Konverter einen einzigen Schalter, um die gesamte Ausgabe umzustellen.
quicktype vs. json-to-ts vs. Online-Tools vs. manuell
Es gibt keinen einzig besten Weg, TypeScript-Typen zu generieren. Es hängt davon ab, wo das JSON herkommt und wie oft es sich ändert.
| Ansatz | Am besten für | Kompromiss |
|---|---|---|
| quicktype | Ausgabe in mehreren Sprachen, Generierung von Code zur Laufzeitvalidierung | Schwerer; mehr Ausgabe, als Sie oft brauchen |
| json-to-ts (Bibliothek) | Codegen zur Build-Zeit, eingebunden in ein Skript oder eine Pipeline | Erfordert Einrichtung und eine Node-Toolchain |
| Browserbasiertes Online-Tool | Einmalige Umwandlungen, sensible Payloads, keine Installation | Jedes Mal manuelles Einfügen |
| Typen von Hand schreiben | Winzige Objekte, das Typsystem lernen | Mühsam und in großem Umfang fehleranfällig |
Wählen Sie quicktype, wenn Sie Typen in mehreren Sprachen brauchen oder möchten, dass es zusätzlich zu den Typen Validatoren ausgibt. Wählen Sie die json-to-ts-Bibliothek, wenn die Umwandlung in einen Build-Schritt gehört. Für eine schnelle Umwandlung gewinnt ein Browser-Tool bei Datenschutz und Geschwindigkeit, besonders bei einer Payload mit Tokens, Kunden-IDs oder allem, was Sie lieber nicht in einen entfernten Dienst einfügen. Unser JSON zu TypeScript Konverter läuft vollständig clientseitig: Das JSON verlässt nie die Seite, und es gibt nichts zu installieren oder zu aktualisieren.
Typen sind keine Validierung: die Brücke zu Laufzeitprüfungen
Das bringt viele Teams ins Stolpern, daher sei es klar gesagt: TypeScript-Typen werden zur Kompilierzeit gelöscht und tun zur Laufzeit nichts. Ein generiertes interface User prüft nicht, ob eine tatsächliche API-Antwort dazu passt. Sendet der Server id als String statt als Zahl, glaubt TypeScript bereitwillig Ihrer Typannotation, während die echten Daten lügen.
Um generate typescript types und diese auf Live-Daten durchzusetzen, koppeln Sie die Typen mit einem Laufzeitvalidator:
- zod — definieren Sie ein Schema einmal, leiten Sie den statischen Typ daraus ab und parsen Sie Antworten zur Laufzeit.
- io-ts — codecbasierte Validierung, beliebt in funktionalen Codebasen.
- JSON Schema + Ajv — sprachunabhängige Schemas, die zur Laufzeit validiert werden, nützlich, wenn der Vertrag über Services hinweg geteilt wird.
Ein gängiges Muster ist, das Interface für die Editor-Unterstützung zu generieren und dann ein passendes zod-Schema als die eigentliche Grenzprüfung zu schreiben:
import { z } from "zod";
const UserSchema = z.object({
id: z.number(),
name: z.string(),
email: z.string().email(),
active: z.boolean(),
roles: z.array(z.string()),
});
type User = z.infer<typeof UserSchema>;
// Wirft einen Fehler, wenn die echte Antwort nicht zum Schema passt.
const user = UserSchema.parse(await res.json());
Wenn Sie den Schema-Weg gehen, führt Sie unser Guide zur JSON-Schema-Validierung von Anfang bis Ende durch das Schreiben und Durchsetzen von Schemas.
Typische Fallstricke beim Typisieren von JSON
Generierte Typen sind ein Ausgangspunkt, kein fertiges Produkt. Achten Sie auf diese Punkte.
snake_case vs. camelCase. Konverter übernehmen Schlüssel wortwörtlich. Eine Payload im GitHub-Stil mit public_repos ergibt public_repos: number, nicht publicRepos. Wenn Ihre Codebasis camelCase bevorzugt, leben Sie entweder mit den snake_case-Typen oder fügen eine Mapping-Schicht hinzu, die Felder bei der Eingabe umbenennt.
Datums-Strings bleiben string. Ein Feld wie "2026-06-01T00:00:00Z" wird als string typisiert, nicht als Date. Das ist Absicht: JSON hat keinen Datumstyp, und falsch zu raten ist schlimmer, als ehrlich zu sein. Die Umwandlung von String zu Date gehört in Ihre Parsing-Schicht, wo Sie sie kontrollieren.
any- und unknown-Leckage. Leere Arrays werden zu unknown[], und stark gemischte Strukturen können zu losen Typen degradieren. Das sind keine Fehler; es ist das Eingeständnis des Konverters, dass er aus unzureichenden Daten nicht ableiten kann. Ziehen Sie sie von Hand an, sobald Sie die echte Form kennen.
Explosion bei tiefer Verschachtelung. Eine stark verschachtelte Payload erzeugt eine lange Kette kleiner Interfaces. Das ist meist in Ordnung und lesbarer als ein einziger riesiger Inline-Typ, doch es lohnt sich, Formen abzuflachen, die ihren eigenen Namen nicht verdienen.
Die Single-Sample-Falle. Das ist der große Punkt. Optionale Felder lassen sich nur aus mehreren Array-Elementen ableiten. Ein einzelnes Objekt kann dem Konverter nicht sagen, welche Schlüssel manchmal fehlen. Sammeln Sie zuerst ein repräsentatives Array von Antworten. Ein JSON-Formatierer ist praktisch, um mehrere Samples vor der Umwandlung nebeneinander einzufügen und zu prüfen, und falls Sie nicht standardkonforme Eingaben wie JSONC einspeisen, lesen Sie unseren Guide zu JSON5 / JSONC; der Konverter braucht streng gültiges JSON.
Häufig gestellte Fragen
Wie wandle ich JSON in ein TypeScript-Interface um?
Fügen Sie Ihr JSON in einen JSON zu TypeScript Konverter ein. Er liest die Eingabe in Ihrem Browser und generiert sofort ein TypeScript-Interface. Klicken Sie auf Kopieren, um das Ergebnis zu übernehmen. Kein Upload, kein Konto, kein Plugin zum Installieren.
Sollte ich für JSON-Daten interface oder type verwenden?
Verwenden Sie interface für einfache Objektformen aus JSON; das ist konventionell und liefert etwas klarere Editor-Fehler. Wechseln Sie zu type, wenn Sie eine Union oder Intersection brauchen, da Interfaces diese nicht ausdrücken können.
Wie werden verschachtelte Objekte und Arrays behandelt?
Verschachtelte Objekte werden zu separaten, benannten Interfaces (ein address-Feld ergibt ein Address-Interface). Arrays von Objekten werden Schlüssel für Schlüssel zu einem Element-Interface zusammengeführt; primitive Arrays werden zu typisierten Arrays wie string[].
Wie werden optionale und null-Felder typisiert?
Ein Schlüssel, der in manchen Array-Elementen fehlt, wird als optional markiert (nick?: string). Ein Schlüssel, der immer vorhanden ist, aber null enthält, wird mit | null typisiert (score: number | null). Die beiden beschreiben verschiedene Situationen: fehlend versus vorhanden-aber-null.
Validieren TypeScript-Typen JSON zur Laufzeit?
Nein. TypeScript-Typen werden zur Kompilierzeit gelöscht und prüfen keine Daten zur Laufzeit. Um eine tatsächliche API-Antwort zu validieren, koppeln Sie die generierten Typen mit einem Laufzeitvalidator wie zod, io-ts oder JSON Schema mit Ajv.
quicktype vs. json-to-ts vs. ein Online-Konverter — was ist am besten?
quicktype eignet sich für Ausgabe in mehreren Sprachen und Laufzeitvalidatoren; die json-to-ts-Bibliothek eignet sich für Codegen zur Build-Zeit; ein Online-Konverter eignet sich für schnelle, private, einmalige Umwandlungen ohne Installation. Bei sensiblen Payloads hält ein clientseitiges Browser-Tool die Daten von jedem Server fern.
Warum werden Datums-Strings als string statt als Date typisiert?
JSON hat keinen Datumstyp, sodass ein Datum auf der Leitung nur ein String ist. Es als string zu typisieren ist ehrlich und stabil; die Umwandlung in Date ist eine Entscheidung Ihrer Parsing-Schicht, wo Sie Format und Fehlerbehandlung kontrollieren.
Sind meine JSON-Daten bei einem Online-Konverter privat?
Bei einem clientseitigen Tool ja. Die Umwandlung läuft vollständig in Ihrem Browser mit JavaScript, sodass das JSON — einschließlich Tokens, IDs und Kundendaten — nie die Seite verlässt und nie an einen Server gesendet wird.