JSON to Dart Converter

Three Real Quirks to Check Before Trusting the Output

This converter infers Dart types entirely from the sample JSON you paste — it has no schema to fall back on, so the quality of the generated model is only as good as how representative your sample is. Three specific behaviors are worth understanding before you paste generated code straight into a Flutter project:

1. Nested Class Names Come Only From the Field Name — Duplicates Will Collide

When the converter hits a nested object, it names the generated class after the PascalCase version of that field's key — not the full path to it. That means if your JSON has both "billingAddress": {...} and "shippingAddress": {...}, you get two distinctly-named classes (BillingAddress, ShippingAddress) — fine. But if two different objects in your JSON both happen to use the same field name at different nesting levels — say "user": {"address": {...}} and, separately, "warehouse": {"address": {...}} — both generate a class literally named Address, and the second declaration will collide with the first in the same output file. Also worth knowing: array-of-object fields get the class named after the plural field itself, with no singularization — a "items": [{...}] field produces class Items {} and List<Items> items, not the more idiomatic Item. Rename colliding or awkwardly-pluralized generated classes by hand after conversion.

2. A Null Sample Value Can Generate Invalid dynamic?? Syntax

If a field's value in your sample JSON is literally null and Null Safety is checked, the type inference returns dynamic? for that field already — but the class-field and copyWith generators then append another ? on top of it, producing invalid Dart like final dynamic?? someField;, which won't compile. This only triggers on fields whose sample value is exactly null — if you can, edit your sample JSON to include a real, non-null example value for every field before converting (e.g. an empty string instead of null, or a representative number) to avoid hitting this, or manually fix the double question mark in the rare fields where a null placeholder is unavoidable.

3. Number and Array Types Are Guessed From a Single Sample Value

• • int vs double depends on how JSON.parse sees the number, not how you wrote it: a price field written as "price": 19.0 in your sample JSON gets parsed to the JavaScript number 19 (JavaScript doesn't distinguish 19 from 19.0), and Number.isInteger(19) is true — so it's typed int, not double. If a real API response could later send a fractional value for that field, change the sample to something like 19.99 before converting so the generator correctly infers double.
• • Array element type comes from element zero only: for a list field, the converter looks at value[0] to decide the whole list's Dart type. A mixed-type array, or one whose first element isn't representative of the rest, will produce a List<T> that's wrong for some elements. An empty array in your sample always becomes List<dynamic> regardless of what the field will actually hold in production.

A Note on the copyWith and Equatable Options

The copyWith method's parameters are always generated as nullable (Type? name) so callers can omit fields they don't want to change — this happens regardless of whether the "Null Safety" checkbox is on, so if you disable Null Safety but enable copyWith, the output will still contain null-safety-only ? syntax that requires a null-safe Dart environment to compile. And checking "Use Equatable" adds an import 'package:equatable/equatable.dart'; line at the top of the output — remember that package has to actually be added to your project's pubspec.yaml dependencies before the generated code will build.

Frequently Asked Questions