Have a JSON response or config file and want real Python types for it instead of passing dicts around?
Generate standard-library @dataclass definitions in one click, entirely in your browser.
Json Web Viewer's Types mode reads your document's actual shape — key names, nesting,
array element types, which fields are sometimes missing or null — and generates matching
Python dataclasses. The output uses only the standard library (dataclasses and
typing), so it runs with no pip install. No server round-trip, no account,
no upload.
Field names are converted to Python's snake_case, with a comment noting the original JSON
key wherever the name changed. Nested objects become their own dataclasses, declared below the root —
from __future__ import annotations is emitted so those forward references resolve. And a
field that a dataclass rule would otherwise break on — a default-valued field before a required one is
a TypeError at import time — is ordered correctly, not just prettily.
Example — this JSON:
{
"id": "ord_9f21a",
"customer": {
"name": "Ada Lovelace",
"email": "ada@example.com",
"vip": true
},
"items": [
{ "sku": "book-001", "qty": 2, "price": 19.99 },
{ "sku": "mug-014", "qty": 1, "price": 12.5 }
],
"shippedAt": null
}
generates this Python:
from __future__ import annotations
from dataclasses import dataclass
@dataclass
class Root:
customer: Customer
id: str
items: list[ItemsItem]
shipped_at: None # JSON key: "shippedAt"
@dataclass
class Customer:
email: str
name: str
vip: bool
@dataclass
class ItemsItem:
price: float
qty: int
sku: str
Open this example in the editor →
The link above pre-loads the order example into Types mode. TypeScript is the default
target — select Python from the language dropdown next to the mode buttons to regenerate
the same document as dataclasses.
No. Type generation runs entirely in your browser — your JSON never leaves the page.
A dataclass is standard library, so the generated file runs with no third-party dependency, and it carries real field metadata (defaults, ordering) that a TypedDict cannot express. Pydantic is a better validator, but it splits into incompatible v1/v2 syntaxes and forces a dependency — this tool generates a type, not a validator.
They're kept distinct, because Python can express both: a key absent from some records becomes
Optional[T] = None (constructing without it is legal), while a key that's always present
but sometimes null becomes Optional[T] with no default — still required,
may be None.
Need a different target language? The same dropdown also generates TypeScript, Java, C#, and Kotlin — plus Go and Rust.