DEV Community

JSON to C# Converter: Generate Classes and Records Safely

Turning an API response into a usable C# model looks simple until the JSON contains nested objects, arrays, nullable values, or inconsistent data types. A converter can remove the repetitive typing, but the generated result should be treated as a strong starting point-not a substitute for reviewing the contract your application actually expects. This guide shows how JSON maps to C# classes and records, what to check after generation, and how to do the conversion without uploading private payloads to a processing server.

A small JSON-to-C# example

Suppose an API returns this product object:

{
  "id": 2048,
  "title": "Mechanical Keyboard",
  "price": 129.99,
  "inStock": true,
  "tags": ["hardware", "keyboards"],
  "vendor": {
    "name": "Northwind Devices",
    "country": "JP"
  }
}

A class-oriented model might look like this:

public class Product
{
    public long Id { get; set; }
    public string Title { get; set; }
    public double Price { get; set; }
    public bool InStock { get; set; }
    public List<string> Tags { get; set; }
    public Vendor Vendor { get; set; }
}

public class Vendor
{
    public string Name { get; set; }
    public string Country { get; set; }
}

A record-oriented version can express the same shape more compactly:

public sealed record Product(
    long Id,
    string Title,
    double Price,
    bool InStock,
    IReadOnlyList<string> Tags,
    Vendor Vendor
);

public sealed record Vendor(string Name, string Country);

Both are valid starting points. The better choice depends on how the model will be created, mutated, compared, and serialized in your application.

How to convert JSON to C#

You can test the process with the free JSON to C# converter in DevCrate:

  • Open the converter and load the sample, or paste a valid JSON object.
  • Review the generated model on the right as the input changes.
  • Choose the C# style that matches your project: records for concise data-focused models, or classes with getters and setters for mutable models.
  • Copy the result into your project.
  • Review nullability, numeric precision, naming, collection types, and serializer behavior before shipping it.

The conversion runs in the browser. The JSON is parsed locally and is not sent to a DevCrate processing API.

Typical JSON-to-C# type mappings

JSON value Common C# type What to verify
String string Could it really be a date, URI, GUID, or enum?
Whole number int or long Can it exceed the 32-bit integer range?
Decimal number double or decimal Use decimal when exact financial precision matters.
Boolean bool Confirm null is not also permitted.
Object Nested class or record Check naming and reuse across the schema.
Array List<T>, T[], or IReadOnlyList<T> Empty arrays do not reveal their element type.
Null Nullable reference/value type One sample cannot prove the full contract.

Type inference is based on the values present in the sample. That limitation matters: a single payload cannot reveal every possible response the API may produce.

C# records versus classes

Choose a record when:

  • The object represents data rather than long-lived mutable state.
  • Value-based equality is useful.
  • Concise construction and pattern matching improve the code.
  • Properties should normally be initialized rather than repeatedly changed.

Records are especially comfortable for DTOs, messages, query results, and configuration snapshots. Positional records are concise, while records with named properties may be easier to decorate with serializer attributes.

Choose a class when:

  • The object is mutable through its lifetime.
  • A framework expects a parameterless constructor and writable properties.
  • Identity matters more than value equality.
  • The model contains behavior in addition to data.

Classes with get; set; remain a practical default for many Entity Framework models, form-binding scenarios, and older serialization conventions. Modern System.Text.Json supports both patterns, but constructor names, access modifiers, and attributes still deserve a quick review.

Five things to review after generation

  1. Nullable values
    If a sample contains a string today, the API may still return null tomorrow. With nullable reference types enabled, decide whether a field should be string, string?, or initialized with a safe default. The API contract or JSON Schema is more reliable than one observed payload.

  2. Money and numeric precision
    A converter may infer double from a decimal-looking JSON number. For prices, rates, and financial totals, decimal is often the safer domain type because binary floating-point cannot represent every base-10 value exactly.

  3. Dates and identifiers
    Values such as 2026-07-27T08:30:00Z and UUID-shaped strings are still JSON strings. In C#, you may want DateTimeOffset, DateOnly, Uri, or Guid after confirming the producer's format and validation rules.

  4. Property names and serializer configuration
    C# commonly uses PascalCase, while JSON often uses camelCase or snake_case. System.Text.Json can handle camelCase through naming policies. For irregular names, add JsonPropertyName attributes rather than silently changing the wire contract.

  5. Arrays and inconsistent objects
    An empty array gives a converter no evidence about its item type. Arrays containing objects with different fields can also produce an incomplete model. Test with a representative payload, then compare the result with the API documentation.

Why local conversion is useful

Real JSON often contains customer details, internal URLs, access claims, or business data. A server-based converter may be trustworthy, but sending the payload creates another system that could log, retain, or expose it. With a browser-only converter, avoiding the processing request entirely creates a simpler privacy boundary. You should still inspect any site and avoid pasting active credentials, but local execution is preferable when the task does not require a server. DevCrate is open source, so the processing approach can be reviewed. The project is statically hosted, and the converter performs its parsing and code generation in the browser.

Practical takeaway

A JSON-to-C# generator is best used to remove boilerplate, then followed by a short engineering review. Check nullability, precision, collection choices, serializer settings, and the difference between the sample and the real API contract. Try the JSON to C# converter with generated or non-sensitive sample data. If you find a payload that produces an awkward model, that edge case is useful feedback-the goal is correct, reviewable code rather than blind one-click generation.

Comments

No comments yet. Start the discussion.