The Architect’s Guide to JSON: Syntax, Semantics, and Interoperability Standards

1. Introduction: The Deceptive Simplicity of the Data Interchange Standard

In the contemporary landscape of distributed computing, Microservices architecture, and RESTful API design, JavaScript Object Notation (JSON) has ascended to a position of ubiquity that borders on hegemony. It has effectively displaced XML as the lingua franca of the web, prized for its lightweight structure, human readability, and seamless integration with the JavaScript runtime environment. However, this perceived simplicity is frequently the source of significant architectural fragility. JSON is not merely a “text format”; it is a rigorous protocol governed by synchronized international standards. The widespread assumption that “JSON is just JavaScript” or that “if it parses, it is valid” has led to a prevalence of fragile parsers, security vulnerabilities, and data corruption issues in production environments.

This documentation serves as the definitive reference for internal development teams. It is an exhaustive analysis of the JSON Data Interchange Format as defined by RFC 8259 (Internet Engineering Task Force) and ECMA-404 (Ecma International). It moves beyond basic syntax verification to explore the theoretical underpinnings, the complex edge cases of serialization, the divergence between theoretical standards and real-world parser implementations, and the critical security implications of malformed data. This guide is designed to be the sole reference required for a developer to implement robust, RFC-compliant JSON parsers or generators, ensuring strict adherence to the grammar that underpins modern data exchange.

2. The Authority of Standards: RFC 8259 and ECMA-404

To master JSON syntax, one must first understand the authority that defines it. Unlike ad-hoc formats that evolve organically through implementation consensus, JSON is governed by strictly synchronized standards bodies. The current Internet Standard for JSON is RFC 8259 (STD 90), titled The JavaScript Object Notation (JSON) Data Interchange Format. This document, published in December 2017, obsoletes the earlier RFC 7159 and RFC 4627, unifying the specification into a cohesive standard.[1]

Concurrently, ECMA-404 defines the JSON syntax as a distinct standard. While the syntax described in these documents is effectively identical, their intent differs significantly. The IETF RFCs focus heavily on interoperability, security, and the mechanics of data transmission over the internet—addressing issues like MIME types, character encoding, and security considerations. In contrast, the ECMA standard focuses purely on the grammatical definition of the valid JSON text sequence, decoupled from any specific transmission context.[2]

2.1 The Inter-Standard Synchronization

Historically, discrepancies existed between the definitions provided by different bodies. However, RFC 8259 explicitly states the intent that the grammar remains identical between the IETF and ECMA definitions. The two organizations have committed to working together to ensure that any future updates maintain this alignment, thereby preventing the fragmentation of the standard into “IETF JSON” and “ECMA JSON” dialects. This synchronization provides a stable foundation for global interoperability, assuring developers that a valid JSON payload in a Node.js environment (governed by ECMA script standards) is guaranteed to be valid when consumed by a Python service (adhering to IETF RFCs).[1]

3. Media Types, Encoding, and the Wire Protocol

Before a single byte of JSON data is parsed, the transmission protocol must correctly identify the payload. The misidentification of JSON content is a primary vector for security vulnerabilities, particularly Cross-Site Scripting (XSS) and content-sniffing attacks.

3.1 The application/json Mandate

The Internet Assigned Numbers Authority (IANA) has registered the official MIME type (media type) for JSON text as application/json. This registration is documented in RFC 4627 and reaffirmed in RFC 8259.[5]

Critical Implementation Directive:

Development teams must strictly adhere to application/json for both Content-Type (when sending data) and Accept headers (when requesting data).

Deprecated Types: The use of text/json or text/javascript is incorrect and technically deprecated. While some legacy browsers might accept them, they signal a misunderstanding of the protocol.[7]
The Danger of text/html: Serving JSON with a Content-Type of text/html is actively dangerous. Legacy browsers, when encountering text/html, may attempt to “sniff” the content to determine if it is actually HTML script. If the JSON payload contains strings that resemble HTML tags (e.g., <script>), the browser may execute them, leading to XSS vulnerabilities. Using application/json instructs the browser that the content is data, not executable code, disabling this sniffing behavior.[7]

3.2 Character Encoding: The UTF-8 Imperative

RFC 8259 imposes a strict constraint on character encoding: JSON text exchanged between systems that are not part of a closed ecosystem MUST be encoded using UTF-8.[1]

Previous specifications (RFC 4627) allowed for UTF-16 and UTF-32, provided that the parser could detect the endianness via the Byte Order Mark (BOM) or pattern analysis of the null bytes. However, to maximize interoperability and align with the dominant encoding of the World Wide Web, RFC 8259 mandates UTF-8.

Implications for Developers:

No BOM: UTF-8 does not require a Byte Order Mark. Parsers should be robust enough to ignore a BOM if present, but generators should not emit one.
Binary Data: JSON is a text format. It cannot natively support raw binary data. Any binary payloads (images, compiled protocol buffers) must be encoded into a text-safe format, typically Base64, before being embedded in a JSON string. This increases the payload size by approximately 33%, a trade-off inherent to the text-based nature of the format.[8]

4. The Grammar of JSON: A BNF Analysis

The syntax of JSON is defined using ABNF (Augmented Backus-Naur Form). A valid JSON text is a sequence of tokens that forms a single JSON value.

4.1 The Six Primitive Values

According to the specification, a JSON value must be one of the following six types. No other types are permitted [1]:

Object: An unordered collection of name/value pairs.
Array: An ordered sequence of values.
String: A sequence of zero or more Unicode characters.
Number: A numeric value (integer or floating-point).
Boolean: The strict literals true or false.
Null: The strict literal null.

Strict Literal Casing:

The literal names false, null, and true are case-sensitive. They MUST be lowercase.

Valid: true, null
Invalid: True, TRUE, Null, NULL

This strictness simplifies the state machine of the parser; it does not need to handle case-folding logic. A parser encountering True should immediately throw a syntax error.[1]

4.2 Whitespace Rules

Whitespace is permitted before or after any of the six structural characters ([, ], {, }, :, ,). The allowed whitespace characters are strictly defined as [1]:

Space (U+0020)
Horizontal Tab (U+0009)
Line Feed (U+000A)
Carriage Return (U+000D)

This permissiveness facilitates “pretty-printing,” allowing developers to format JSON with indentation for readability without altering the semantic meaning of the data. However, whitespace is not permitted within tokens (except for spaces inside a string). tr ue is not a valid boolean; 12 34 is not a valid number.[1]

5. The Object Structure: Keys, Uniqueness, and Security

An object is structured as a pair of curly brackets surrounding zero or more name/value pairs (or members). A colon separates the name from the value, and commas separate the pairs.[1]

5.1 The Strict Definition of Keys

A fundamental point of confusion for developers transitioning from JavaScript is the syntax of keys. In JSON, all keys must be strings, and those strings must be enclosed in double quotes.[9]

The following table illustrates the divergence between loose JavaScript object literals and strict JSON syntax:

Syntax	Validity	Reason
{"key": "value"}	Valid	Keys are strictly double-quoted strings.
{key: "value"}	Invalid	Unquoted keys are forbidden (Valid JS, Invalid JSON).
{'key': "value"}	Invalid	Single quotes are forbidden in JSON.
{123: "value"}	Invalid	Numeric keys are forbidden; they must be strings "123".

This restriction ensures that the parser does not need to implement a full identifier resolution engine (to distinguish variables from strings), keeping the grammar context-free and efficient.

5.2 The Duplicate Key Controversy and Security Risks

A critical ambiguity in the JSON specification concerns whether an object can contain multiple members with the same name. RFC 8259 states: “The names within an object SHOULD be unique.”

In the language of IETF standards (RFC 2119), “SHOULD” represents a strong recommendation but not a binding mandate (which would be “MUST”). Consequently, syntactically, {“a”: 1, “a”: 2} is valid JSON. However, the RFC explicitly warns that the behavior of software receiving such an object is unpredictable.[1]

Observed Parser Behaviors:

The unpredictability manifests in three distinct behaviors across the industry, creating “parser differentials” that attackers can exploit:

Last-Value Wins: The majority of parsers (including JavaScript’s JSON.parse and Python’s json library) will overwrite earlier keys with later ones. {“role”: “user”, “role”: “admin”} results in {“role”: “admin”}.[11]
First-Value Wins: Some streaming parsers or older implementations may retain the first occurrence and ignore subsequent duplicates.
Fatal Error: Strict parsers, often found in strongly-typed environments like Java (e.g., MuleSoft runtimes before version 3.9.1) or Go, may throw an exception and refuse to parse the payload entirely.[13]

Security Implication (JSON Injection):

This differential creates a security vulnerability known as JSON Injection or Parameter Pollution. If a security gateway (WAF) uses a parser that reads the first value to validate a request (e.g., checking role: user), but the backend application uses a parser that reads the last value (e.g., processing role: admin), an attacker can inject a duplicate key to bypass security controls.

Architectural Standard:

Internal systems must be configured to reject duplicate keys. Generators must never produce them. This ensures deterministic behavior across the distributed system stack.

6. Numbers: The Mathematical and Precision Minefield

Handling numbers in JSON is arguably the most complex aspect of the format due to the dissonance between the arbitrary precision allowed by the syntax and the fixed precision of the hardware and software consuming the data.

6.1 Strict Numeric Syntax

JSON numbers follow a base-10 decimal representation. Unlike JavaScript, which supports hex (0x), binary (0b), and octal (0o), JSON supports only base-10. The syntax rules are rigid to prevent ambiguity [1]:

No Leading Zeros: A number cannot begin with 0 unless the number is exactly 0 or the zero is immediately followed by a decimal point.
- Invalid: 01, 0123.
- Valid: 0, 0.123.
- Reasoning: In many languages (C, Java, Python, JavaScript), a leading zero indicates an Octal (base-8) number. 010 is 8, not 10. To prevent this confusion, JSON simply forbids the syntax entirely.[16]
The “Plus Sign” Prohibition: A number cannot be prefixed with +. While -1 is valid to indicate a negative number, +1 is invalid.
- Invalid: +10, +0.
- Error: This often results in Unexpected character (’+’ (code 43)) errors in Java-based parsers.[17]
Decimal Point Placement: A decimal point must be flanked by at least one digit on both sides.
- Invalid: 10., .5.
- Valid: 10.0, 0.5.
- Reasoning: This simplifies parsing logic, removing ambiguity about whether a dot is a decimal point or an object access operator.[20]
Scientific Notation: Exponents are denoted by e or E, followed optionally by + or -, and then digits.
- Valid: 1.5e3, 1E-4, 0e+5.
- Invalid: 1.5e, e5.

6.2 The IEEE 754 Constraint and the 53-Bit Cliff

The JSON specification states that numbers are sequences of digits and does not explicitly impose a precision limit. Theoretically, a JSON number could have 1,000 digits. However, the RFC includes a critical note on interoperability:

“Since software that implements IEEE 754 binary64 (double precision) numbers is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide.” [1]

The Mechanism of Failure:

JavaScript, along with many dynamic languages, treats all numbers as IEEE 754 double-precision floating-point values. This format allocates 53 bits for the significand (mantissa). This means it can only safely represent integers exactly in the range:

$-(2^{53} - 1) \text{ to } 2^{53} - 1$

$\approx \pm 9,007,199,254,740,991$

The 64-bit Integer (Snowflake ID) Crisis:

Backend systems using Java, C++, Go, or SQL databases frequently use 64-bit integers (int64, long) for identifiers (e.g., Database Primary Keys, Twitter Snowflake IDs). A signed 64-bit integer can scale up to $\approx 9 \times 10^{18}$ .

When such an ID—say 10765432100123456789—is serialized into JSON as a raw number and then consumed by a JavaScript client, the JavaScript engine parses it into a double. Since the value exceeds $2^{53}$ , the lower bits are lost due to precision rounding. The ID changes, effectively corrupting the data reference.[22]

Architectural Mitigation:

Developers must serialize 64-bit integers as Strings in JSON (e.g., {“id”: “10765432100123456789”}). This bypasses the numeric parser entirely, preserving the exact sequence of characters. The consuming application can then parse the string into a BigInt or long as needed.[16]

6.3 The BigInt Serialization Failure

Modern JavaScript (ES2020+) introduced the BigInt primitive to handle integers beyond the safe limit. However, the standard JSON.stringify() method was not updated to support BigInt natively. This was a deliberate decision by the TC39 committee to avoid “breaking the web” by implicitly changing the serialization format of numbers.

Attempting to stringify a payload containing a BigInt results in a specific error:

V8 (Chrome/Node): TypeError: Do not know how to serialize a BigInt
Firefox: TypeError: BigInt value can’t be serialized in JSON
Safari: TypeError: JSON.stringify cannot serialize BigInt.[26]

Solution and Workarounds:

To handle BigInts, developers must patch the BigInt prototype or provide a replacer function to stringify.


// Global Patch (Common but strictly speaking, prototype pollution)
BigInt.prototype.toJSON = function() {
  return this.toString();
};

Alternatively, using the newer JSON.rawJSON (Stage 3 Proposal) allows for the injection of raw JSON text, preventing the string quoting if a raw number is truly desired, though string serialization remains the safest interoperability path.[27]

6.4 The Absence of Infinity and NaN

In accordance with its strict definition, JSON does not support NaN (Not a Number), Infinity, or -Infinity. These are valid numeric values in IEEE 754 and JavaScript, but they are forbidden in JSON syntax.

If a JavaScript object contains NaN, JSON.stringify() will serialize it as null.
If a developer manually attempts to write {“value”: NaN}, the parser will throw a syntax error.[21]

7. Strings: Encoding, Escaping, and Unicode Complexity

A JSON string is a sequence of zero or more Unicode characters strictly enclosed in double quotes.[1] Single quotes are strictly forbidden—a common “gotcha” for Python and JavaScript developers accustomed to interchangeable quotes.

7.1 Mandatory Escape Sequences

While most Unicode characters can be placed literally within a string, a specific subset MUST be escaped. Failure to escape these characters renders the JSON invalid.[1]

Quotation Mark (”): Escaped as ”.
Reverse Solidus (Backslash) (): Escaped as \.
Control Characters: The range U+0000 through U+001F (C0 control codes) must be escaped. This includes null bytes, bells, backspaces, etc. They can be escaped via the standard single-character escapes (\b, \f, \n, \r, \t) or the generic Unicode escape \u00xx.[29]

The Bash Regex Failure:

Implementations often fail to strictly enforce the control character escaping. For example, some regex-based parsers might use [:cntrl:] classes which include U+007F (DEL). However, JSON spec does not require DEL to be escaped, leading to discrepancies where valid JSON is rejected by over-zealous validators.[31]

7.2 The Solidus (/) Ambiguity and XSS

Developers often observe the forward slash being escaped as / in JSON output (e.g., http://example.com), despite the RFC stating that escaping the solidus is optional.[32]

The Rationale (HTML Injection):

The escaping of the solidus is a security defense-in-depth measure. Consider a JSON blob embedded directly into an HTML page:

<script>
    var data = {"content": "</script><script>alert('XSS')</script>"};
</script>

The HTML parser scans for the </script> closing tag before the JavaScript engine parses the string. The sequence </script> inside the JSON string would prematurely close the script block, allowing the malicious payload following it to execute as raw HTML/JS.

By escaping the slash to </script>, the sequence is broken. The HTML parser does not see a closing tag, but the JSON parser interprets / simply as /, preserving the data while neutralizing the XSS vector.[1]

7.3 Unicode, Surrogate Pairs, and Emojis

JSON strings are sequences of Unicode code points. For characters in the Basic Multilingual Plane (BMP, U+0000 to U+FFFF), a single 4-digit hex escape \uXXXX is sufficient.

However, modern applications frequently use characters from the Supplementary Planes, such as Emojis (e.g., 🤦, U+1F926) or rare musical symbols. Since JSON’s \u escape syntax supports only 4 hex digits, characters with code points above U+FFFF must be represented as a UTF-16 Surrogate Pair.[33]

The Mechanism:

To encode U+1F926 (🤦):

Subtract 0x10000 from the code point: 0x1F926 - 0x10000 = 0xF926.
Represent the result in 20 bits: 0000 1111 1001 0010 0110.
Split into top 10 bits (0000111110 = 0x03E) and bottom 10 bits (0100100110 = 0x126).
Add top bits to 0xD800 (High Surrogate): 0xD800 + 0x03E = 0xD83E.
Add bottom bits to 0xDC00 (Low Surrogate): 0xDC00 + 0x126 = 0xDD26.
Resulting JSON: “\uD83E\uDD26”.

Common Implementation Error:

Attempting to use \u1F926 (5 digits) or \U1F926 (capital U, common in C/Python) is invalid in JSON. The format strictly recognizes only \u followed by exactly 4 hex digits. Failing to correctly calculate surrogate pairs leads to corrupted characters (mojibake) or “Unpaired Surrogate” errors in strict parsers.[36]

8. The “Missing” Features: Intentional Exclusions

To maintain its status as a platform-independent data format, JSON intentionally lacks several features found in JavaScript and configuration languages like YAML or TOML.

8.1 The Prohibition of Comments

Comments (// or /* */) are strictly forbidden in JSON.9 This is perhaps the most requested and most denied feature in the history of the format.

Douglas Crockford, the creator of JSON, explicitly removed comments to prevent the format from adopting “parsing directives.” He observed that if comments were allowed, developers would start using them to embed metadata or instructions for the parser (e.g., // @type: Integer), creating non-standard dialects that would destroy interoperability.

Implication:

JSON should not be used for configuration files where human documentation is necessary, unless a pre-processor (like JSON5 or a distinct stripping script) is used before the file reaches the standard JSON parser.[8]

8.2 The “Trailing Comma” Restriction

JSON does not allow a comma after the last element in an array or the last member of an object.

Invalid: {“a”: 1, “b”: 2,}
Invalid: [1, 2, 3,]

This restriction is a legacy artifact of the ECMAScript 3 specification and early browser quirks. Specifically, Internet Explorer 8 (and older) had a bug where a trailing comma in an array definition [1, 2,] would result in an array of length 3 (with the last element being undefined), whereas other browsers created an array of length 2. To ensure consistent behavior across all platforms, trailing commas were banned in the JSON standard.[41]

While ES5 and modern JavaScript now support trailing commas to simplify Git diffs and code generation, standard JSON remains frozen in the older syntax. Developers using linters like Prettier must ensure they are configured to remove trailing commas for JSON files.[43]

8.3 No Date Type

JSON has no native data type for dates. This is a deliberate design choice to avoid the immense complexity of time zones, leap seconds, and varying calendar systems.

The ISO 8601 Standard:

The nearly universal convention is to serialize dates as Strings formatted according to ISO 8601.

Format: YYYY-MM-DDThh:mm:ss.sssZ
Example: “2023-10-27T14:30:00Z”

Using this format ensures that dates are human-readable, unambiguous (the Z suffix explicitly denotes UTC), and lexicographically sortable (string sorting matches chronological sorting).

Warning: The JavaScript Date.prototype.toJSON() method automatically converts dates to this ISO string format. However, other languages may default to different serializations (e.g., Python’s default json serializer does not handle standard datetime objects and throws an error unless a custom encoder is used).[45]

9. Comparative Syntax: JSON vs. JavaScript

For students and developers, the mental model that “JSON is JS” is the primary source of syntax errors. The following comparison highlights the divergences that break parsers.[9]

Feature	JSON Standard	JavaScript Object Literal
Keys	Must be double-quoted strings {"key": 1}.	Can be unquoted {key: 1} or quoted.
String Quotes	Double quotes only "string".	Single ' or double " allowed.
Trailing Commas	Forbidden.	Allowed (ES5+).
Comments	Forbidden.	Allowed (// and /* */).
Values	String, Number, Bool, Null, Object, Array.	Any expression (Functions, undefined, Symbols).
Numbers	Base-10 only. No leading zeros.	Hex (0x), Octal (0o), Binary (0b) allowed.
Literals	true, false, null (lowercase).	Case-sensitive, but mapped to language primitives.
Undefined	Not supported. Property omitted.	Supported undefined value.

10. Security and Parsing Edge Cases

10.1 The “Billion Laughs” and Depth Limits

While JSON does not have a formal limit on nesting depth, parsers run on finite hardware. Deeply nested objects (e.g., [[[[…]]]]) can cause stack overflow errors in recursive parsers. This can be weaponized in a Denial of Service (DoS) attack.

Similarly, a “Billion Laughs” style attack can be constructed using extremely long number strings or repeated string escapes, forcing the parser to allocate massive amounts of memory.

Defense: Robust JSON parsers typically impose a default depth limit (often 512 or 1024 levels) and a string length limit to mitigate these risks.[25]

10.2 JSON Polyglots and Hijacking

Valid JSON can sometimes be interpreted as valid JavaScript code. For example, {“x”: 1} is a valid block statement in JavaScript with a label x and value 1. Historically, this ambiguity allowed attackers to load JSON endpoints via <script> tags and override the Array constructor to steal data (JSON Hijacking).

This is why modern APIs must require application/json headers and often use “unexecutable prefixes” (like )]}’,\n) to prevent the JSON from being executed as a script if accidentally loaded by a browser.[7]

11. Ultimate Reference Cheat Sheet

This section consolidates the rules into a quick-reference format for validation.

11.1 Valid vs. Invalid Syntax Examples

Category	Example	Status	Explanation
Strings	{"name": "O'Reilly"}	Valid	Single quote inside double quotes is treated as a literal.
Strings	{'name': 'John'}	Invalid	Single quotes cannot be used as delimiters.
Numbers	{"cost": 10.50}	Valid	Standard floating point.
Numbers	{"cost":.5}	Invalid	Leading decimal point is forbidden; must be 0.5.
Numbers	{"code": 0123}	Invalid	Leading zero is forbidden (prevents octal ambiguity).
Numbers	{"val": +5}	Invalid	Explicit plus sign is forbidden.
Numbers	{"val": 1.}	Invalid	Trailing decimal point is forbidden; must be 1.0.
Booleans	{"active": true}	Valid	Strictly lowercase literal.
Booleans	{"active": True}	Invalid	Capitalized literal is treated as an unknown identifier.
Lists	``	Valid	Standard array.
Lists	[1, 2, 3,]	Invalid	Trailing comma is forbidden.
Objects	{"id": 1, "val": 2}	Valid	Standard object.
Objects	{id: 1, val: 2}	Invalid	Unquoted keys are forbidden.

11.2 Character Escape Reference

When constructing JSON strings manually, ensure these characters are handled:

Character	ASCII/Unicode	JSON Escape Sequence
"	0x[22]	\"
**	0x5C	\\
Backspace	0x[08]	\b
Form Feed	0x0C	\f
Newline	0x0A	\n
Carr. Return	0x0D	\r
Tab	0x[09]	\t
Control Chars	0x00-0x1F	\u00xx (e.g., \u0000)

11.3 Decision Matrix for Developers

Need to store a Date? Use ISO 8601 String (“2023-01-01T12:00:00Z”).
Need to store a 64-bit Integer? Serialize as a String to prevent IEEE 754 precision loss.
Need comments? You cannot use them. Store metadata in a separate field (e.g., “_comment”: ”…”) or use a distinct format.
Need unique keys? Enforce uniqueness at the generation stage; do not rely on the parser to handle duplicates consistently.
Need binary data? Base64 encode it into a String.

Conclusion

JSON’s ubiquity is driven by its accessibility, but its reliability is predicated on strict adherence to the grammar constraints outlined in RFC 8259. The format is intolerant by design: a single trailing comma, a capitalized boolean, or an unescaped control character renders an entire payload invalid.

For the Lead Developer and the Architect, the mandate is clear: treat JSON not as a flexible text format, but as a rigid data protocol. Implement strict validation, respect the limitations of numeric types, and ensure all generators produce RFC-compliant output. By doing so, we safeguard the integrity of the data that powers our distributed systems.

Sources

RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format, accessed: november 23, 2025, https://datatracker.ietf.org/doc/html/rfc8259
ECMA-404 - Ecma International, accessed: november 23, 2025, https://ecma-international.org/publications-and-standards/standards/ecma-404/
The JSON Data Interchange Syntax - Ecma International, accessed: november 23, 2025, https://ecma-international.org/wp-content/uploads/ECMA-404_2nd_edition_december_2017.pdf
RFC 7159 - The JavaScript Object Notation (JSON) Data Interchange Format, accessed: november 23, 2025, https://datatracker.ietf.org/doc/html/rfc7159
RFC 4627 - The application/json Media Type for JavaScript Object Notation (JSON), accessed: november 23, 2025, https://datatracker.ietf.org/doc/html/rfc4627
JSON - Wikipedia, accessed: november 23, 2025, https://en.wikipedia.org/wiki/JSON
Which JSON content type do I use? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/477816/which-json-content-type-do-i-use
Douglas Crockford explains why he removed comments from JSON : r/programming - Reddit, accessed: november 23, 2025, https://www.reddit.com/r/programming/comments/t0gub/douglas_crockford_explains_why_he_removed/
What is the difference between JSON and Object Literal Notation? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/2904131/what-is-the-difference-between-json-and-object-literal-notation
JSON Data Types - REST API Tutorial, accessed: november 23, 2025, https://restfulapi.net/json-data-types/
Handling JSON objects with duplicate names in Python - alexwlchan, accessed: november 23, 2025, https://alexwlchan.net/2025/duplicate-names-in-json/
Does JSON syntax allow duplicate keys in an object? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object
JSON with Duplicate Key Entries are not Handled Appropriately by JSON Schema Validator, accessed: november 23, 2025, https://help.salesforce.com/s/articleView?id=001117815&language=en_US&type=1
Consider erroring on JSON duplicate keys instead of “last value wins” #34 - GitHub, accessed: november 23, 2025, https://github.com/iancoleman/orderedmap/issues/34
Number Handling - JSON for Modern C++, accessed: november 23, 2025, https://json.nlohmann.me/features/types/number_handling/
Why is JSON invalid if an integer begins with a leading zero? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/27361565/why-is-json-invalid-if-an-integer-begins-with-a-leading-zero
Error parsing JSON. Unexpected character (’+’ (code 43)) in numeric value - Mendix Support, accessed: november 23, 2025, https://support.mendix.com/hc/en-us/articles/23456195818268-Parsing-JSON-with-Positive-Number-Error-parsing-JSON-Unexpected-character-code-43-in-numeric-value
serialize JSON with plus sign results in invalid JSON - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/18833564/serialize-json-with-plus-sign-results-in-invalid-json
Does JSON allow positive sign for numbers? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/26667313/does-json-allow-positive-sign-for-numbers
Common JSON Mistakes and How to Avoid Them - JSONLint, accessed: november 23, 2025, https://jsonlint.com/common-mistakes-in-json-and-how-to-avoid-them
SyntaxError: JSON.parse: bad parsing - JavaScript - MDN Web Docs, accessed: november 23, 2025, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/JSON_bad_parse
Safely Handling Large Integers in JSON: Best Practices and Pitfalls - HackerOne, accessed: november 23, 2025, https://www.hackerone.com/blog/safely-handling-large-integers-json-best-practices-and-pitfalls
Try passing around 64bit integers in json. The majority of json implementations … | Hacker News, accessed: november 23, 2025, https://news.ycombinator.com/item?id=15516652
What is the accepted way to send 64-bit values over JSON? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/209869/what-is-the-accepted-way-to-send-64-bit-values-over-json
Numbers Are Numbers, Not Strings | json-everything, accessed: november 23, 2025, https://blog.json-everything.net/posts/numbers-are-numbers-not-strings/
TypeError: BigInt value can’t be serialized in JSON - JavaScript - MDN Web Docs, accessed: november 23, 2025, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/BigInt_not_serializable
Stringify BigInt as a number instead of string - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/77829479/stringify-bigint-as-a-number-instead-of-string
Can you use a trailing comma in a JSON object? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/201782/can-you-use-a-trailing-comma-in-a-json-object
escape u0000 .. u001F when outputting json - Patchwork - OzLabs, accessed: november 23, 2025, https://patchwork.ozlabs.org/comment/105058/
How FOR JSON Escapes Special Characters and Control Characters - SQL Server | Microsoft Learn, accessed: november 23, 2025, https://learn.microsoft.com/en-us/sql/relational-databases/json/how-for-json-escapes-special-characters-and-control-characters-sql-server?view=sql-server-ver17
Parsing JSON is a Minefield - Nicolas Seriot, accessed: november 23, 2025, https://seriot.ch/projects/parsing_json.html
JSON: RFC8259 Escape forward slash or not? - Software Engineering Stack Exchange, accessed: november 23, 2025, https://softwareengineering.stackexchange.com/questions/444480/json-rfc8259-escape-forward-slash-or-not
How can I set text with JSON encoded emojis using DQL? - Discuss Dgraph, accessed: november 23, 2025, https://discuss.dgraph.io/t/how-can-i-set-text-with-json-encoded-emojis-using-dql/13459
Write & read emoji to/from file using json - JUCE Forum, accessed: november 23, 2025, https://forum.juce.com/t/write-read-emoji-to-from-file-using-json/62136
How to Create a UTF-16 Surrogate Pair by Hand, with Python - Oil Shell, accessed: november 23, 2025, https://www.oilshell.org/blog/2023/06/surrogate-pair.html
JSON decode of Unicode escape sequence: cannot handle more than 4 hex digits?, accessed: november 23, 2025, https://forums.swift.org/t/json-decode-of-unicode-escape-sequence-cannot-handle-more-than-4-hex-digits/56138
JQ can’t parse an Unicode emoji character. Is it valid JSON? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/42457416/jq-cant-parse-an-unicode-emoji-character-is-it-valid-json
How can I convert surrogate pairs to normal string in Python? - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/38147259/how-can-i-convert-surrogate-pairs-to-normal-string-in-python
Comments - JSON for Modern C++, accessed: november 23, 2025, https://json.nlohmann.me/features/comments/
Why JSON doesn’t allow comments (and what you can do about it) | by Mary Crivelli, accessed: november 23, 2025, https://medium.com/@marycriv/why-json-doesnt-allow-comments-fe93f7106c62
Trailing commas in object literals and array literals - 2ality, accessed: november 23, 2025, https://2ality.com/2013/07/trailing-commas.html
Best practices for using trailing commas in JavaScript - LogRocket Blog, accessed: november 23, 2025, https://blog.logrocket.com/best-practices-using-trailing-commas-javascript/
What is the issue with the trailing comma of JSON Object - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/58954457/what-is-the-issue-with-the-trailing-comma-of-json-object
Trailing commas - JavaScript - MDN Web Docs, accessed: november 23, 2025, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Trailing_commas
JSON Date Format: A Guide to Handling Dates in APIs - Itexus, accessed: november 23, 2025, https://itexus.com/json-date-format-a-guide-to-handling-dates-in-apis/
ISO 8601 - Wikipedia, accessed: november 23, 2025, https://en.wikipedia.org/wiki/ISO_8601
What is the “right” JSON date format? - javascript - Stack Overflow, accessed: november 23, 2025, https://stackoverflow.com/questions/10286204/what-is-the-right-json-date-format
Javascript Objects Vs JSON: Explained Simply | Appsmith Community Portal, accessed: november 23, 2025, https://community.appsmith.com/content/blog/javascript-objects-vs-json-explained-simply
JSON vs JavaScript Object Literals: Key Differences with Examples - Intellipaat, accessed: november 23, 2025, https://intellipaat.com/blog/json-vs-javascript-object-literal/