JSON to Dart

Why generate Dart classes from a sample?

Dart's null safety is a contract, and JSON APIs break it for a living: a key that is present in nine responses and absent in the tenth will crash a model class that declared it non-nullable. Getting the classes right means reading the sample for exactly that evidence — which keys come and go, which ones turn null, which number slots ever show a fraction — and transcribing it into camelCase fields and constructor parameters without losing the original key names. That transcription is mechanical, and the sample already contains every fact it needs. This converter does it: objects become classes with final fields, absence becomes a ? and a seat outside the constructor's required list, and every slot that had to become dynamic is reported with its reason.

How to use this tool

1. Paste the JSON. A real API response is ideal; include several array elements if you have them, because absence across elements is how nullable fields are discovered.
2. Name the root class. Root is fine for a quick look; for code you will keep, use the name it will wear in your project.
3. Press Generate Dart. The root class comes first, the classes it references after it.
4. Read the notes if any appear. They list every dynamic slot, every keyword escape and every name collision — nothing was decided silently.
5. Copy or download the result, then add your serialization: hand-written fromJson using the key comments, or annotations for your code generator of choice.

The rules it follows

Numbers. Whole numbers become int; any fraction widens the slot to double — a JSON 1.0 is the number 1 to every parser, so a field your API always sends as 2.0 reads as an integer sample unless a real fraction appears. Names. Classes are PascalCase after the key that holds them; fields are camelCase, with the original JSON key kept in a trailing comment whenever camelCasing changes the spelling (a Dart keyword gains an underscore instead). Absence and null. Missing from some elements or sometimes null → a nullable type, and the constructor parameter leaves the required set. Null everywhere or genuinely mixed types → dynamic, always noted. Merging. Identical shapes — same keys, same types — share one class instead of being emitted twice.

Worked example

Given this sample (the second user has no nickname):

{
  "teamName": "Platform",
  "users": [
    { "id": 1, "firstName": "Ada", "nickname": "ada" },
    { "id": 2, "firstName": "Grace" }
  ]
}

the converter emits:

class Root {
  final String teamName;
  final List<User> users;

  const Root({required this.teamName, required this.users});
}

class User {
  final int id;
  final String firstName;
  final String? nickname;

  const User({required this.id, required this.firstName, this.nickname});
}

The question mark and the missing required are the same fact seen twice: the second user proves nickname is sometimes absent, so the type admits null and the constructor does not demand it.