Generate Python dataclasses from a YAML document — nested mappings as their own dataclasses in dependency order, sometimes-absent keys as Optional with the dataclass field move reported, stringified non-string keys and Any slots all listed. Your input is never auto-saved: YAML is configuration, and configuration carries secrets. Free, no sign-up — runs locally in your browser.
Why generate Python dataclasses from a YAML sample?
Python programs live on YAML — Ansible inventories, MkDocs and
static-site configuration, ML experiment files, GitHub Actions
workflows read back by tooling — and the hand-written half of
every such reader is a set of classes that transcribe the file
key by key, with the failure mode of silence when a key is
missed or misread. Generating the dataclasses from a real
sample inverts that risk. Every key in the sample gets a field
with the inferred type, nested mappings become their own
dataclasses, sequences of mappings merge into one element
class — and the judgement calls (a key that only sometimes
appears, a field that had to move, a key that had to be
stringified) are written into the notes instead of being
buried in the output.
How to use this tool
- Paste the YAML, upload a file, or drop one on the panel. One document only — multi-document files are refused with an explanation.
- Name the root class.
Config is the default because that is what most YAML pasted here turns out to be. - Press Generate Python dataclasses. Classes are emitted in dependency order, so the file runs top to bottom.
- Read the notes if any appear:
Optional fields, field moves, Any typings, stringified keys and anchor effects are all listed there. - Copy or download, and remember the input was never saved — if you clear the box, the YAML is gone from this tool entirely.
The mapping rules
Mappings become dataclasses, with snake_case
field names and the original key kept in a trailing comment
whenever the spelling changed. Sequences
become List[…], and a sequence of mappings yields
one merged element class. Scalars infer like
JSON: whole numbers int, decimals
float, true/false bool, everything
else str — including dates, which this parser
hands over as strings, so a when: 2024-01-15 field
is a str unless you swap in a date type yourself. A key
missing from some items becomes Optional[…] = None
and moves after the required fields, as dataclasses demand —
the move is noted. Nulls, mixed slots and empty
sequences become Any and are always
noted. Identical shapes share one class.
Worked example
Given this sensor configuration (the second reading has no temp):
station: North Ridge
readings:
- sensor: s1
temp: 21.5
- sensor: s2
the converter emits:
from dataclasses import dataclass
from typing import List, Optional
@dataclass
class Reading:
sensor: str
temp: Optional[float] = None
@dataclass
class Config:
station: str
readings: List[Reading]
The Optional on temp is the second
reading talking: the sample proves the key comes and goes, so
the type says so, with None as the absence value.
Frequently asked questions
Why dataclasses and not TypedDicts or Pydantic models?
Dataclasses are the standard library's shape description: no dependency, no framework lock-in, and the generated file runs as-is on Python 3.7+. A TypedDict would describe the parsed YAML value itself (which is dictionaries all the way down) — if that is what you want, the mapping is one-to-one: every field here is a key there. Pydantic models add validation the sample cannot specify: the sample shows shapes, not constraints, and inventing constraints would be guessing dressed as rigour.
Why did my optional field move to the bottom of the class?
Because Python requires it: a dataclass field with a default value (and Optional fields get '= None') may not be followed by a field without one — the class would fail to define. So optional fields are emitted after the required ones, in their original relative order, and whenever that actually changes the order you wrote, the move is listed in the notes above the result. The YAML order is still visible in the notes; the class order is Python's constraint, not a silent edit.
My YAML has several documents separated by ---. What happens?
The converter refuses, and says how many documents it found. Each document would need its own root class, and quietly generating the first (or merging them) would produce classes that misdescribe your file. Split the documents and convert each one, or name the root per document — that is a modelling decision, so the tool leaves it to you.
I use anchors, aliases and merge keys. Do they survive?
They are resolved before generation: an aliased mapping is seen as the full mapping it points at, and a merge key's entries appear as the fields they contribute, so the generated classes describe the values, not the anchor syntax. If two keys alias mappings with the same shape, they share one class, like any identical shapes. What is lost is the sharing itself — the class cannot say 'these two fields are the same object'. If your program depends on that identity rather than the values, no class generator can express it.
My keys aren't strings — YAML allows that. What happens to them?
Python dataclass fields are named from strings, so a numeric or boolean YAML key is treated as its string spelling (42 becomes "42") and the notes call out every key it happens to. Be aware of one step where this bites: YAML also distinguishes the keys 42 and "42" in the same mapping; the parsed value cannot, so a document using both would collapse them before generation even starts — the notes are where to check if that matters to you.
Why isn't my input auto-saved like on other tools?
Because YAML is usually configuration, and configuration files carry secrets — API keys, tokens, internal hostnames, database passwords. This converter keeps no draft of your input or your root class name, in your browser or anywhere else: paste, convert, done. Refresh the page and it is gone — that is deliberate, and it is the same rule on every YAML tool on this site.
Dev