JSON Formatter & Syntax Validator

JSON syntax: formatting, validation, and debugging

JSON is a data format, not JavaScript

JSON (JavaScript Object Notation) has a deliberately small grammar. A JSON document must contain a valid JSON value: an object, array, string, number, true, false, or null. The most common top-level forms are objects and arrays. JSON property names must use double quotes, strings must use double quotes, and structural punctuation must be placed exactly where the grammar expects it.

JavaScript object literals are not automatically valid JSON. For example, {name: "Ada"} is valid-looking JavaScript syntax but invalid JSON because the property name is not quoted. Likewise, comments, trailing commas, undefined, functions, and single-quoted strings are not part of standard JSON syntax.

Format versus validate

Formatting changes presentation; validation checks syntax. This tool calls the browser’s native JSON parser first. If parsing succeeds, the value can safely be serialized again with predictable indentation. Formatting therefore does not “repair” arbitrary broken JSON: invalid input must first be corrected enough for the parser to accept it.

{
  "user": {
    "id": 42,
    "name": "Ada"
  },
  "roles": ["admin", "editor"]
}

The same data can be minified into a compact representation:

{"user":{"id":42,"name":"Ada"},"roles":["admin","editor"]}

Minification removes insignificant whitespace. It does not make invalid syntax valid and it does not reduce the semantic size of the underlying data.

Step 1: Paste the exact payload

When debugging an API response, copy the raw body rather than manually retyping it. Retyping can remove the character that caused the error or introduce a second error. Paste the complete payload into the input editor, then select Format / Validate.

If parsing succeeds, the tool displays normalized JSON using the selected indentation. The serializer may change whitespace and formatting, but it preserves the parsed data types. A number remains a number, a boolean remains a boolean, and null remains JSON null.

Step 2: Read parser errors systematically

Messages such as “Unexpected token” are symptoms of a grammar mismatch. Start at the reported line and column, then inspect the character immediately before the location as well. A missing comma, quote, or closing bracket often causes the parser to complain at the next token rather than at the original mistake.

Common invalid JSON examples

Unquoted property:

{name: "Ada"}

Correct:

{"name": "Ada"}

Single quotes:

{'name': 'Ada'}

Correct:

{"name": "Ada"}

Trailing comma:

{
  "name": "Ada",
}

Correct:

{
  "name": "Ada"
}

Comments:

{
  "name": "Ada", // developer note
  "active": true
}

Correct:

{
  "name": "Ada",
  "active": true
}

Strings, escapes, and Unicode

JSON strings use double quotes. Special characters are represented with JSON escapes such as \" for a quotation mark, \\ for a backslash, \n for a line feed, and Unicode escapes such as \u00A9. A literal unescaped control character inside a string is invalid. If an API payload contains embedded quotes, inspect whether they are properly escaped rather than simply adding more quotation marks around the whole value.

Do not confuse JSON escaping with URL encoding, HTML escaping, or JavaScript string escaping. Those are separate transformations. A JSON string can contain a URL without URL-encoding it merely because it appears inside JSON.

Numbers and special values

JSON numbers do not support JavaScript conveniences such as NaN or Infinity. JSON uses true, false, and null as literals. If a backend needs to represent a value that is not naturally representable as JSON, the API contract should define a string or another explicit representation.

Formatting does not validate your business rules

A document can be syntactically valid and still be wrong for an API. For example, this is valid JSON:

{"age":"forty-two"}

An API expecting age to be a number may reject it even though the JSON parser accepts it. This distinction is important: syntax validation answers “Can this text be parsed as JSON?” Schema validation answers “Does the parsed value match the required structure, types, fields, and constraints?”

Large files and browser limits

The tool is designed for ordinary developer payloads and uses in-memory browser parsing. Very large JSON files consume memory because the browser holds the input, parsed value, and formatted output. For multi-hundred-megabyte datasets, use a streaming parser or command-line tooling rather than pasting the entire file into a browser editor.

Why client-side processing protects payload privacy

The formatter uses the browser’s built-in JSON parsing and serialization APIs. The input does not need to be sent to a formatting server, which makes the architecture appropriate for sensitive development payloads such as private API responses, configuration files, and test fixtures.

Client-side processing does not make every deployment automatically private. If the page adds analytics, session recording, advertising scripts, browser extensions, or other third-party code, those systems can have their own data flows. For sensitive JSON, audit the complete page and its network requests rather than relying only on the fact that the formatter itself is client-side.

Practical debugging workflow

1. Copy the original JSON response without manually editing it.
2. Paste it into the validator and run Format / Validate.
3. Read the reported line and column; inspect the preceding token too.
4. Look specifically for missing commas, extra commas, mismatched brackets, unescaped quotes, single quotes, comments, and unquoted keys.
5. Validate again after each logical correction instead of making many unrelated edits at once.
6. Once syntax is valid, check the API’s schema, required fields, value types, and business constraints separately.
7. Use Minify only when compact transport/storage is actually required.