JSON FAQ
Quick answers to specific JSON questions that don't need a full topic page — each one links to the reference page that covers it in depth.
Try It Now
Put this into practice with OpenFormatter's free tools — no signup, 100% client-side.
Official Specification
Related References
FAQs
Is JSON a programming language?
No. RFC 8259 describes JSON as "a text format for the serialization of structured data" — it has no variables, no control flow, and no functions. It's a data format that many programming languages can read and write, not a language itself.
Can JSON contain comments?
No. RFC 8259's grammar allows only space, tab, carriage return, and line feed as whitespace — there's no // or /* */ production anywhere in it, so a parser that follows the spec treats a comment as a syntax error, not as something to skip.
Is JSON case-sensitive?
Yes. The literal tokens true, false, and null must be lowercase — TRUE or Null are invalid JSON, not just unconventional. Object member names are also case-sensitive: "id" and "ID" are two different keys, never the same one written differently.
What's the file extension for JSON?
.json, registered by RFC 8259 alongside the application/json media type used for JSON over HTTP.
Can JSON have duplicate object names?
Syntactically, yes — nothing in RFC 8259's grammar forbids repeating a name within one object. But the RFC also warns that when names aren't unique, the behavior of software that reads the object is unpredictable, since different parsers resolve the conflict differently.
Is JSON always UTF-8?
For interchange between systems, yes — RFC 8259 requires it: JSON text exchanged between systems MUST be encoded as UTF-8, and a generator MUST NOT add a byte-order mark.
Why are trailing commas invalid?
Because RFC 8259's grammar defines the comma strictly as a separator between members or values, never as a terminator — there's no rule in the grammar that produces a comma after the last item, so every conforming parser rejects one.
What's the difference between JSON validation and JSON Schema validation?
"JSON validation" usually means checking that text is well-formed JSON at all — syntax only. "JSON Schema validation" is a separate, later step that checks whether an already-well-formed document has the shape you expect (required fields, types, formats). A document can pass the first and fail the second.
Why do I get "Unexpected token" errors?
The parser hit a character it doesn't allow at that position in the grammar — most often a trailing comma, single quotes instead of double quotes, an unquoted key, or a comment. The error message's position number points at the exact character.
Can JSON represent dates?
Not natively — RFC 8259 defines only six value types (string, number, boolean, null, object, array), and none of them is a date. Dates are conventionally represented as ISO 8601 strings, by convention rather than by anything the grammar requires.
Is JSON order guaranteed?
It depends which structure. Arrays: yes — an array is defined as an ordered sequence of values, and that order is part of the data. Objects: no — RFC 8259 defines an object as an unordered collection of name/value pairs, so a parser is free to return members in a different order than they were written.
What's the difference between null and a missing property?
A property set to null is present in the object with an explicit null value. A missing property doesn't appear as a member at all. As the JSON Schema documentation puts it: "a property with value null is not equivalent to the property not being present." JSON Schema's required keyword controls only whether a property must be present — it says nothing about whether a present value is allowed to be null.