Need help with your JSON?

Try our JSON Formatter tool to automatically identify and fix syntax errors in your JSON. JSON Formatter tool

Reserved Words as Keys in JSON: Why They Cause Problems

If you searched for reserved words in JSON, the short answer is this: JSON itself does not reserve object-key words. A payload with keys like "class", "default", or "return" is valid JSON. The real trouble starts later, when that data is mapped into language identifiers, generated classes, templates, ORMs, or API frameworks that do have reserved words.

Quick Answer

JSON object member names are strings, so "class" and similar keys are valid.
Problems usually appear in the consumer, not in JSON.parse or the JSON syntax itself.
Modern JavaScript can access data.class and data.default.
The risky cases are code generation, typed DTOs, object mappers, and framework-specific reserved names.

Are Reserved Words Valid in JSON?

Yes. The JSON specification treats object member names as strings. That means a JSON parser does not care whether a key looks like a programming-language keyword. This is valid JSON:

{
  "class": "admin",
  "default": true,
  "return": 42,
  "package": "starter"
}

A standards-compliant JSON parser should accept this without complaint.

Why They Still Cause Problems in Real Projects

The key question is not whether the JSON is valid. It is whether the next tool in your pipeline treats the key as a plain string or tries to turn it into an identifier with naming rules of its own.

1. Code Generation and Typed Models

This is the most common failure point. If JSON is converted into Java, Kotlin, C#, Swift, Go, or Python model types, some keys cannot be used directly as field or property names. A generator may fail, escape the name awkwardly, or require an alias.

Typical fix: keep the wire format, rename internally

public class UserDto {
  @JsonProperty("class")
  public String className;

  @JsonProperty("default")
  public boolean defaultValue;
}

The JSON stays the same, but your application code uses safe member names.

2. Access Syntax Is Not the Same Across Languages

Older articles often claim that JavaScript cannot read reserved-word properties with dot notation. That is outdated. In modern JavaScript, keyword-like property names such as class and default work. Bracket notation is still required when the key is not a valid identifier, such as "user-name" or "first name".

Modern JavaScript reality check

const data = JSON.parse('{"class":"admin","default":true,"user-name":"sam"}');

console.log(data.class);         // "admin"
console.log(data.default);       // true
console.log(data["user-name"]);  // "sam"

3. Framework and Schema Boundaries Can Reserve Names

Even when JSON is valid, downstream systems may reserve certain names or prefixes for their own metadata. This shows up in API layers, template engines, database mappers, and serialization frameworks. The JSON key is not wrong; it is just inconvenient in that specific environment.

API and schema tools may reserve special prefixes or internal metadata fields.
ORMs and SQL layers can stumble over names that match SQL keywords such as order, group, or default.
Code generators often need explicit aliases when JSON keys overlap with language keywords.

Language-Specific Notes

JavaScript and TypeScript

Parsing is fine. Keyword-like property names are usually fine too. The bigger issue is consistency when you generate types or want ergonomic property access across many keys. For keys that are not valid identifiers, use quoted property names in types and bracket notation at runtime.

Python

Plain dictionaries handle any string key. Problems start when you convert JSON into objects, dataclasses, or model classes where class or from would be invalid attribute names.

Java, Kotlin, C#, Swift

These ecosystems commonly map JSON into DTOs or structs. Reserved words often need annotation-based aliases so the external JSON name stays stable while the internal field name stays legal.

Safer Naming Patterns

If you control the schema, the best fix is usually to choose names that communicate meaning without colliding with language syntax.

Awkward Key

class
default
return
new

Safer Alternative

className, userRole
defaultValue, isDefault
returnValue, result
isNew, createdRecently

If You Cannot Rename the Incoming JSON

Parse the JSON normally and keep the raw key names at the API boundary.
Map external names to safe internal names once, close to your deserializer or validation layer.
Document the aliasing clearly so serialization back to JSON remains predictable.
Add a test that round-trips the payload, especially if code generation is involved.

Bottom Line

Reserved words are not a JSON validity problem. They are a portability and tooling problem. If a payload only needs to be valid JSON, keys like "class" are fine. If that payload will be turned into typed code, templates, database fields, or framework models, aliasing or safer naming will save time later.

Need help with your JSON?

Try our JSON Formatter tool to automatically identify and fix syntax errors in your JSON. JSON Formatter tool