Need help with your JSON?

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

The Standardization of JSON and Its Effect on Formatting Tools

JSON looks simple, but the difference between data that merely resembles JSON and data that is safe to exchange across browsers, servers, CLIs, and APIs comes from standardization. For a formatter, that matters more than indentation style. A trustworthy tool needs to know which rules are fixed, which edge cases are technically valid but risky, and which relaxed inputs belong to JSON5 rather than standard JSON.

Today, the most important references are RFC 8259, which defines the current IETF JSON standard, ECMA-404, which stays aligned with the core grammar, and RFC 7493 (I-JSON), which defines a stricter interoperability profile. Together, they explain why one formatter accepts a payload, another rejects it, and a third prettifies it while still leaving portability problems behind.

Which JSON standards matter now?

RFC 8259: The current IETF standard for JSON. It defines the grammar for valid JSON text and adds interoperability guidance for parsers, generators, encoding, numbers, and object member names.
ECMA-404: A companion JSON specification focused on the syntax itself. RFC 8259 explicitly says the two documents are intended to stay aligned.
RFC 7493 (I-JSON): A stricter profile for internet-facing use. It tightens expectations around UTF-8, duplicate member names, and safe number handling.

That distinction matters because not every tool marketed as a JSON formatter is equally strict. Some tools target standard JSON only. Others accept extensions such as comments or trailing commas on input, then output clean RFC 8259 JSON. Both behaviors can be useful, but they solve different problems.

What standardization requires from formatting tools

At a minimum, a standard-compliant formatter is a parser plus a serializer. It reads input according to JSON grammar, builds an internal representation, and writes it back out without changing the meaning of the data. Standardization gives that workflow hard boundaries.

What a strict formatter should enforce

Only valid JSON tokens are accepted: objects, arrays, strings, numbers, true, false, and null.
Strings use double quotes, with proper escaping for control characters and backslashes.
Numbers cannot use leading zeros, NaN, or Infinity.
Comments and trailing commas are rejected in strict mode because they are not part of standard JSON.
Output remains valid JSON after reserialization. The formatter may change whitespace, but it should not silently invent non-standard syntax.

One subtle point from RFC 8259 is especially useful in practice: parsers may choose to accept non-standard extensions, but generators are expected to produce strict JSON. That is why some tools can clean up comment-heavy config files and still emit valid JSON for downstream systems.

Where compliant tools can still disagree

Standardization reduces ambiguity, but it does not erase every interoperability trap. Several areas still matter when you compare formatters, validators, and parsers.

1. Duplicate object keys

RFC 8259 says object member names should be unique, not that parsers must reject duplicates. As a result, one implementation may keep the last value, another may keep the first, and another may report an error. A pretty-printer can make duplicated keys look neat while still leaving the payload semantically unsafe.

2. Top-level scalars

Modern JSON allows any serialized value at the top level, not only an object or array. That means"ok", 42, and null are valid JSON texts. Older libraries and older API expectations still sometimes reject them, so a formatter may accept input that a legacy consumer later refuses.

3. Large numbers and precision

JSON grammar allows very large numeric literals, but RFC 8259 notes that interoperability is best when numbers stay within the exact integer range of IEEE 754 double precision, roughly -(2**53)+1 through (2**53)-1. A formatter can preserve the text of a number, but once another system parses it into a native number type, precision may already be gone. For identifiers, money subunits, or 64-bit database keys, strings are often safer than numeric JSON values.

4. Encoding and Unicode edge cases

For systems that are not part of a closed ecosystem, JSON exchanged over the network should be UTF-8. Formatters also need to handle escape sequences correctly and avoid introducing invalid Unicode data. In real workflows, this matters when files arrive with a BOM, mixed encodings, or broken surrogate pairs from copy-paste or legacy exports.

5. Member ordering and stable output

JSON objects are not defined by a mandatory key order, so the standard does not prescribe one canonical pretty-printed form. One formatter may preserve source order, another may sort keys if asked, and both can still be standards-compliant. If you need byte-for-byte stable output for hashing, signatures, golden files, or deterministic diffs, pretty-printing alone is not enough. You need an explicit canonicalization or stable-sort strategy.

Examples that reveal real formatter behavior

These examples are useful because they separate syntax validity from interoperability. A good JSON formatter should help you spot both.

Valid JSON that can still be unsafe

{
  "invoiceId": 9007199254740993,
  "status": "draft",
  "status": "final"
}

This is syntactically valid JSON, but it contains both a precision-risk number and a duplicate key. A basic pretty-printer may format it without complaint. A better validator should warn that different consumers may interpret it differently.

Valid JSON text that older tooling may reject

"ok"

A top-level string is valid JSON under modern standards, but some older validators and integrations still assume the top level must be an object or array.

Not standard JSON

{
  // comment
  user: 'alice',
  limit: Infinity,
}

Comments, unquoted keys, single-quoted strings, trailing commas, and Infinity belong to relaxed formats such as JSON5, not to standard JSON.

JSON vs. JSON5: why many tools seem inconsistent

A lot of confusion around JSON formatters is really confusion between standard JSON and JSON5-style input. JSON5 is intentionally more human-friendly for hand-edited files. It allows features such as comments, trailing commas, identifier-style keys, single-quoted strings, hexadecimal numbers, and values like Infinity or NaN.

That does not make JSON5 wrong. It simply makes it a different format with a different compatibility target. If your destination is an API, database import, browser fetch response, or a strict parser in another language, output needs to be standard JSON. When choosing a formatter, check whether it is:

strict on input and strict on output, or
relaxed on input but strict on output after cleanup.

A practical checklist for JSON formatting tools

Reject or clearly flag duplicate keys instead of prettifying them silently.
Report exact line and column for invalid tokens, missing commas, and broken strings.
State whether top-level scalars are accepted and whether output is always RFC 8259-compliant.
Handle UTF-8 cleanly and make BOM behavior explicit.
Preserve member order by default unless the user explicitly asks to sort keys.
Warn about precision risks when numeric values exceed safe integer range.
Separate normal pretty-printing from any canonicalization or stable serialization mode.

Bottom line

JSON standardization did not just make parsers possible. It made formatter behavior testable and comparable. RFC 8259 defines what valid JSON is, ECMA-404 keeps the core syntax aligned, and I-JSON shows what a safer interoperability baseline looks like. The best formatting tools use those rules to do more than add indentation: they help you catch duplicate names, non-standard extensions, encoding problems, and portability bugs before those problems escape into production.

Need help with your JSON?

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