JSON to C# Class Converter
Generate strongly-typed C# POCO classes and models from JSON with Newtonsoft or System.Text.Json attributes.
Classes Generated
2
Total Properties
10
Target Library
newtonsoft
Nullable Reference Types
Disabled
How JSON to C# conversion works
Paste any JSON object and this tool generates a set of C# classes that model its structure. It infers .NET types (int, double, bool, string, List<T>) and recurses into nested objects to produce a full class hierarchy. Property names are converted to PascalCase; when the original JSON key differs, a [JsonProperty] or [JsonPropertyName] attribute is added so Newtonsoft.Json or System.Text.Json can deserialize correctly. The generated code uses { get; set; } auto-properties — compatible with all major .NET JSON libraries.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Generating classes from a sample response rather than typing properties.
- Getting property names that follow C# conventions from JSON keys that do not.
- Deciding between records and classes once the shape is in front of you.
- Producing types a serialiser binds without a custom converter.
- Getting property names that follow C# conventions from JSON keys.
Frequently Asked Questions
- How are C# types inferred?
- Strings map to `string`, booleans to `bool`, whole numbers to `int`, fractional ones to `double`, and a nested object to a generated class named after its key. A `null` has no type information, so it becomes `object`.
- Why are property names changed?
- Because JSON conventionally uses `snake_case` or `camelCase` and C# properties are PascalCase. The name is converted for idiomatic code, which is exactly why the serialiser attribute matters — it records the original key.
- Do I need JsonPropertyName attributes?
- Whenever the C# name differs from the JSON key, yes. `System.Text.Json` matches names case-insensitively by default but will not bridge `user_name` to `UserName`, so the attribute is what keeps deserialisation working.
- What happens with an array of objects?
- The elements are merged before the class is generated, so a key present on only some of them still becomes a property. Reading only the first element produces a class that silently drops fields the rest of the array carries.
- Should the properties be nullable?
- Under nullable reference types, any field that can be absent or null should be declared `string?` rather than `string`, or the compiler's guarantees are wrong from the first deserialisation. JSON gives no way to tell which those are — that decision is yours.
- Class or record?
- A record is a good fit for an immutable DTO and gives value equality for free. A class with settable properties is what most existing serialisation code and ORMs expect. Neither choice affects how the JSON maps.
Common errors and gotchas
- Using a non-nullable value type for a field that can be absent, which then throws on deserialisation.
- Letting a whole number become `int` when the values exceed its range.
- Assuming camelCase keys map automatically, which needs a naming policy or attributes.
- Leaving properties settable when the model should have been init-only.
- Overlooking that `System.Text.Json` and Newtonsoft differ on defaults such as case sensitivity.