About this conversion
In this example, the camelCase JSON keys are inferred into Pydantic v2 models: orderId becomes order_id: str = Field(alias="orderId") with model_config = ConfigDict(populate_by_name=True), the nested customer object becomes its own BaseModel class, and the null-valued discountCode becomes Optional[str] = None — so the models parse the original payload as-is.
Key Syntax Transformations
One BaseModel per nested object
Every nested object in the payload becomes its own class inheriting from BaseModel, with names deduplicated and derived from the JSON keys.
snake_case with Field(alias=...)
camelCase keys become idiomatic snake_case fields, and model_config = ConfigDict(populate_by_name=True) lets the models validate the original payload without renaming anything.
Optional[...] = None for nulls
Keys observed as null become Optional[type] = None — the Pydantic convention for values that may be missing from an API response.
datetime and list[...] typing
ISO 8601 date strings are inferred as datetime fields, arrays become list[...] of the item type, and the correct typing imports are emitted for you.
Frequently Asked Questions
Is my JSON uploaded anywhere?
Never. Inference and code generation run entirely in your browser — there is no upload endpoint, nothing is logged, and the page works offline once loaded.
Does the output target Pydantic v1 or v2?
Pydantic v2 — the output uses ConfigDict and modern typing syntax, the patterns current FastAPI applications expect.
Can the models validate my original camelCase payload?
Yes. Renamed fields carry Field(alias="originalKey") and the model sets populate_by_name=True, so both the original JSON keys and the snake_case names validate.
How are date strings handled?
Strings that parse as ISO 8601 dates or timestamps are inferred as datetime fields with the right import; everything else stays str — no silent coercion.