JSON naar TypeScript: interfaces en types genereren (gids 2026)

De snelste route van JSON naar TypeScript is je payload plakken in een JSON naar TypeScript Omzetter en de interface kopiëren die hij genereert — niets installeren, niets uploaden, klaar in je browser. Dat dekt het geval “ik heb nu types nodig”.

Maar types genereren en goede types genereren is niet hetzelfde. Een omzetter moet gokken: is dit veld optioneel of ontbreekt het gewoon in één voorbeeld? Bevat die array altijd strings, of soms ook getallen? Moet de datumstring een Date worden? Deze gids legt uit hoe de inferentie werkt, wanneer je naar interface of type grijpt, en welke valkuilen je tegenkomt bij het omzetten van live API-responses naar types waarop je kunt vertrouwen.

Zo zet je JSON om naar TypeScript

JSON omzetten naar TypeScript kost drie stappen:

1. Plak je JSON. Zet een object, array of ruwe API-response in het invoerveld. De conversie draait direct, volledig aan de clientkant.
2. Stel de uitvoer af. Kies interface of type, geef een rootnaam op zoals User of ApiResponse, schakel het export-sleutelwoord in of uit, en kies ?: of | null voor optionele velden.
3. Kopieer of download. Pak de gegenereerde TypeScript met één klik en plak het direct in je codebase.

Meer is er niet aan de transactionele kant. De JSON naar TypeScript Omzetter leest de invoer, leidt een type-boom af en drukt de definities rechts af — niets verlaat de pagina. De rest van deze gids gaat over het begrijpen van wat er geproduceerd is, zodat je de gevallen kunt corrigeren die hij niet kan raden.

Hoe JSON-types op TypeScript worden afgebeeld

Elke JSON-waarde heeft een TypeScript-tegenhanger. De afbeelding is grotendeels één-op-één:

JSON-waarde	TypeScript-type
"text"	string
42, 3.14	number
true / false	boolean
null	null
[1, 2, 3]	number[]
{ ... }	interface of type

Bij objecten gebeurt het echte werk. Neem een typische REST-userpayload:

{
  "id": 101,
  "name": "Ada Lovelace",
  "email": "ada@example.com",
  "active": true,
  "roles": ["admin", "user"]
}

Een omzetter produceert deze TypeScript-interface uit de JSON:

export interface User {
  id: number;
  name: string;
  email: string;
  active: boolean;
  roles: string[];
}

Elke scalar wordt afgebeeld op zijn primitieve type, en de roles-array wordt string[]. Zet dat in je API-client en je krijgt automatisch aanvullen en compile-time-controles cadeau.

Hoe de omzetter types afleidt

Het interessante deel is het inferentie-algoritme. Vier regels dekken vrijwel alles wat je erin gooit.

Structurele inferentie: één benoemde interface per object

Elke afzonderlijke objectvorm wordt zijn eigen benoemde interface. Geneste objecten klappen niet samen tot inline types — ze worden gelicht naar aparte, gerefereerde definities:

{
  "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;
}

Identieke vormen worden ontdubbeld, zodat twee velden met dezelfde structuur één interface delen in plaats van kopieën te produceren.

Arrays samenvoegen: optionele velden afleiden

Wanneer je een array van objecten doorgeeft, voegt de omzetter ze key voor key samen. Als een key in sommige elementen voorkomt maar niet in andere, wordt hij als optioneel gemarkeerd:

{
  "users": [
    { "id": 1, "nick": "x" },
    { "id": 2 }
  ]
}

export interface Root {
  users: User[];
}

export interface User {
  id: number;
  nick?: string;
}

id zit in elk element en blijft dus verplicht. nick ontbreekt bij de tweede user en wordt daarom nick?: string. Daarom is één enkel voorbeeld zelden genoeg — zie de sectie met valkuilen hieronder.

Union-types voor gemengde arrays

Arrays hoeven niet homogeen te zijn. Wanneer elementen verschillende types hebben, verzamelt de omzetter ze in een union:

{
  "tags": ["a", "b"],
  "meta": [1, "two"]
}

export interface Root {
  tags: string[];
  meta: (string | number)[];
}

tags bestaat uniform uit strings, dus string[]. meta mengt een number en een string, wat (string | number)[] oplevert. Een lege array kan helemaal niet worden afgeleid en valt terug op unknown[] — eerlijk, want er valt niets te leren van nul elementen.

Optioneel vs null: ?: versus | null

Deze lijken op elkaar maar betekenen iets verschillends. Een veld met ?: mag volledig ontbreken in het object. Een veld met type | null is altijd aanwezig maar kan de waarde null bevatten:

{ "score": null }

export interface Root {
  score: number | null;
}

Hier is score aanwezig met een expliciete null, dus heeft het type number | null — de waarde bestaat, hij is alleen null. Vergelijk dat met nick?: string uit het array-voorbeeld, waar de key volledig kan ontbreken. Grijp naar ?: wanneer de API de key kan weglaten, en naar | null wanneer hij de key met een null-waarde stuurt. De meeste omzetters laten je met een schakelaar bepalen hoe dit wordt weergegeven.

interface vs type: welke moet je gebruiken?

Beide kunnen een objectvorm beschrijven. Zo beslis je:

Behoefte	Gebruik
Eenvoudige objectvorm uit JSON	interface
Union (A | B) of intersectie (A & C)	type
Declaration merging / uitbreiden over bestanden heen	interface
Mapped of conditional types	type
Iets nettere foutmeldingen in de editor	interface

Voor data die uit een JSON-object komt, is interface de conventionele keuze en levert het iets fraaiere compilerfouten op. Zodra je een union nodig hebt — bijvoorbeeld een Result die een succes óf een fout is — moet je overschakelen naar een type, omdat interfaces geen unions kunnen uitdrukken:

type ApiResult =
  | { status: "ok"; data: User }
  | { status: "error"; message: string };

Een goede standaard: genereer een interface voor eenvoudige JSON-objecten, en zet om naar een type wanneer de vorm een union of intersectie nodig heeft. Het TypeScript Handbook behandelt de randgevallen als je de volledige vergelijking wilt. Wanneer je een json to typescript type-alias nodig hebt in plaats van een interface, bieden de meeste omzetters één schakelaar om de hele uitvoer om te zetten.

quicktype vs json-to-ts vs online tools vs handmatig

Er is geen enkele beste manier om TypeScript-types te genereren — het hangt af van waar de JSON staat en hoe vaak hij verandert.

Aanpak	Het best voor	Afweging
quicktype	Uitvoer in meerdere talen, runtime-validatiecode genereren	Zwaarder; meer uitvoer dan je vaak nodig hebt
json-to-ts (library)	Build-time codegen ingebouwd in een script of pipeline	Vereist installatie en een Node-toolchain
Browsergebaseerde online tool	Eenmalige conversies, gevoelige payloads, geen installatie	Telkens handmatig plakken
Types met de hand schrijven	Kleine objecten, het typesysteem leren	Bewerkelijk en foutgevoelig op schaal

Kies quicktype wanneer je types in meerdere talen nodig hebt of validators naast de types wilt laten uitstoten. Kies de json-to-ts-library wanneer de conversie in een buildstap thuishoort. Voor een snelle conversie — vooral van een payload met tokens, klant-ID’s of iets dat je liever niet in een externe service plakt — wint een browsertool op privacy en snelheid. Onze JSON naar TypeScript Omzetter draait volledig aan de clientkant: de JSON verlaat de pagina nooit, en er valt niets te installeren of bij te werken.

Types zijn geen validatie: de brug naar runtime-controles

Hier struikelen veel teams over, dus laat ik het helder stellen: TypeScript-types worden bij het compileren gewist en doen niets tijdens runtime. Een gegenereerde interface User controleert niet of een echte API-response eraan voldoet. Stuurt de server id als een string in plaats van een number, dan gelooft TypeScript braaf je type-annotatie terwijl de echte data liegt.

Om TypeScript-types te genereren én ze af te dwingen op live data, koppel je de types aan een runtime-validator:

• zod — definieer eenmalig een schema, leid daaruit het statische type af, en verwerk responses tijdens runtime.
• io-ts — codec-gebaseerde validatie, populair in functionele codebases.
• JSON Schema + Ajv — taalonafhankelijke schema’s die tijdens runtime gevalideerd worden, handig wanneer het contract gedeeld wordt over services heen.

Een veelvoorkomend patroon is om de interface te genereren voor editorondersteuning, en daarna een bijpassend zod-schema te schrijven als de eigenlijke grenscontrole:

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>;

// Throws if the real response doesn't match the schema.
const user = UserSchema.parse(await res.json());

Ga je voor de schema-route, dan loopt onze JSON Schema-validatie-gids stap voor stap door het schrijven en afdwingen van schema’s.

Veelvoorkomende valkuilen bij het typen van JSON

Gegenereerde types zijn een startpunt, geen afgewerkt product. Let op deze.

snake_case vs camelCase. Omzetters houden keys letterlijk aan. Een payload in GitHub-stijl met public_repos produceert public_repos: number, niet publicRepos. Verkiest je codebase camelCase, dan leef je ofwel met de snake_case-types, ofwel voeg je een mappinglaag toe die velden bij binnenkomst hernoemt.

Datumstrings blijven string. Een veld als "2026-06-01T00:00:00Z" krijgt het type string, niet Date. Dat is bewust — JSON heeft geen datumtype, en fout gokken is erger dan eerlijk zijn. De omzetting van string naar Date hoort thuis in je verwerkingslaag, waar jij de controle hebt.

Lekkende any en unknown. Lege arrays worden unknown[] en diep gemengde structuren kunnen verworden tot losse types. Dit zijn geen bugs; het is de omzetter die toegeeft dat hij niet kan afleiden uit onvoldoende data. Maak ze met de hand strakker zodra je de echte vorm kent.

Explosie van diepe nesting. Een zwaar geneste payload genereert een lange keten van kleine interfaces. Dat is meestal prima en leesbaarder dan één gigantisch inline type, maar het loont om vormen plat te slaan die hun eigen naam niet verdienen.

De valstrik van één enkel voorbeeld. Dit is de grote. Optionele velden zijn alleen af te leiden uit meerdere array-elementen — één object kan de omzetter niet vertellen welke keys soms ontbreken. Verzamel eerst een representatieve array van responses. Een JSON Formatter is handig om verschillende voorbeelden naast elkaar te plakken en te bekijken voordat je omzet, en voer je niet-standaard invoer zoals JSONC in, lees dan onze JSON5 en JSONC formatteren-gids — de omzetter heeft strikt geldige JSON nodig.

Veelgestelde vragen

Hoe zet ik JSON om naar een TypeScript-interface?

Plak je JSON in een JSON naar TypeScript Omzetter. Hij leest de invoer in je browser en genereert direct een TypeScript-interface. Klik op Kopiëren om het resultaat te pakken — geen upload, geen account, geen plug-in om te installeren.

Moet ik interface of type gebruiken voor JSON-data?

Gebruik interface voor eenvoudige objectvormen uit JSON — het is conventioneel en geeft iets duidelijkere editorfouten. Schakel over naar type wanneer je een union of intersectie nodig hebt, want interfaces kunnen die niet uitdrukken.

Hoe worden geneste objecten en arrays afgehandeld?

Geneste objecten worden aparte, benoemde interfaces (een address-veld levert een Address-interface op). Arrays van objecten worden key voor key samengevoegd tot één element-interface; arrays met primitieven worden getypeerde arrays zoals string[].

Hoe worden optionele en null-velden getypeerd?

Een key die in sommige array-elementen ontbreekt, wordt als optioneel gemarkeerd (nick?: string). Een key die altijd aanwezig is maar null bevat, krijgt type | null (score: number | null). De twee beschrijven verschillende situaties: afwezig versus aanwezig-maar-null.

Valideren TypeScript-types JSON tijdens runtime?

Nee. TypeScript-types worden bij het compileren gewist en controleren geen data tijdens runtime. Om een echte API-response te valideren, koppel je de gegenereerde types aan een runtime-validator zoals zod, io-ts, of JSON Schema met Ajv.

quicktype vs json-to-ts vs een online omzetter — welke is het best?

quicktype past bij uitvoer in meerdere talen en runtime-validators; de json-to-ts-library past bij build-time codegen; een online omzetter past bij snelle, private, eenmalige conversies zonder installatie. Voor gevoelige payloads houdt een tool aan de clientkant de data van elke server af.

Waarom worden datumstrings getypeerd als string in plaats van Date?

JSON heeft geen datumtype, dus een datum is gewoon een string op de lijn. Het als string typen is eerlijk en stabiel; omzetten naar Date is een beslissing voor je verwerkingslaag, waar jij het formaat en de foutafhandeling beheert.

Is mijn JSON-data privé bij gebruik van een online omzetter?

Met een tool aan de clientkant: ja. De conversie draait volledig in je browser met JavaScript, dus de JSON — inclusief tokens, ID’s en klantgegevens — verlaat de pagina nooit en wordt nooit naar een server gestuurd.