JSON to Dart Converter

How JSON to Dart conversion actually works

When your Flutter app talks to a backend, the backend sends data as JSON. JSON is easy for the server to produce but awkward for a strongly typed language like Dart to consume — you cannot write user.name against a raw Map<String, dynamic> without losing the compiler's help. Converting JSON into a Dart class gives you real types, autocomplete, and compile-time checks.

Each class needs two methods: fromJson (takes a Map and produces an instance) and toJson (takes an instance and produces a Map). Writing these by hand for a single model is manageable. For an app with 15 models, most of which have nested objects and lists, it becomes a multi-hour chore where a single missed null check causes a runtime crash in production.

This tool does that conversion for you — with correct null safety, nested class generation, and list handling — in one click.

How this tool helps Flutter beginners

Nested objects and lists

This is where hand-written code breaks most often. Take this sample:

{
  "id": 1,
  "name": "Alice",
  "profile": {
    "age": 28,
    "city": "Berlin"
  },
  "orders": [
    { "id": "o_1", "total": 49.99 }
  ]
}

The generated Dart file contains three classes:

• User — the root, with typed fields for id, name, profile (typed as UserProfile), and orders (typed as List<UserOrder>).
• UserProfile — the nested object, with age and city.
• UserOrder — the list item, with id and total.

Each class has its own fromJson/toJson, and the parent's fromJson correctly calls UserProfile.fromJson on the nested map and UserOrder.fromJson on each element of the list.

Common mistakes when writing models by hand

• Casting to String when the API sometimes returns int. JSON does not distinguish types the way Dart does — a field that is usually "42" can occasionally be 42 if the backend serialises it inconsistently. This tool casts integers and doubles through num so the parse never throws.
• Forgetting required on non-nullable constructor params. Without required, Dart rejects the constructor when a non-nullable field is present. The generated constructor includes required exactly where it is needed.
• Marking every field nullable to "be safe". This defeats the point of typed models. Nullable marks should reflect fields the API can actually return as null. Use a sample with real values to determine which fields are optional.
• Not handling nested toJson. A common bug is writing return { 'profile': profile } where profile is a class instance — Dart will throw when it tries to JSON-encode a non-primitive. This tool emits profile?.toJson() and orders.map((e) => e.toJson()).toList() automatically.
• Forgetting to regenerate when the API changes. When a new field appears in the API, the hand-written model silently drops it during fromJson. Regenerate whenever your sample JSON changes — it takes 3 seconds with this tool.

Using the generated file in your Flutter project

Save the generated code as lib/models/user.dart (or wherever your project keeps models). Then in your repository or service layer, parse the response:

import 'dart:convert';
import 'models/user.dart';

Future<User> fetchUser(String url) async {
  final response = await http.get(Uri.parse(url));
  final json = jsonDecode(response.body) as Map<String, dynamic>;
  return User.fromJson(json);
}

For lists, User.listFromJson(jsonDecode(response.body) as List) would work if you generate a list at the root — this tool includes that pattern when your root is an array.

When to use json_serializable instead

This tool has an option to add json_serializable annotations. That is the right choice when your models have custom types (dates, enums, value objects) that you want to annotate with @JsonKey(fromJson:, toJson:) or custom JsonConverter classes. The generated code becomes much shorter — fromJson and toJson delegate to _$UserFromJson and _$UserToJson, and you run flutter pub run build_runner build to produce the actual logic.

If you do not want to add a build step, leave the checkbox off — you get a fully self-contained file that compiles without any dependency on json_serializable.

Things this tool does not do

• Detect DateTime fields. Dates arrive as Strings or epoch integers. After generating, change the field type and update fromJson to DateTime.parse(...).
• Detect enums. A string like "active" is generated as String. If your API has a fixed set of values, replace it with an enum and add a small helper for parsing.
• Infer types from a sample where every value is null. If a field is null in your sample, the tool uses dynamic. Paste a sample with a real value, or type the field manually after generating.
• Handle Map<String, dynamic> as a field. Dictionary-shaped fields generate as dynamic. Cast them manually if you know the value type.