{{ summary.heading }}
{{ summary.primary }}
{{ summary.line }}
{{ badge.label }}
Use a PascalCase name that matches the API payload, config file, event, or fixture.
Choose the TypeScript shape you want to paste into a model, SDK, or test fixture.
Use exported declarations for normal app code; namespace is useful for generated bundle handoffs.
Optional-if-missing is safest for arrays of API records sampled from several responses.
Nullable unions preserve explicit nulls; optional-from-null is useful when null means omitted data.
Arrays are treated as sample collections, so missing keys become optional when that policy is selected.
{{ fileStatus || 'Drop JSON or TXT onto the textarea.' }}
Use this for immutable API responses, generated fixtures, or DTOs.
{{ readonlyFields ? 'On' : 'Off' }}
Leave on for stable reviews; turn off to preserve source object order.
{{ sortProperties ? 'On' : 'Off' }}
Keep strings wide for API data unless repeated status/code samples clearly form a finite domain; format-like values are review notes, not narrower TypeScript types.
Use merge for API lists; tuple is useful for fixed-position arrays.
Prefer unknown for safe generated code; any is available for legacy codebases.
{{ result.typesCode }}
{{ result.guardCode }}
Path Type Status Evidence Copy
{{ row.path }} {{ row.type }} {{ row.status }} {{ row.evidence }}
Level Area Evidence Action Copy
{{ row.level }} {{ row.area }} {{ row.evidence }} {{ row.action }} 
{{ jsonText }}
Tags: Data Format, Devtools
Export to PDF Fullscreen
Customize
Advanced
:

JSON-to-TypeScript conversion turns real JSON samples into typed declarations that can guide application models, API clients, fixtures, and event contracts. The result is most useful when the sample shows the shapes developers actually receive: nested objects, arrays, nulls, strings, numbers, booleans, and keys that appear in only some records.

Type inference from JSON is evidence-based, not a final guarantee. A sample can show that items is an array and that customer.email is a string, but it cannot prove every future status value, optional property, nullable path, or fixed array position. The output should be read as a typed starting point that still needs review against the real data contract.

JSON values flowing through inference into TypeScript declarations and review notes.

Arrays need special attention because a list of objects often represents a collection of examples. A property missing from one item may be optional, while a value that appears as both a string and a number may need a union type or a corrected sample. Fixed-position arrays are different: when each position has meaning, a tuple can describe the shape better than a merged item array.

Generated declarations also do not validate runtime data by themselves. TypeScript helps editors and compilers reason about code, but JSON that arrives from a network call, file, queue, or user input still needs runtime checks when the boundary is untrusted.

How to Use This Tool:

Start with a representative sample, then tune the inference choices that affect optional fields, nulls, arrays, and emitted declaration style.

  1. Set Root type name to a PascalCase name that matches the payload, event, configuration object, or fixture. The summary should show the normalized root name after the sample is parsed.
  2. Choose Declaration style and Emit mode. Interfaces fit extendable object declarations, type aliases fit unions and tuple roots, exported output fits normal app code, and namespace output groups the declarations under one named wrapper.
  3. Select Missing properties before using array samples. Optional when absent is usually safest for collections of API records because it marks keys missing from some sampled objects with ?.
  4. Choose Null handling. Nullable unions preserve explicit null; the optional setting treats null-only fields like omitted data; fallback modes use unknown or any for paths without a non-null example.
  5. Paste Sample JSON, browse a .json, .jsonl, or .txt file, or drop text onto the textarea. A complete JSON value is parsed first; multi-line JSON Lines input is treated as an array of samples.
  6. Open Advanced when the generated shape needs readonly properties, stable sorted keys, literal string unions, tuple inference, or a different fallback type for empty arrays and unsupported edge cases.
  7. Review Generated Types, Runtime Guard, Inference Ledger, Review Notes, and Type Profile. Fix parse errors first, then check optional fields, date-like strings, empty arrays, unsafe integers, and quoted property names before copying code into a project.

Interpreting Results:

The generated declarations reflect the current sample and the selected inference policies. Generated Types is the TypeScript handoff, while Inference Ledger shows which JSON path produced each type, whether the property is required or optional, and how many sampled objects supported that decision.

Review Notes is where false confidence usually shows up. A date-like string remains a string unless your application converts it. A repeated status can be a useful literal union, but open text, emails, URLs, UUIDs, and dates should normally stay wide. An empty array has no item evidence, so its fallback type deserves human review.

  • Use the summary counts to see field count, declaration count, depth, optional fields, and whether the input parsed as JSON or JSON Lines.
  • Use Type Profile to spot unexpected complexity, such as many unions, optional fields, arrays, or deeply nested objects.
  • Use Runtime Guard as a starter check for the root shape only. It is not a full validator for every nested business rule.
  • Compare the output against more than one real sample before treating the declarations as the shared contract.

Technical Details:

JSON values can be objects, arrays, strings, numbers, booleans, or null. TypeScript declarations describe the expected structure that code will use, but they are inferred from evidence rather than discovered from a formal schema. The quality of the declaration therefore depends on how well the sample covers real production shapes.

Object inference starts by collecting observed keys. When several object samples appear in an array, each key is checked across the sampled objects so missing-key policy can decide whether to emit a required property or an optional property. Nested objects receive generated names derived from their parent path, while array item objects use singularized item-style names when possible.

Primitive inference follows JSON kinds. Strings become string unless literal-union inference is selected and the values form a small repeated set that does not look like open text. Numbers become number, booleans become boolean, arrays become merged item arrays or tuples, and null handling depends on the selected policy.

Transformation Core:

Stage Inference rule Review point
Parse input Try one complete JSON value first; when that fails and nonblank lines parse independently, treat the input as JSON Lines samples. Parse errors must be fixed before any generated declaration is meaningful.
Name declarations Normalize the root name to PascalCase and derive nested type names from parent names and property keys. Rename the root when generated names would be too generic for the project.
Infer object fields Collect all observed keys, infer each property value, then apply missing-key, null, readonly, and sort settings. Optional markers should match the real contract, not just the current array sample.
Infer arrays Merge item samples by default; tuple mode emits fixed positions only when all sampled arrays share a length of 1 to 8. Use tuple mode only when positions carry stable meaning.
Build unions Different observed JSON kinds at one path become a TypeScript union, with null included only under nullable handling. Mixed-type unions often need a domain check because they can hide inconsistent upstream data.
Emit code Output interfaces, type aliases, exported declarations, ambient declarations, or a namespace wrapper according to the selected style. The same inferred shape can be emitted in different TypeScript forms for different codebases.

JSON numbers deserve extra caution because many JavaScript and TypeScript workflows use the same double-precision number model. Very large integer identifiers can lose exact integer precision before a declaration ever reaches code. The review notes flag integer samples beyond the usual safe range so identifiers that must round-trip exactly can be reconsidered as strings.

Policy Effects:

Setting Output effect When to verify
Missing properties Controls whether absent keys in object samples become optional, required when observed, or all optional. Arrays assembled from several API responses may show different keys per item.
Null handling Emits | null, optional fields, unknown, or any for null-only evidence. Null can mean explicit empty value, unavailable data, or an omitted field depending on the API.
String inference Keeps strings wide, warns on date-like strings, or emits small repeated literal unions. Open text and identifiers should not become narrow unions by accident.
Array inference Creates merged item arrays or fixed-length tuples. Coordinates, color triples, and compact protocol arrays can be tuples; ordinary lists should be merged arrays.
Fallback type Uses unknown, any, or never when the sample has no concrete item or non-null value. Empty arrays and null-only paths need a broader sample or a manual type decision.

Worked Transformation Path:

For an array containing two order items, one with discount_code missing and another with discount_code: null, Optional when absent plus nullable handling emits an optional property whose type includes null. If Require every observed property is selected instead, the same evidence can make every observed key required, which may be too strict when the sample is a collection of partial records.

Privacy Notes:

Pasted text and selected files are parsed in the browser for this conversion. The generated declarations, guard snippet, ledger tables, review notes, type profile, and JSON payload are created from the current page state. Avoid putting secrets into samples that you plan to copy, export, or share with someone else.

Worked Examples:

An order event with id, type, created_at, customer.email, and an items array should produce Generated Types with a root declaration plus nested customer and item shapes. Review Notes may flag created_at as date-like text because JSON has no native date value.

A JSON Lines paste with three nonblank event records is treated as an array sample when each line parses as JSON. Inference Ledger should show paths that are present in all three records as required under Optional when absent, while paths seen in only one or two records become optional.

A fixed coordinate sample such as [40.7128, -74.0060] works better with tuple inference than merged array inference. Tuple output preserves position-specific types, while merged array output says only that the root is a list of numbers.

A trailing comma, malformed JSON Lines row, or unsupported file type stops useful output. The error message points to the JSON position or JSON Lines row when available; fix that first, then recheck Review Notes before trusting any copied declaration.

FAQ:

Should I use interfaces or type aliases?

Use interfaces when the root and nested values are mainly object shapes that may be extended. Use type aliases when the root can be a union, tuple, primitive, or array, or when your codebase prefers aliases for generated declarations.

Why did a property become optional?

When Optional when absent in array samples is selected, a property becomes optional if it is absent from at least one sampled object in an array. Check Inference Ledger for the present count before deciding whether the field is truly optional.

Why are dates generated as strings?

JSON stores date and date-time values as strings. Keep strings wide and flag date-like values adds a review note for ISO-like values, but the generated TypeScript type stays string unless you manually change it later.

Can JSON Lines be used as a sample set?

Yes. When the input has multiple nonblank lines and each line is valid JSON, the converter treats those lines as array samples and reports JSONL in the summary.

Does the runtime guard replace full validation?

No. The guard is a starter check for the inferred root shape and top-level required fields. It does not replace a schema validator, business-rule validator, or hand-written checks for nested constraints.

Does my JSON sample leave the browser?

The conversion is performed in the browser from the pasted text or selected file. Be careful with secrets if you copy generated artifacts or share the resulting declarations, notes, or payload JSON.

Glossary:

Declaration
A TypeScript interface or type alias that names an inferred JSON shape.
Optional property
A property emitted with ? because the selected policy treats missing or null evidence as optional.
Union type
A TypeScript type that allows more than one value kind, such as string | number or Item | null.
Tuple
A fixed-position array type where each index can have its own meaning and type.
JSON Lines
A text format where each nonblank line is a separate valid JSON value.
Inference Ledger
The result table that records each JSON path, inferred type, required or optional status, and sample evidence.

References: