JSON to Pydantic Converter

Generate a Python Pydantic BaseModel class from a JSON sample — infers types, nested models, lists, and Optional fields.

Root model nameUse X | None instead of Optional[X]

JSON input

Drop a JSON file or click to browseLoads it into the input below

or drop a file here

Pydantic model

from typing import Optional
from pydantic import BaseModel, Field


class Address(BaseModel):
    street: str
    city: str
    zip_code: str


class Order(BaseModel):
    order_id: int
    total: float
    shipped: bool


class RootModel(BaseModel):
    id_: int = Field(alias="id")
    name: str
    email: str
    is_active: bool
    balance: float
    signup_ip: None = None
    tags: list[str]
    address: Address
    orders: list[Order]

How JSON to Pydantic conversion works

Pydantic (v2) uses type-annotated classes that subclass BaseModel to validate and parse data — the same shape FastAPI request/response bodies use. This tool walks your JSON sample and infers a matching model: strings become str, whole numbers become int, decimals become float, booleans become bool, arrays become list[...], and nested objects become their own named BaseModel classes (capitalized from the parent key, singularized for list items — e.g. an "orders" array of objects produces an Order model).

Fields that are null in the sample, or that are missing from some array items, are wrapped in Optional[...] (or X | None if you enable the modern union syntax) with a default of None. Keys that aren't valid Python identifiers — reserved words, names starting with a digit, or non-alphanumeric characters — are renamed and mapped back to the original JSON key with Field(alias="..."), so Model.model_validate(json_data) still round-trips correctly. Everything runs locally in your browser; nothing is uploaded.

Built and maintained by Meet Shah · Last updated 1 August 2026

What this tool is used for

Generating a BaseModel from an API response instead of typing the fields out.
Producing a validated model for an endpoint with no published schema.
Getting nested models generated for a deeply structured payload.
Creating models for a fixture that match production shapes.
Seeing which fields a sample suggests should be Optional.

Frequently Asked Questions

How do JSON types map to Pydantic fields?: Strings to `str`, whole numbers to `int`, fractional to `float`, booleans to `bool`, arrays to `List[T]` and nested objects to their own model. A null gives no type information and becomes `Optional`.
What does Pydantic add over a dataclass?: Validation and coercion at construction — a dataclass records types and enforces nothing at runtime. That is the whole point in an API boundary, where the input is untrusted.
How do I handle a JSON key that is not a valid Python name?: With an alias — declare the field with a Python-safe name and set `alias` to the wire name. That is also how you bridge camelCase JSON to snake_case Python cleanly.
What changed in Pydantic v2?: The core was rewritten in Rust and much of the API moved — `parse_obj` became `model_validate`, `Config` became `model_config`, and validators use new decorators. Generated v1 code does not run unchanged on v2.
Should optional fields default to None?: Only where absent genuinely means "unknown". Giving everything a default makes a required field silently optional, which is exactly the class of bug validation is there to catch.

Common errors and gotchas

Accepting inferred Optional fields, which one sample cannot determine reliably.
Letting a whole number become int when another response returns a float.
Assuming validation is free, since Pydantic will now reject payloads the old code accepted.
Shipping generated model names derived from keys, which rarely read idiomatically.
Mixing Pydantic v1 and v2 syntax, where validators and config differ substantially.