DEV Community: Khem Raj Rai

5 JSON-to-C# conversion mistakes generated models can hide

Khem Raj Rai — Wed, 05 Aug 2026 01:56:02 +0000

JSON-to-C# generators are useful for removing boilerplate, but their output is a starting point - not a schema.

Before shipping generated models, I review five things:

1. Missing property vs explicit null

A missing JSON property and a property whose value is null can mean different things. The generated C# model should reflect whether the field is required, nullable, or optional in your application.

2. Integers that may outgrow Int32

A sample value of 42 does not prove the field will always fit in int. Identifiers, counters, and timestamps may need long, decimal, or even string.

3. Strings with stronger domain types

Values such as ISO timestamps, UUIDs, and money often arrive as strings. Consider DateTimeOffset, Guid, or decimal when the contract supports it.

4. Empty arrays reveal no element type

[] gives a converter no evidence about the collection's contents. Add a representative item before generating, or review the inferred fallback type.

5. Record vs class semantics

Records are useful for value-oriented data transfer models. Classes are often a better fit when identity, mutation, or framework behavior matters.

I built DevCrate's JSON to C# converter to make the first pass fast and private. Conversion happens locally in the browser, so the JSON is not sent to a conversion API:

https://devcrate.org/tools/json-to-csharp/

Generated code still deserves a human review.

What “Client-Side” Privacy Actually Means for Developer Tools

Khem Raj Rai — Sun, 02 Aug 2026 13:29:06 +0000

When a developer pastes a JWT, API request, or private JSON document into a utility, “client-side” sounds reassuring. But it is important to understand exactly what that promise covers.

There are two separate data flows involved.

1. Processing the tool input

A genuinely client-side utility parses and transforms the user’s input inside the browser. The input is not submitted to an API, stored in a database, or sent to an analytics service.

For example, a browser can:

Parse JSON using JSON.parse()
Generate hashes with the Web Crypto API
Generate identifiers with crypto.randomUUID()
Decode Base64URL data locally
Convert structured data using JavaScript running on the device

This is the privacy benefit developers usually care about: their tokens, payloads, and source data never need to leave the browser.

2. Loading the website

A client-side tool is still a website. On the first visit, the browser normally requests HTML, JavaScript, fonts, and other files from a hosting provider or CDN.

That infrastructure may receive ordinary request information such as the IP address, requested page, browser type, and request time. Therefore, “tool inputs never leave your browser” is usually more accurate than claiming “zero server logs” unless the entire hosting configuration has been independently verified.

Better privacy language

A trustworthy developer tool should make concrete, testable statements:

Tool inputs are never transmitted to a processing server.
Conversion happens locally in the browser.
Inputs and results are not intentionally persisted.
Clear controls are provided for sensitive data.
Offline support applies after the required application files have been cached.

These claims tell users what actually happens without overpromising.

Privacy also requires good UX

Implementation alone is not enough. A privacy-focused tool should also provide:

Visible Clear buttons
No automatic input history
Warnings when a decoder does not verify cryptographic signatures
Honest explanations of hosting and offline behavior
Useful functionality without requiring an account

I applied these principles while building DevCrate, a collection of browser-only developer utilities. Its converters, JWT inspector, hashing tools, and UUID generator run locally without sending tool inputs to a processing API.

Client-side architecture is not a magic privacy label. It is a specific technical design decision—and the clearest products explain exactly what it protects.

Disclosure: I used AI assistance while editing this article and developing portions of the project. I reviewed the final text and technical claims.

JWT Decoding Is Not Verification: The Checks That Actually Matter

Khem Raj Rai — Thu, 30 Jul 2026 09:45:04 +0000

A JWT decoder can make a token readable, but it cannot tell you whether the token should be trusted.

A JSON Web Token usually has three dot-separated parts: a header, a payload, and a signature. Decoding Base64URL turns the first two parts into readable JSON. That is useful for debugging, but it proves nothing about who created the token or whether it was modified.

What verification must check

A secure verifier should do all of the following:

Verify the signature using the issuer's expected key.
Enforce an allowed algorithm instead of trusting the token's alg field blindly.
Validate exp and reject expired tokens.
Validate nbf before accepting a token that is not active yet.
Match iss to the expected issuer.
Match aud to the service receiving the token.
Apply a small, deliberate clock-skew allowance when appropriate.

A token can contain perfectly readable claims and still be forged, expired, or intended for a different API.

A safer debugging habit

Use decoding only to inspect structure and claims. Treat everything you see as untrusted until your application verifies the signature and validates the relevant claims with a maintained JWT library.

This is also why developer tools should avoid showing a vague green "valid" state after decoding. Readable is not the same as verified.

I built the browser-only JWT inspector in DevCrate with that distinction in the interface. Decoding runs locally, and the result explicitly says that the signature has not been verified.

Try the DevCrate JWT inspector

What JWT validation mistake have you seen most often in real projects?

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.