JSON to Dart Model Generator
Generate Dart model classes from JSON with null safety and fromJson/toJson — entirely in your browser. Built for Flutter developers.
- Runs in your browser
- No upload, no tracking
- Free forever
How it works
A JSON-to-Dart generator reads a sample JSON payload and emits matching null-safe Dart model classes for Flutter, with optional fromJson and toJson methods so you can serialize to and from a Map<String, dynamic> without any build step. This tool runs entirely client-side, so your JSON never leaves the page. It is built by JusDB, a managed database operations team, for turning API and database payloads into typed Dart code.
- 1
Paste your JSON
Drop a representative object into the input panel, or click Sample to load an example. The Dart models regenerate as you edit.
- 2
Name the root class
Set the Class name field (default User); nested objects become their own classes named from their JSON keys, and arrays become List<T> fields.
- 3
Pick null safety and serializers
Toggle Null safety to emit nullable fields like String? and int?, and fromJson / toJson to add parse and serialize methods — no build_runner required.
- 4
Copy the models
Copy the generated Dart with one click and drop it into your Flutter project. Nothing is ever uploaded.
Frequently asked questions
- Is my JSON kept private?
- Yes. Dart models are generated locally in your browser with JavaScript. Your JSON never leaves the page, so it is safe for internal API payloads.
- Does it generate fromJson and toJson?
- Yes. Enable the fromJson / toJson option to emit a factory constructor that parses a Map<String, dynamic> and a toJson() method that serializes back to a map.
- What does null safety do here?
- With null safety on, fields are emitted as nullable types (for example String? and int?), matching modern Dart and Flutter null-safe projects. Turn it off for non-null fields.
- Does it handle nested objects?
- Yes. Nested JSON objects become separate Dart classes that are referenced from the parent model, and JSON arrays become List<T> fields.
- Does it need build_runner or json_serializable?
- No. The generated fromJson and toJson are written out as plain Dart methods, so there is no code-generation step, no build_runner and no extra package — just paste the classes into your project.
- Can I name the root class?
- Yes. Set the Class name field (default User) and the root model takes that name, while nested classes are named from their JSON keys in PascalCase. Everything is generated locally in your browser.
Generating reliable Dart models from JSON
A single JSON sample is a snapshot, not a contract. Dart's sound null safety and its split between int and double mean the model you hand-write often diverges from what the API actually returns at runtime. The notes below cover the decisions a generator can't make for you and the traps that surface only in production.
fromJson / toJson and the parsing boundary
The idiomatic pattern is a factory constructor that consumes a Map<String, dynamic> and a toJson() that returns one. Treat that pair as the only place untyped data enters and leaves your model: cast and coerce inside the factory, and everything downstream stays strongly typed. If you keep raw JSON tidy first with the JSON formatter, spotting which keys are actually present becomes far easier before you commit to a shape.
Null safety: required vs nullable is a judgement call
A sample cannot tell you which fields are optional. If a key happens to be present in your example, a generator will mark it non-nullable — but the server may omit it, send null, or add it later. Audit each field against the real API contract: make genuinely guaranteed fields required (or non-nullable with a default), and mark anything uncertain as nullable (String?, int?). Over-trusting one payload is the most common cause of a runtime type-cast crash on the first edge-case response.
int vs double vs num
JSON has one number type; Dart has int and double as distinct subtypes of num. A value that arrives as 10 decodes to int, while 10.5 decodes to double — so a field you typed as double will throw when the server sends a whole number, because an int is not a double in Dart. When a numeric field can be either, type it as num, or coerce explicitly in fromJson with (json['amount'] as num).toDouble(). This is the single trap a JSON sample is least likely to reveal.
Nested objects and lists of models
Nested objects should become their own classes, parsed by calling the child's fromJson inside the parent. Arrays of objects map to List<T> built with (json['items'] as List).map((e) => Item.fromJson(e)).toList(). Decide early whether an empty array and a missing key mean the same thing — defaulting a nullable list to const [] often simplifies UI code. The same modelling discipline carries over to other typed targets like C# records or TypeScript interfaces.
Manual code vs json_serializable and freezed
Hand-written fromJson/toJson has zero dependencies and no build step — ideal for a handful of models or a quick prototype. As the model count grows, json_serializable removes the boilerplate but adds a build_runner step (dart run build_runner build) and generated .g.dart files you must keep in sync. Reach for freezed when you also want immutable classes, value equality, copyWith and union/sealed types; it leans on build_runner too, so adopt it when the safety it buys outweighs the extra tooling.
Generate from the messiest real response you can find — one with nulls, an empty list and a whole number where you expect a decimal — not the clean happy-path example. The fields that break are exactly the ones a tidy sample hides.