JSON to Python dataclasses
freeGenerate Python dataclasses, TypedDicts, or Pydantic models from JSON.
from __future__ import annotations
from dataclasses import dataclass
from typing import Any
from datetime import datetime
from uuid import UUID
@dataclass
class Root:
id: UUID
name: str
email: str
age: int
bio: Any
address: Address
tags: list[str]
createdAt: datetime
verified: bool
@dataclass
class Address:
street: str
city: str
country: str
postalCode: str
Generate Python type definitions from any JSON sample. Three model styles to match your codebase: stdlib `@dataclass` (zero dependencies), `TypedDict` (lightweight, dict-shaped), or Pydantic v2 `BaseModel` (runtime validation + serialization). String formats — `date-time`, `date`, `uuid` — are mapped to their stdlib types so you don't have to re-parse.
Common use cases
- FastAPI request/response models. Pick the Pydantic v2 flavour and use the output directly as FastAPI route signatures. The detected formats (`datetime`, `UUID`) become Pydantic's built-in validators automatically.
- Stricter `dict` typing in existing code. Use TypedDict to retrofit type hints onto code that already passes dictionaries around. Zero runtime cost, full mypy coverage.
- Data class for API SDKs. Pick `@dataclass` for a lightweight client-side representation — easy to construct, serialize back with `asdict()`, no extra deps.
- Configuration parsing. Generate from your `config.json`, then use Pydantic's `model_validate_json()` to get validated config objects with clear error messages.
Frequently asked
What's the difference between dataclass, TypedDict, and Pydantic?
Dataclass: stdlib classes with `__init__` and field defaults — no validation. TypedDict: structural type hints for dicts — no runtime behaviour. Pydantic: classes with runtime validation, serialization, and JSON schema generation — needs the pydantic package installed.
Should I enable `slots=True`?
For dataclasses with many instances, `slots=True` cuts memory usage by ~20% and slightly speeds up attribute access. Trade-off: you can't add arbitrary attributes after construction. Reasonable default for data-shaped classes.
Why are optional fields grouped at the bottom of dataclasses?
Python dataclasses require fields with defaults to come after fields without — the emitter respects that. Optional and nullable-required fields all default to `None`.
How does Pydantic v2 differ from v1?
v2 is significantly faster (built on Rust) and uses `model_validate` / `model_dump` instead of v1's `parse_obj` / `dict()`. The emitted models work on v2; older v1 codebases need minor method-name updates.
Why do I see `from __future__ import annotations`?
This delays evaluation of type hints to runtime — required for forward references between dataclasses where one type references another defined later in the file. It's been the recommended default since Python 3.10.
Can I generate `attrs` classes instead?
Not yet — currently dataclass, TypedDict, and Pydantic. attrs is structurally similar to dataclass; you can usually rename `@dataclass` to `@attrs.define` and adjust defaults.