Pydantic v2 output
Generate BaseModel classes with built-in collection generics and union syntax.
Start typing to search 227 tools.
Generate Pydantic v2 BaseModel classes from JSON with nested models, Python type hints, nullable options, and Field aliases for JSON keys.
JSON to Pydantic Model creates Pydantic v2 BaseModel classes from sample JSON. Primitive values become Python type hints, nested objects become named child models, and arrays use the first item to infer their item type.
JSON keys that are not safe Python field names are normalized and preserved with Field(alias=...). For example, user-id becomes the Python field user_id with an alias that still accepts the original JSON key. Fields are required by default. The optional setting changes every generated field to a nullable type with a default of None, which is only a broad scaffold and must be adjusted per field.
OrderResponse.Focused controls, predictable output, and a workflow designed around this exact transformation.
Generate BaseModel classes with built-in collection generics and union syntax.
Turn nested JSON objects into reusable named child models.
Preserve JSON keys with hyphens, spaces, leading digits, or Python keywords.
Choose a strict required scaffold or a broad nullable and omittable scaffold.
Practical details about input, output, privacy, limits, and the best way to use this tool.
Yes. It uses BaseModel, built-in list[T] annotations, and T | None optional syntax appropriate for modern Python and Pydantic v2 projects.
Yes. A sample contains observed fields but cannot prove which fields may be absent. Required is the safer deterministic starting point.
It makes every field nullable and supplies a default of None, so every field may be omitted. Review fields individually because nullable and missing are different API states.
They are converted to safe snake_case Python names and preserved with Field(alias="original-key").
A non-empty array uses its first item. Empty arrays become list[Any], and mixed arrays require a manually defined union or discriminated model.
No. JSON represents those semantic values as strings or numbers. Replace basic types with Pydantic types and constraints only when the contract supports them.
The generator wraps it in a field named value so the result remains a BaseModel.
No. Run model validation against valid, missing, null, extra, malformed, and boundary payloads in the exact Python and Pydantic versions used by the application.
Learn JSON objects, arrays, value types, validation, formatting, parsing, API workflows, and common syntax errors.
The nested profile object becomes a child model declared before the root.
Model: User
Optional: off
JSON: {"id":42,"name":"Ada","profile":{"city":"Kyiv","verified":true}}
class UserProfile(BaseModel):\n city: str\n verified: bool\n\nclass User(BaseModel):\n id: int\n name: str\n profile: UserProfile
Safe Python fields use aliases so the original JSON property names remain accepted.
Model: Account
JSON: {"user-id":7,"class":"premium","2fa enabled":true}
class Account(BaseModel):
user_id: int = Field(alias='user-id')
class_: str = Field(alias='class')
field_2fa_enabled: bool = Field(alias='2fa enabled')
The broad optional mode adds both a nullable union and a None default to every field.
Model: SearchResult
Optional: on
JSON: {"title":"Guide","score":0.98}
class SearchResult(BaseModel):\n title: str | None = None\n score: float | None = None
For a root array, the first object becomes the root model sample.
Model: Product
JSON: [{"sku":"A-10","price":19.95}]
class Product(BaseModel):\n sku: str\n price: float
Strings, booleans, integers, and decimal numbers become str, bool, int, and float. Nested objects create child BaseModel classes. Lists use their first item to establish an initial item type. A null sample becomes Any because null alone does not reveal the intended non-null type.
JSON numbers do not carry domain meaning. A value such as 42 may be an identifier, quantity, enum member, bounded integer, or timestamp. Replace primitive annotations with constrained or semantic types based on the real schema.
JSON property names can contain punctuation, spaces, leading digits, or Python keywords. Pydantic fields cannot. The generator creates a safe snake_case field and supplies the original property name through Field(alias=...). This is functional model metadata rather than a comment.
If two JSON keys normalize to the same Python field, a numeric suffix keeps the generated annotations unique and both aliases intact. Review these collisions because the similar names may still indicate an ambiguous source contract.
Required fields have no default. In the optional mode, every field receives a | None annotation and a None default, allowing both omission and null. Real APIs often require a mixture: some fields are required but nullable, some may be omitted, and others require a non-null value.
Edit defaults and annotations per field. Do not treat one global option as a faithful replacement for an OpenAPI or JSON Schema contract.
The generator does not infer validators, computed fields, serializers, configuration, strict types, enums, discriminated unions, aliases chosen by an API, recursive models, formats, numeric ranges, string limits, or extra-field policy. Arrays use only the first item and root empty arrays are rejected because no model fields can be inferred.
Prepare JSON with JSON Formatter, compare TypeScript output with JSON to TypeScript, create a frontend schema with JSON to Zod Schema, or inspect structural rules with JSON Schema Validator.
Review the official Pydantic model documentation and Pydantic field and alias documentation.