JSON Converter — JSON to TypeScript, YAML & CSV
Turn JSON samples into useful project artifacts: TypeScript types, YAML configuration, or a CSV file for spreadsheet work.
- Choose TypeScript for a quick starting interface.
- Use YAML when moving data into configuration files.
- Use CSV for arrays of similar records.
This tool runs entirely in your browser. Your JSON is not uploaded, stored, or logged.
From sample payload to project artifact
A real API response is often the fastest way to sketch TypeScript types, seed a YAML config, or export tabular data for a spreadsheet. Convert a validated sample instead of hand-typing nested shapes from memory.
Treat generated TypeScript as a starting point — tighten optional fields, unions, and naming to match your domain. YAML and CSV outputs inherit the structure of the JSON you paste, so clean the sample first.
Generated types are a sketch, not a contract
A type inferred from a single sample claims exactly what that sample contained: every field required, every string a string, every array non-empty. Real APIs return null for optional fields, omit keys entirely, and send a union of shapes from the same endpoint depending on the resource.
So the useful next step is not to paste the output into your codebase unchanged but to ask what the sample did not show: which fields can be absent, which can be null, which numbers arrive as strings. Marking those optional is the difference between types that catch bugs and types that lie about them.
Sample size decides the quality
One response gives you one shape. If an endpoint is polymorphic — a list that returns different item types, or a payload carrying a nested enum — convert two or three representative samples and merge what you learn from them, or the generated type will not tolerate the second case it meets.
For CSV the same logic runs in reverse: rows only make sense for an array of similarly shaped records. Convert a deeply nested payload and you get a column of JSON strings, which is usually the signal that the data wanted a different export altogether.
YAML is not JSON with the punctuation removed
YAML was designed for humans, and its type rules are looser than JSON's. In YAML 1.1 — still what many parsers load — the unquoted words yes, no, on, off, and y are booleans, not strings. A country field holding NO becomes the boolean false, which is why the classic example is Norway's country code.
Numbers carry their own traps: a version like 1.10 collapses to the number 1.1, and a leading zero can read as octal. When converting to YAML, quote anything that looks like a number, boolean, or null but is meant to be text.
CSV wants flat, tabular data
CSV has columns and rows and nothing else, so a nested object has to be flattened or stringified. The common conventions are a dotted key (address.city) or a JSON string in the cell; pick one and stay consistent, because neither round-trips without the same decision on import.
An array of scalars becomes a repeated column or a joined string, an array of objects usually cannot be one row, and mixed shapes produce ragged output. If the JSON is deeply nested, CSV is the wrong target — the structure is telling you so.
Frequently asked questions
Are the generated TypeScript types production-ready?
They are a useful scaffold from a sample. Review optionality, naming, and edge-case values before committing them as your public types.
Does conversion upload my JSON?
No. Conversion runs locally in your browser.
Why did my YAML boolean change to true/false?
YAML 1.1 treats unquoted yes, no, on, off, and y as booleans. A value meant to be text — NO for Norway, for instance — becomes false unless it is quoted. Quote ambiguous strings in the output.