JSON to Dart Converter

Root class name:

Use a domain name such as OrderResponse, Account, or CatalogItem.

Serialization style:

Choose standalone mappings or annotations for a build_runner project.

Null safety:

A JSON sample is evidence, not a complete schema; verify required and nullable choices.

Field naming:

JSON keys stay exact in serialization mappings even when Dart field names change.

Representative JSON:

Include several object samples when nullability or mixed-number evidence matters.

Object samples:

Merge array items to expose missing fields, or inspect only the first object.

Mixed numbers:

Emit num or normalize mixed integer and decimal evidence to double.

Generated field order:

Keep alphabetical output for deterministic review, or preserve source order.

{{ values.dart_model_source }}

JSON path	Dart field	Dart type	Copy
{{ row.json_path }}	{{ row.dart_field }}	{{ row.dart_type }}

Priority	Evidence	Next check	Copy
{{ row.priority }}	{{ row.evidence }}	{{ row.action }}

A JSON response shows values that happened to appear in one payload. A Dart model needs stronger decisions: which fields are required, which may be null, how nested objects are named, what type represents each value, and how JSON keys map back to Dart identifiers. Generating a model from a sample is therefore inference, not schema discovery.

A broad sample makes a better draft. If every observed order has a customer name, one payload may suggest a required String; the production API can still omit it in an error response. Several objects can reveal missing keys, explicit nulls, integers mixed with decimals, and arrays whose items do not share one shape.

What JSON samples can and cannot establish for Dart models
Observed JSON	Useful first inference	What still needs confirmation
`42`	`int`	Future decimal values and values beyond Dart or JavaScript integer assumptions
`42` and `42.5`	`num` or `double`, according to policy	Whether the API contract promises one numeric representation
A key missing from one object	A nullable field	Whether absence and explicit `null` have different meanings
An empty array	`List<dynamic>`	The real item type from a non-empty response or formal schema
Conflicting value kinds	`dynamic`	Whether the variation is intentional, versioned, or malformed data

Dart's null safety makes these choices visible in the type. A non-nullable field becomes a required constructor argument; a nullable field receives ?. Marking everything nullable is conservative for uncertain APIs, while observed nullability produces a tighter draft that requires better sample coverage.

Names also cross a language boundary. JSON keys may contain spaces, hyphens, leading digits, or Dart keywords. A model can use a safe lowerCamelCase field while serialization continues to read and write the exact original key. This separation keeps Dart code idiomatic without changing the wire format.

Generated classes should enter a review cycle, not production unchanged. Compare them with API documentation, schemas, fixtures, and failure payloads; add domain validation; then run the project's formatter, analyzer, tests, and serialization round trips.

How to Use This Tool:

Use representative payloads, choose how cautious the generated types should be, and treat every inference note as a review task.

Enter a domain-specific Root class name such as OrderResponse and paste one JSON object or an array containing only object samples.
Choose Serialization style. Manual output includes standalone fromJson and toJson methods; annotation output is intended for a project that already uses generated serialization code.
Set Null safety to observed evidence for a tighter draft, or make every field nullable when the sample is too narrow to support required fields confidently.
Use Merge object samples when an array contains several payload examples. Choose the mixed-number policy and field naming policy only when their defaults do not match the destination codebase.
Review Inference notes and Field mapping before copying the Dart. Fix invalid JSON first; then investigate missing fields, nulls, empty arrays, mixed types, renamed keys, and truncated sample coverage.

Interpreting Results:

The class and field counts describe the generated draft, not the completeness of the API. A low warning count means the supplied sample was internally consistent under the selected policies; it does not prove that unseen production payloads have the same fields and types.

Use Field mapping to confirm that every JSON path reaches the intended Dart field and type. Renamed fields are safe only when manual mappings or annotations continue to use the exact source key. Check collisions carefully when two unusual keys normalize to similar Dart names.

Treat dynamic, nullable fields, empty-array notes, and mixed-number notes as prompts for evidence. The best correction may be a broader sample, a formal schema, or a hand-written domain type rather than a different generation setting.

Technical Details:

JSON supplies six value kinds relevant to inference: object, array, string, number, boolean, and null. Dart models need more structure, so objects become classes, arrays become typed lists, integer-looking numbers become int, decimal numbers become double, and conflicting evidence is merged according to explicit rules.

Transformation Core

JSON sample to Dart model transformation stages
Stage	Input evidence	Dart result
Parse root	One object or a non-empty array containing only objects	One root class; a root array also receives a list typedef
Infer shapes	Nested values and selected array samples	Primitive types, nested classes, and typed lists
Merge evidence	Nulls, missing keys, number variants, and conflicting kinds	Nullable types, `num` or `double`, or `dynamic` with a note
Normalize names	JSON keys, requested root name, nesting, and Dart keywords	Unique class and field identifiers plus exact key mappings
Emit serialization	Manual or annotation policy	Standalone conversion methods or annotated classes and generated-part hooks

For example, two item objects containing {"unit_price": 8} and {"unit_price": 19.95, "note": null} merge into a numeric unitPrice field and a nullable note field. With the default mixed-number policy, the numeric field becomes num; choosing the alternate policy makes it double. The JSON keys remain unit_price and note during serialization.

Rule Core

JSON inference and Dart emission rules
Evidence or policy	Rule	Review consequence
Null or missing field	Mark the merged field nullable.	Confirm whether omission and null carry the same domain meaning.
All-nullable policy	Add `?` to every non-`dynamic` field and omit required constructor markers.	Safer for sparse evidence, but shifts more checks into application code.
Integer plus decimal	Use `num` by default or `double` by selection.	Choose the type expected by downstream arithmetic and API contracts.
Different nonnumeric kinds	Use `dynamic`.	Replace it with a union-like domain design or validation when possible.
Empty array	Use `List<dynamic>`.	Supply a non-empty sample or set the item type manually.
Invalid identifier or keyword	Normalize to a safe field; append `Value` for a Dart keyword and a number for collisions.	Verify the exact JSON key mapping before integration.
Field order	Sort alphabetically for stable diffs or preserve first-observed source order.	Ordering changes generated text, not JSON meaning.

Input and Output Bounds

The source is limited to 100,000 characters, 20 nesting levels, 5,000 sampled values, 1,000 sampled fields, 100 sampled items per array, and 80 generated classes. Generated Dart is limited to 200,000 characters, and at most 24 distinct inference notes are shown before an omitted-note summary is added.

JSON numbers are parsed through the browser's numeric representation. An integer beyond JavaScript's exact integer range produces a warning because its literal value may already have lost precision before a Dart int declaration is emitted.

Limitations and Privacy:

Representative JSON is parsed locally and never executed. Pasted or selected source stays in the browser tab, but copied or downloaded Dart can contain example strings and field names from the payload.

Remove personal data, tokens, and private identifiers before sharing generated code or screenshots.
No sample can prove every production variant, conditional field, pagination envelope, error body, or API version.
Generation does not run the Dart analyzer, formatter, build process, or serialization tests.

References:

RFC 8259: The JavaScript Object Notation Data Interchange Format, RFC Editor, December 2017.
Using JSON, Dart documentation, February 2, 2026.
Effective Dart: Style, Dart documentation.