JSON to Dart Converter

How to use this tool

Paste a representative JSON object, choose a class name, and generate. Review inferred fields before adding the code to your project.

Example

Input

{"name":"Ada","address":{"city":"Pune"}}

Output

A model with nullable name and Address fields, fromJson() and toJson().

What does this tool do?

Dart model classes give JSON data named fields and conversion methods. This generator infers types from a sample object and creates classes for nested objects.

Common mistakes and limitations

Samples do not define a complete API schema. Missing or null fields become nullable; empty or mixed lists use dynamic. Dates remain strings. Review generated names and types against real responses.

From a sample object to a model class

A JSON object suggests fields, but one example cannot describe every response the API may return. This generator produces Dart model code with fromJson and toJson methods, including nested object classes and lists where the sample provides enough information. The root must be an object. Name the root class with PascalCase, such as UserModel, while generated field names follow Dart-style naming rather than blindly copying punctuation from JSON keys.

{"id":1,"name":"Asha"}

// Typical use after reviewing the generated class:
final user = UserModel.fromJson(jsonDecode(responseBody));
final payload = jsonEncode(user.toJson());

Null safety needs knowledge of the contract

A field that is present in one sample may be absent or null in another. Review the generated nullability and defaults against the documented API schema. An empty list reveals no element type, while a list mixing strings, numbers and objects needs a broader representation than a homogeneous list. Numeric samples can also hide later decimal values. Automatic inference should start a model, not replace the decisions your type system is meant to express.

Nested responses and round-trips

Nested objects become helper classes so callers can work with typed values rather than repeated dynamic map lookups. Inspect those class names when different parts of the response share similar keys. Test fromJson with missing fields, explicit nulls and malformed values, then test toJson against the server’s expected shape. JSON date strings remain strings unless you deliberately add date parsing; converting every date-looking value automatically could change identifiers or timezone semantics.

Review before adding models to an application

Generated code does not fetch an API, validate a signature or implement business rules. Check import requirements, reserved names, large number behavior and how errors should be reported to callers. For a long-lived API client, compare this lightweight starting point with schema-driven or annotation-based generation used by your project. Keep fixtures for several real response shapes, with personal information removed, so future contract changes are caught by tests rather than by users.

Do not infer a whole API from one row

A list’s first object may omit optional fields that appear later. Compare several sanitized examples with the official contract before deciding that a field is always an integer, always present or always non-null. Keep wire-format keys stable in fromJson and toJson even if you improve Dart field names. Renaming a Dart property should not accidentally rename the key an external service expects.

Frequently asked questions