JSON Formatter and Validator

About this JSON formatter and validator

This JSON formatter checks your text against the JSON standard, then pretty prints it with 2 or 4 spaces or minifies it. When the JSON is invalid, the validator gives the line, column and character where it stopped, says which rule was broken and points at it with a caret. It also warns about duplicate keys and numbers too large for JavaScript, which pass validation but change your data. Nothing you paste is uploaded.

How to use it

1. Paste your JSON. A short sample with one mistake is loaded so you can see an error report.
2. Click Format (2 or 4 spaces), Minify, or Validate only to check without changing anything.
3. Fix the error at the line and column shown and run it again. Only the first error is reported, because after it the parser can't know what you meant.
4. Copy the result.

How the error line and column are found

Formatting uses the browser's own JSON.parse() and JSON.stringify(). When parsing fails, the browser's message varies: some give a character position, some a line and column, some only quote your text, and the wording changes between engines and versions. So this page re-reads your text with its own scanner, which follows the grammar in RFC 8259 one character at a time and keeps a stack of the brackets that are still open. It stops at the first character the grammar doesn't allow. Lines are counted at every line break (LF, CRLF or a lone CR); columns count characters from 1, with a tab as one character. The browser's message is shown underneath for reference.

The position is where the JSON stopped being valid, often just after the real mistake: a missing comma is reported at the next value, and a missing closing quote at the end of its line.

Worked example

The sample in the box is:

{
  "id": 9007199254740993,
  "name": "Ana",
  "roles": ["admin", "editor",],
  "active": true
}

The page checks it as soon as it loads and reports Invalid JSON: line 4, column 31, which is the ] after "editor",. The message reads "Trailing comma: remove the comma at line 4, column 30 before ]." Delete that comma and click Format (2 spaces). The result is:

{
  "id": 9007199254740992,
  "name": "Ana",
  "roles": [
    "admin",
    "editor"
  ],
  "active": true
}

The ID changed by one, and the page warns: "Line 2, column 9: 9007199254740993 is beyond Number.MAX_SAFE_INTEGER and is written as 9007199254740992." Click Minify instead and the same data becomes one 77-character line: {"id":9007199254740992,"name":"Ana","roles":["admin","editor"],"active":true}.

JSON validator rules: what RFC 8259 doesn't allow

Most invalid JSON is valid JavaScript, or valid in a looser format such as JSON5. The validator gives a specific message for each of these common mistakes.

RFC 8259 says leading zeros are not allowed, that values such as Infinity and NaN are not permitted, and that the quotation mark, the backslash and the control characters U+0000 to U+001F must be escaped inside a string. Its grammar has no comment syntax. Whitespace between values can only be a space, tab, line feed or carriage return, so a no-break space pasted from a web page is an error. The standard lets parsers accept extensions, which is why some config loaders tolerate comments or trailing commas; JSON.parse() and this validator don't.

Validating vs formatting, 2 vs 4 spaces, and minifying

Validating answers one question: is this text JSON? Formatting parses the text into data and writes it back out, so the result is always valid but not a byte-for-byte copy of your input (see below). Whitespace around structural characters is insignificant, so 2-space, 4-space and minified versions parse to the same data. Two spaces keeps deep nesting from drifting right; four is easier to scan. Pick one per project. In code, JSON.stringify(data, null, 2) matches the 2-space button; per MDN, numbers above 10 are treated as 10 and "\t" indents with tabs. Minifying removes all whitespace outside strings. Note that validation checks syntax only: a missing required key needs a schema to catch.

JSON escape characters

The only escapes JSON allows. Anything else after a backslash, like \x41 or \', is an error.

Why formatted output can differ from your input

• Large integers lose precision. JavaScript numbers are 64-bit floating point. Number.MAX_SAFE_INTEGER is 2⁵³ − 1, or 9,007,199,254,740,991, and integers above it can't all be stored exactly. A number too large for a double at all, such as 1e400, becomes null. The page warns about both. Send 64-bit IDs as strings.
• Spelling is normalized. 1.0 becomes 1, 1e2 becomes 100, and "caf\u00e9" becomes "café".
• Integer-like keys move to the front. JavaScript orders keys that look like array indexes first, so {"b":1,"2":0,"1":0} is written as {"1":0,"2":0,"b":1}.
• Duplicate keys collapse. {"a":1,"a":2} becomes {"a":2}, and the page warns you.

Common mistakes and limits

• Windows paths. "C:\users" fails because \u starts a Unicode escape. Worse, "C:\new\folder" is valid and silently contains a line feed and a form feed. Double every backslash: "C:\\new\\folder".
• Several documents at once. A JSON text holds exactly one value. A log with one object per line fails with "after the end of the JSON value"; validate one line at a time, or wrap the objects in [ ] with commas.
• A byte order mark. JSON.parse() rejects one at the start of the text, and RFC 8259 says not to add one. The validator flags it at line 1, column 1.

To compare two payloads by path, use JSON Diff. To convert valid JSON, try JSON to CSV or JSON to XML (and JSON vs XML on when each fits); YAML to JSON converts YAML config so you can validate it here.