DEV Community: Khem Raj Rai

JSON to C# Converter: Generate Classes and Records Safely

Khem Raj Rai — Sun, 26 Jul 2026 15:11:16 +0000

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[], or IReadOnlyList	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 statically hosted and documents its privacy boundary clearly: the converter performs its parsing and code generation in the browser, and tool inputs are not sent to a conversion API.

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.

Why Developer Utilities Should Process Sensitive Data in Your Browser

Khem Raj Rai — Sun, 26 Jul 2026 14:45:14 +0000

Developers paste surprisingly sensitive information into online utilities every day: API responses, access tokens, database records, cURL commands, and configuration fragments. A formatter or converter may look harmless, but the input can still contain customer data, internal URLs, credentials, or claims that were never meant to leave a local machine.

That is why I built DevCrate: a privacy-first collection of developer utilities where the conversion work happens in the browser instead of a processing API.

The hidden risk in convenient online tools

A typical online converter can send your input to a remote server before returning the formatted result. The site may be legitimate, but a developer often cannot verify:

whether the payload is logged;
how long request data is retained;
which analytics or third-party scripts can observe the page;
whether an error-reporting service captures the input;
who controls the infrastructure later.

Even when a tool promises not to store data, avoiding the request entirely is a stronger privacy boundary.

What browser-only processing changes

A client-side utility downloads its application code and runs the transformation locally. Parsing JSON, generating UUIDs, decoding Base64URL segments, and converting cURL commands do not inherently require a server.

DevCrate is statically exported and uses browser APIs or local application logic for its tools. The current collection includes:

JSON to TypeScript, C#, Kotlin, and SQL;
JSON to Shopify CSV;
cURL to JavaScript Fetch, Python Requests, and C# HttpClient;
JWT inspection;
Base64 encoding and decoding;
hashing and UUID generation.

DevCrate is statically hosted, and its privacy boundary is documented on the site: tool inputs are processed in browser memory and are not sent to a conversion API.

JWT decoding is not JWT verification

This distinction is important. A JWT decoder can parse the token header and payload locally, but readable claims are not proof that the token is authentic.

Signature verification requires the expected algorithm and the correct issuer key. Until that verification succeeds, an attacker can modify the claims and produce a token that still decodes normally.

A safe decoder should therefore:

label the output as unverified;
avoid uploading the token;
distinguish issued-at and expiry timestamps clearly;
remind users to verify signatures in the application that trusts the token.

Base64 is not encryption

Base64 is an encoding format. Anyone who receives the encoded value can reverse it without a password or key. It is useful for transporting binary data in text systems, but it should never be presented as a security control.

Hashing also needs context. Modern browser cryptography can generate SHA-family hashes locally, while MD5 support is mainly useful for compatibility checks and legacy systems—not for password storage or security-sensitive integrity guarantees.

Static architecture has practical benefits

Keeping utility processing on the client creates several advantages:

no processing server to operate or scale;
fewer places where user payloads can be retained;
fast feedback while typing or pasting;
easier static hosting;
the potential to keep working after application assets have been cached by a supported browser.

It also creates responsibilities. Browser code still needs dependency review, a careful content-security policy, transparent analytics choices, and accurate language around what “local” actually covers. External links, hosting requests, and optional analytics are different from sending tool input to a conversion endpoint.

UX matters too

Privacy alone is not enough if the tool is frustrating. Developer utilities should be fast to navigate, usable without a mouse, and honest when input is invalid.

DevCrate uses a global Cmd/Ctrl+K palette, live conversion, explicit error states, copy and download actions, and sample inputs that let visitors test tools without exposing real data.

Try it with sample data

You can explore the tools at devcrate.org. Start with generated or non-sensitive sample data, and inspect the browser's network activity if you want to verify the behavior.

I would especially value feedback on converter correctness, missing utilities, keyboard accessibility, and any privacy wording that feels unclear. The goal is not to ask developers for blind trust—it is to make the design easier to verify.