JSON to C# Class Generator
Generate C# model classes from JSON with PascalCase properties and System.Text.Json attributes — entirely in your browser.
- Runs in your browser
- No upload, no tracking
- Free forever
How it works
A JSON-to-C# generator reads a sample JSON payload and emits matching C# model classes, converting keys to PascalCase properties, preserving the original names with [JsonPropertyName] attributes for System.Text.Json, and turning nested objects and arrays into their own classes and List<T> fields. 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 .NET code.
- 1
Paste your JSON
Drop a representative object into the input panel, or click Sample to load an example. The C# classes regenerate as you edit.
- 2
Set class name and namespace
Choose the root Class name and the Namespace (default MyApp.Models) so the output drops straight into your project.
- 3
Toggle nullable types
Turn Nullable types on to emit string? and int? in line with C# 8+ nullable reference types, or off for non-null properties.
- 4
Copy the classes
Nested objects become separate classes and arrays become List<T>. Copy the generated code with one click — nothing is uploaded.
Frequently asked questions
- Is my JSON uploaded anywhere?
- No. The C# classes are generated locally in your browser with JavaScript. Your JSON is never sent to JusDB or any server.
- What serialization attributes are added?
- Each property gets a [JsonPropertyName("...")] attribute for System.Text.Json so the original JSON key names are preserved while the C# properties use PascalCase.
- Does it support nested objects and arrays?
- Yes. Nested objects become separate classes and arrays become List<T>. If you paste an array of objects, the first element is used as the shape for the root class.
- What about nullable types?
- Toggle Nullable types to emit reference and value types with a trailing ? (for example string? and int?), which matches C# 8+ nullable reference type conventions.
- Can I set the namespace?
- Yes. Set the Namespace field (default MyApp.Models) and the generated classes are wrapped in that namespace, and the root class name in the Class name field, so the output drops straight into your project.
- Does it use System.Text.Json or Newtonsoft?
- It targets System.Text.Json, the built-in serializer in modern .NET, using [JsonPropertyName("...")] attributes. The same classes work with Newtonsoft.Json, though Newtonsoft uses its own [JsonProperty] attribute.
From JSON sample to production-ready C# models
Generating C# from a JSON sample gets you 80% of the way to a working data contract, but the remaining 20% is where deserialization actually succeeds or throws at runtime. A single payload is one observation of a shape, and turning it into POCOs (plain old CLR objects) or records means making decisions the sample alone cannot make for you — about nullability, optionality, enums, and the boundary between System.Text.Json and Newtonsoft.Json.
Records or classes for your DTOs
For data transfer objects you only read once after deserializing, C# records are often the better fit: they are immutable by default, give you value equality for free, and read as a concise positional or init-only declaration. Mutable classes still make sense when you bind to UI, mutate properties through a pipeline, or need a parameterless constructor that older frameworks expect. System.Text.Json has supported deserializing into records with parameterized constructors since .NET 5, so either style round-trips cleanly. Pick records for inbound API contracts you treat as snapshots, and classes for entities you intend to edit in place.
Mapping snake_case keys with [JsonPropertyName]
Most JSON APIs send snake_case or kebab-style keys, while idiomatic C# wants PascalCase properties. The [JsonPropertyName("created_at")] attribute bridges that gap per property so your CreatedAt field still binds to the wire name. For System.Text.Json you can also set a JsonNamingPolicy globally instead of annotating every property — but explicit attributes win when the naming is irregular (an API mixing camelCase and snake_case in the same object). Newtonsoft.Json uses [JsonProperty] for the same purpose, so if you migrate serializers you will swap the attribute, not the property names.
Nullability is a decision, not a detail
A sample cannot tell you what is optional. If a field happens to be present in your one example, the generator emits a non-null type — but the API may omit it entirely or send null for other records. This is the single biggest source of deserialization surprises. Distinguish value types that are sometimes absent (int? versus int, so a missing number becomes null rather than silently defaulting to 0) from reference types under nullable reference types (string? versus string). Treat the generated types as a first draft and widen anything that the API contract — not your sample — says can be missing.
Collections, nesting, and shapes the sample hides
Arrays of objects become List<T> over a generated element class, and nested objects each become their own type so your model tree mirrors the JSON tree. What a single sample cannot reveal is variation: a field that is a string here but an object elsewhere, an enum whose other members never appeared, or a polymorphic union where the shape depends on a discriminator. After generating, fold in the variants you know exist — promote loosely typed strings to enums, and use a converter or JsonDerivedType for union shapes rather than forcing one rigid class to cover them all.
If your stack spans more than C#, the same JSON drives our JSON to Dart and JSON to TypeScript generators so your models stay aligned across services.
Before generating, pretty-print and skim the payload in the JSON formatter to spot nulls, mixed types, and empty arrays — the exact spots where a generated model needs a human decision about nullability or enums.