Are JSON keys case-sensitive?

Yes. JSON object member names are strings, and string comparison in the JSON standard is case-sensitive. That means "name" and "Name" are different keys at the data interchange level RFC 8259 (JSON standard).

What that means in practice

• Do not assume consumers will normalize key casing. The JSON text itself distinguishes keys by exact characters and case RFC 8259.
• An object like {"A":1, "a":2} contains two distinct JSON names. It is different from repeating exactly the same name twice, which the standard advises against because receivers handle exact duplicates inconsistently RFC 8259.
• Comparing member names is defined as a straight string comparison “code unit by code unit,” which preserves case differences RFC 8259.

Why you still see case-insensitive behavior in some frameworks

While JSON itself is case-sensitive, some deserializers choose to match property names case-insensitively for convenience. For example, Microsoft documents System.Text.Json’s normal default as case-sensitive, but its web default as case-insensitive. The PropertyNameCaseInsensitive option controls this matching Microsoft: case-insensitive property matching. This is a framework choice, not a change to JSON.

Key takeaways

• Interchange is case-sensitive. If casing must be flexible, your receiver must implement that.
• Document consumer behavior: whether it maps keys case-insensitively or requires exact spellings.

Duplicates and collisions

The JSON standard recommends object member names be unique. When they aren’t, behavior is explicitly “unpredictable” across implementations RFC 8259. If a pipeline treats names case-insensitively, {"A":1, "a":2} can collide and overwrite; if it is case-sensitive, both may be retained separately.

How to avoid casing bugs

Adopt and enforce one casing convention

Pick a canonical casing (for example, camelCase) and require it everywhere: producers, validators, and consumers. If your API documentation shows property names, publish the exact spellings.

Test the real pipeline

Run round-trip tests through your actual deserializer, middleware, and storage. Include payloads with intentional casing variations to observe whether keys are preserved, overwritten, or rejected.

Validate contracts

Use a schema or contract check to assert property names. For background on practical uses of JSON Schema in enforcement, see What JSON Schema is used for in practice, and for catching implementation mistakes, see What are schema errors? A practical explainer.

Quick checklist: prevent case-related key bugs

• Choose one key casing (e.g., camelCase) and document exact property names in your API reference.
• Verify your deserializer setting (e.g., case-insensitive matching on/off) and note it in the contract.
• Add tests that send both "A" and "a" in the same object and confirm the consumer’s behavior.
• Check downstream storage and queries for exact key spelling expectations.
• Fail fast in validation when unexpected casing appears.

Examples across tools

• Some JSON query libraries and parsers treat key lookups as case-sensitive, so "name" and "Name" will not match interchangeably GJSON issue: keys are case-sensitive.

Short FAQ

Can a JSON object contain both "A" and "a"?

Yes, because they are different strings; they are not duplicate JSON names. The standard’s duplicate-name warning concerns names that are equal after JSON string decoding RFC 8259. If your consumer compares names case-insensitively, they will collide.

Why did my API accept the wrong casing?

Some frameworks opt into case-insensitive property binding by default. For instance, ASP.NET Core can accept keys regardless of case unless you disable it ASP.NET Core: case-insensitive binding. That flexibility is implementation-specific.