LLM Structured Outputs. OpenAIs response_format und Anthropics Tool-Use nehmen beide JSON Schema. Nach dem Entwurf willst du meist eine Pydantic-Klasse zum Validieren und Zugreifen in Python. OpenAPI-Client-Generierung. Eine OpenAPI-Spec liefert JSON Schema für Request/Response Bodies; schnellster Weg zu passenden Pydantic-Modellen ohne vollen Codegenerator. Schema → Python Migrationen. System mit JSON-Schema-Validierung soll auf Pydantic umziehen. Schema einfügen, Startklasse, verfeinern. Schnelles Scaffolding. Form im Notebook in JSON skizziert, ein Paste macht daraus ein echtes Model.

Externe $ref (URLs). Lokale Refs auf $defs klappen. patternProperties — TODO-Kommentar. additionalProperties als Schema — TODO-Kommentar. Mehrstufige allOf -Komposition. Einzelnes allOf wird entpackt. Custom Validatoren via pattern — Feld bleibt, Regex weg. Bei Bedarf @field_validator nachreichen.

JSON-Schema → Pydantic

Wandle JSON Schema in Pydantic-v2-Modellcode um, direkt im Browser. Schema einfügen, fertige Python-Klasse erhalten. Nützlich für LLM-Structured-Output.

JSON Schema

Pydantic version

Sample schema

Root class name

Generated Pydantic code

Geben Sie oben eine Eingabe ein, um das Ergebnis zu sehen.

Wozu ist das gut?

JSON Schema und Pydantic sind die beiden Hauptarten, ein strukturiertes Objekt zu beschreiben — JSON Schema ist die Lingua Franca für OpenAPI, LLM Function Calling und Structured Outputs; Pydantic ist Pythons De-facto-Validierungsbibliothek. Oft hast du eines und brauchst das andere. Dieses Tool macht die Umwandlung in eine Richtung: JSON Schema einfügen, Pydantic-Klasse rausziehen.

Wann nützlich

LLM Structured Outputs. OpenAIs response_format und Anthropics Tool-Use nehmen beide JSON Schema. Nach dem Entwurf willst du meist eine Pydantic-Klasse zum Validieren und Zugreifen in Python.
OpenAPI-Client-Generierung. Eine OpenAPI-Spec liefert JSON Schema für Request/Response Bodies; schnellster Weg zu passenden Pydantic-Modellen ohne vollen Codegenerator.
Schema → Python Migrationen. System mit JSON-Schema-Validierung soll auf Pydantic umziehen. Schema einfügen, Startklasse, verfeinern.
Schnelles Scaffolding. Form im Notebook in JSON skizziert, ein Paste macht daraus ein echtes Model.

Was das Tool unterstützt

type: object mit properties + required — verschachtelte BaseModel-Klasse.
type: array mit items — List[X].
Primitive: string → str, integer → int, number → float, boolean → bool, null → None.
format bei String: date-time → datetime, email → EmailStr, uri/url → HttpUrl, uuid → UUID.
enum → Literal[...]; const → Literal[X].
oneOf/anyOf → Union[...]; Null-Variante wird zu Optional[...].
type: ["string", "null"] → Optional[str].
description → Field(..., description=...).
default → Feld-Default.
minimum/maximum/minLength/maxLength → Field(ge=..., le=..., min_length=..., max_length=...).
Ungültige Python-Bezeichner werden saniert; alias= erhält den Original-Wire-Namen. populate_by_name=True wird konfiguriert.
Verschachtelte Objekte werden eigene Klassen, benannt nach Feld oder title.
$defs / definitions kommen als separate Klassen.

Was (noch) nicht

Externe $ref (URLs). Lokale Refs auf $defs klappen.
patternProperties — TODO-Kommentar.
additionalProperties als Schema — TODO-Kommentar.
Mehrstufige allOf-Komposition. Einzelnes allOf wird entpackt.
Custom Validatoren via pattern — Feld bleibt, Regex weg. Bei Bedarf @field_validator nachreichen.

Typische Stolperfallen

Pydantic v2 vs v1. Default ist v2. Bei v1-Codebase umschalten. Großer Unterschied: Field(...) für Required, model_config statt class Config:.
Output ist Startpunkt, nicht Endpunkt. Reviewen, besonders bei Unions und rekursiven Typen.
Namen zählen. „Root class name" steuert die Top-Level-Klasse. Sub-Klassen erben aus title oder Feldnamen.
Required vs Optional in v2. Required ohne Default → .... Optional → None in Optional[T].