BRev JSON to C# classes
JSON APIs speak camelCase and C# speaks PascalCase — the generated classes bridge that with serializer attributes on every property, so deserializing keeps working without renaming a single key by hand. Each nested object becomes its own class, and arrays become typed List<T>.
Value types get the nullable treatment they need: a number that is ever null arrives as long? or double?, not a silent 0. Merge several real responses as samples and properties that sometimes disappear are typed accordingly instead of throwing at deserialize time.
ISO timestamps can map to DateTimeOffset and repeated string values to real enums — both toggles, and the serializer options let you match the conventions your project already uses.
How JSON type inference works
The generator reads your JSON and builds the strictest type that fits every value it saw: objects become interfaces, structs or classes; arrays become typed lists; a value that appears as both a number and a string becomes a union. Repeated string values (like "active" / "inactive") can be promoted to an enum, and ISO 8601 timestamps or UUIDs can map to your language's date and UUID types — both are toggles above.
Why add multiple samples?
One API response rarely shows every field — optional fields are missing, nullable fields happen to be set. Add two or three real responses with Add sample and they merge into a single type: a field present in every sample stays required, and a field that only some samples carry becomes optional. More samples always produce a more honest type.
Nullable is not optional
A field that appears as null in a sample is nullable — it is always present, but its value may be null (string | null). A field that is missing from some samples is optional — it may not exist at all (field?: string). Serializers treat the two very differently, which is why the generator keeps them distinct instead of collapsing both to "maybe".
JSON Schema in, types out
Already have a JSON Schema? Switch the input to JSON Schema and the types are derived from the schema's declared properties, required list and formats instead of being inferred from samples — or pick the JSON Schema output target to go the other way and generate a schema from samples.
FAQ
Does my JSON leave the browser?
No — the generator is client-side JavaScript. Payloads with bearer tokens or customer records never leave this page.
Why long? instead of int?
JSON numbers carry no size hint, so integers default to the safest width. A field that ever appears as null becomes nullable (long?) so deserialization cannot silently coerce missing data to 0.
How are optional fields detected?
Across samples: present in all pasted samples means required; missing from any sample means optional. Add a second or third real response — one sample always looks fully required.
Do the classes work with my serializer?
The properties carry JSON name attributes so the mapping to the original keys is explicit rather than relying on a global naming policy — check the options row to align the output with your setup.