JSON Formatter & Validator

Eight JSON spec gotchas that will bite you

JSON looks deceptively simple. The JSON specification (RFC 8259) is deliberately minimal, and several things that work fine in JavaScript are silent or fatal errors in JSON. Here are the eight that catch developers most often.

1. Trailing commas are not allowed

This is the most common JSON error. It works in JavaScript and most modern config formats, so developers type it by muscle memory.

// INVALID JSON — trailing comma after last item
{
  "name": "Alex",
  "role": "engineer",  ← this comma kills it
}

// VALID JSON
{
  "name": "Alex",
  "role": "engineer"
}

The same rule applies to arrays. A trailing comma after the last element — [1, 2, 3,] — is invalid JSON even though it is valid JavaScript since ES2017.

2. Keys and strings must use double quotes

JSON requires double quotes. Single quotes are JavaScript shorthand that does not exist in the spec. Unquoted keys are also invalid JSON.

// INVALID — single quotes and unquoted keys
{ 'name': 'Alex' }
{ name: "Alex" }

// VALID
{ "name": "Alex" }

3. JSON has no comment syntax

Douglas Crockford deliberately excluded comments from JSON to prevent the format from being used as a configuration file. Neither // line comments nor /* block comments */ are valid. If you need commented JSON configs, use JSONC (supported in VS Code and TypeScript) or YAML.

4. Undefined and functions are silently dropped by JSON.stringify()

This one does not throw an error — it silently loses your data.

const obj = {
  name: "Alex",
  callback: () => {}, // dropped silently
  age: undefined,       // dropped silently
  score: null,          // kept as null
};
JSON.stringify(obj);
// → '{"name":"Alex","score":null}'

The round-trip through JSON.stringify → JSON.parse is not always lossless. If a field is missing from your API payload, check whether it was undefined on the JavaScript side.

5. Large integers lose precision

JSON numbers map to IEEE 754 64-bit floats. Integers larger than Number.MAX_SAFE_INTEGER (9,007,199,254,740,991) cannot be represented exactly. Twitter switched from numeric IDs to strings for exactly this reason. The fix: pass large integers as strings in JSON and parse with BigInt on the client.

6. Duplicate keys are technically valid — but dangerous

RFC 8259 says keys "SHOULD" be unique — not "MUST." Duplicate keys are not a parse error, but different parsers handle them differently (first value, last value, or error). This formatter accepts them, matching browser behaviour. Avoid them in production.

7. JSON has no native Date type

JSON.stringify(new Date()) converts to an ISO 8601 string. JSON.parse() does NOT convert it back — you get a string, not a Date object. You must explicitly parse it: new Date(data.createdAt). This is one of the most common sources of type bugs in JavaScript APIs.

8. Control characters must be escaped

Literal tab (\t), newline (\n), and carriage return (\r) characters inside JSON strings must be backslash-escaped. JSON.stringify() handles this automatically. Problems arise when JSON is constructed by string concatenation rather than a proper serialiser.

When to use jq instead of a browser formatter

This tool handles files up to ~10MB comfortably. For large files, API response streams, or scripted transformations, use jq — the command-line JSON processor.

# Prettify a file
jq . data.json

# Minify
jq -c . data.json

# Extract a field
jq '.users[].email' data.json

# Pipe from curl
curl -s https://api.example.com/data | jq .

Frequently Asked Questions