MSRX Tools

JSON to TypeScript

Generate interfaces from a sample JSON payload.

Everything runs inside your browser. Your files never leave your device.

Input

Result

The result appears here as you type.

Ask about JSON to TypeScript

Questions about what this tool does, which option to pick, or what it can and cannot handle.

The question you type here is sent to an AI provider to be answered — your files and whatever you put in the tool above are not, and the assistant cannot see them. Answers are generated and can be wrong. The tool itself is not guessing: it runs deterministic code on your device.

About the JSON to TypeScript

An API returns JSON and your code needs to know its shape. Writing the interface by hand means reading the payload field by field and getting the optionality right, which is slow and easy to get subtly wrong.

This generates TypeScript interfaces from a sample. Nested objects become their own named interfaces rather than being inlined, so the result reads like something a person would have written, and arrays are inspected across their elements rather than only the first.

That array handling is the part that matters. A response where one item has a null description and the next has a string will produce "string | null" here, not "string" — which is what a first-element-only tool gives you, and which fails at runtime on the second item. Similarly, a key present in some elements and absent in others is marked optional, because that is what the sample actually demonstrates.

The unavoidable limitation is the same one every inference tool has, and it is worth stating rather than burying. A sample shows what came back once. It cannot show that a field is sometimes absent, that an empty array is really an array of orders, or that a string field is actually one of five specific values. Generated types are a starting point that saves the typing, not a specification.

Two places to look before trusting the output: any field that was null in your sample, which will have been typed as null and needs the real type adding; and any empty array, which cannot be inferred at all. Both are quick to fix once you know to look.

The best source of truth remains the API's own schema, if it publishes one. Generating types from an OpenAPI document gives you what the API promises rather than what it happened to send.

How to use it

  1. 1Paste a representative JSON response — a real one, with populated fields.
  2. 2Read the generated interfaces. Nested objects are extracted as their own named types.
  3. 3Fix any field that was null or an empty array in your sample, since neither can be inferred.
  4. 4Mark genuinely optional fields yourself; a sample cannot show that something is sometimes missing.

Questions

Why is a field typed as null?
Because it was null in your sample and there was nothing else to go on. Replace it with the real type, or supply a sample where the field is populated.
How are arrays with mixed elements handled?
Every element is examined and the results are merged, so a field that is a string in one and null in another becomes a union. A key missing from some elements is marked optional.
Should I use generated types directly?
As a starting point. They save the typing and are usually right about shape, but they cannot know about optional fields that happened to be present, or string fields that are really a fixed set of values. Read them before committing them.
What about an empty array in the sample?
It becomes an array of unknown, because there is genuinely no information to work from. Supply a sample with at least one element, or fill the type in by hand.