Docify

By Docify

Validate JSON Syntax with JSON.parse

• 5 min read

Load sample on the live JSON formatter fills the compact object {"name":"John Doe","age":30,"email":"john@example.com","address":{"street":"123 Main St","city":"New York","country":"USA"},"hobbies":["reading","coding","gaming"]} and does not run Prettify, Minify, or Validate. Validate then runs the same JSON.parse then JSON.stringify(value, null, 2) path as Prettify: it writes the matching 2-space JSON { "name": "John Doe", "age": 30, "email": "john@example.com", "address": { "street": "123 Main St", "city": "New York", "country": "USA" }, "hobbies": [ "reading", "coding", "gaming" ] } and the Valid JSON badge. age is the number 30. This is not the older users / Jane Smith / total leftover. A JSON syntax check is JSON.parse on the text. If parse throws, the string is not standard JSON — no comments, trailing commas, or JSON5. Infinity, -Infinity, and NaN are not JSON numbers, so those tokens fail parse. A complete exponent such as 1e309 overflows to Infinity; Prettify, Minify, and Validate then write null. 1e308 stays finite. 1e-324 underflows to 0. A leading-zero integer such as 01 is not a JSON number either — keep padded IDs as strings. A leading or trailing decimal such as .5 or 1. is also invalid — write 0.5 or 1.0. A plus-prefixed integer such as +1 is not a JSON number; plus is only legal in an exponent (1e+2). An incomplete exponent such as 1e or 1e+ is also invalid — the exponent needs one or more digits. A hexadecimal prefix such as 0x1 is also invalid — JSON numbers are decimal only. A literal line feed or tab inside a quoted string is also invalid — write \n or \t. Newlines between tokens are still whitespace. A JavaScript-style \x or incomplete \u escape inside a quoted string is also invalid — write \u plus four hex digits. Python True, False, and None are not JSON literals — write true, false, or null. JavaScript undefined is not a JSON literal either — write null or omit the key. A trailing comma before } or ] is also invalid — write {"ok":true} or [1]. A // or/* */ comment is also invalid — JSON whitespace is only space, tab, LF, and CR. Write{"ok":true} without comments. A single-quoted string such as 'hello' or{'ok':true} is also invalid — JSON strings use only U+0022. Write {"ok":"true"}. An apostrophe inside a double-quoted string is fine. An unquoted object key such as{ok:true} or {1:true} is also invalid — RFC 8259 §4 requires a string name. Write {"ok":true}. An unquoted value such as {"ok":yes} or yesis also invalid — RFC 8259 §3 allows only false, null, true, object, array, number, or string. Write {"ok":"yes"} or{"ok":true}. A JSON Lines / NDJSON dump is several values, one per line; one JSON.parse still fails after the first. Docify’s Validate button runs that parse in your browser, shows the parser error on failure, and does not upload the text.

Invalid JSON fails the first parse in an app, a pipeline, or a config loader. You do not need a custom grammar to catch the usual mistakes — the browser already implements ECMA-404. Use the JSON formatter Validate (or Prettify) button after you paste. Load sample fills the leftover compact object and does not run Validate. Validate then writes that same 2-space JSON and the Valid JSON badge.

Load sample Validate leftovers

Load sample fills this compact object and does not run Validate. Validate then writes the matching 2-space JSON and the Valid JSON badge. age is the number 30. This is the same stringify path as Prettify — not a parse-only check that leaves the output box empty.

{"name":"John Doe","age":30,"email":"john@example.com","address":{"street":"123 Main St","city":"New York","country":"USA"},"hobbies":["reading","coding","gaming"]}
{ "name": "John Doe", "age": 30, "email": "john@example.com", "address": { "street": "123 Main St", "city": "New York", "country": "USA" }, "hobbies": [ "reading", "coding", "gaming" ] }

Why Validate JSON?

  • 🐛Catch errors early - Find syntax errors before a deploy or a client parse
  • ⚡Read the parser message - Browsers include a position or token in e.message
  • ✅Stay on standard JSON - The same grammar works in every language’s strict parser
  • 🔒Avoid a thrown parse - Invalid text crashes JSON.parse and most language bindings

How to Validate JSON Online

Step 1: Paste Your JSON

Copy JSON from an API body, a config file, or a snippet and paste it into the formatter input.

Step 2: Click Validate

Docify runs JSON.parse when you click Validate, Prettify, or Minify. Load sample fills the leftover compact John Doe object and does not run those buttons. Validate then writes the matching 2-space JSON and the Valid JSON badge — the same stringify path as Prettify. A failure badge shows the browser error string. It does not re-check on every keystroke.

Step 3: Fix the token named in the error

Common fixes are listed below. After you edit, click Validate again. On success, Validate writes the 2-space serialization into the output box (the same JSON.stringify(value, null, 2) path as Prettify) and the Valid JSON badge.

Most Common JSON Syntax Errors

1. Trailing commas

Extra commas at the end of objects or arrays are invalid.

Invalid:

{"name": "John", "age": 30,}

Fixed:

{"name": "John", "age": 30}

2. Single quotes

JSON requires double quotes. Single quotes are not allowed.

Invalid:

{'name': 'John'}

Fixed:

{"name": "John"}

3. Unquoted keys

All object keys must be wrapped in double quotes.

Invalid:

{name: "John"}

Fixed:

{"name": "John"}

4. Missing commas

Items must be separated by commas.

Invalid:

{"name": "John" "age": 30}

Fixed:

{"name": "John", "age": 30}

5. Unescaped quotes in strings

A double quote inside a string must be escaped as \".

Invalid:

{"message": "She said "hello""}

Fixed:

{"message": "She said \"hello\""}

Infinity and NaN are not JSON numbers

RFC 8259 §6 and ECMA-404 allow only digit sequences (optional minus, fraction, and exponent). Numeric values that cannot be written that way — Infinity, -Infinity, and NaN — are not permitted. JSON.parse("Infinity") and JSON.parse("NaN") throw. Those tokens are JavaScript. If you already have a JavaScript Number, JSON.stringify(Infinity) is null, but Docify never reaches stringify for those tokens: Validate runs parse first. A digit-sequence overflow such as 1e309 is different. Use null or a string if you need a sentinel.

Invalid JSON (valid JavaScript):

{"n": Infinity}

Valid JSON sentinel:

{"n": null}

A complete exponent such as 1e309 becomes null after Prettify

RFC 8259 §6 allows implementations to limit numeric range. It names 1E400 as a number that may not interoperate. JavaScript JSON.parse uses IEEE-754 binary64. Number.MAX_VALUE is 1.7976931348623157e+308. JSON.parse("1e308") is finite. JSON.parse("1e309") is Infinity. Prettify, Minify, and Validate then run JSON.stringify, which writes null for a non-finite Number, so {"n":1e309} becomes {"n":null}. Validate still reports valid — parse succeeded. 1E309, 1e+309, and 10e308 are the same overflow. A quoted "1e309" stays the string. This is not the Infinity token. 1e-324 underflows to 0, not null. Write a string if the magnitude must survive.

Valid JSON that overflows on parse:

{"n":1e309}

Prettify / Minify / Validate output:

{"n":null}

Finite exponent (stays a number):

{"n":1e308}

Keep the magnitude as a string:

{"n":"1e309"}

Leading zeros are not JSON numbers

RFC 8259 §6 and ECMA-404 write the integer part as 0 or a non-zero digit plus more digits. Leading zeros are not allowed. JSON.parse("01") and JSON.parse('{"n":01}') throw, often with “Unexpected number”. 0 and 0.1 are valid; -01 is not. This is not C-style octal — 007 is not 7. Keep padded IDs as JSON strings ("007").

Invalid JSON (leading zero):

{"id": 007}

Valid JSON string:

{"id": "007"}

Leading or trailing decimals are not JSON numbers

RFC 8259 §6 and ECMA-404 write number = [ minus ] int [ frac ] [ exp ]. The integer part is required; a fraction is a decimal point plus one or more digits. JSON.parse(".5") and JSON.parse("1.") throw, often with “Unexpected token .” or “Unterminated fractional number”. 0.5 and 1.0 are valid; -.5 is not. JSON5 allows those forms; this page does not.

Invalid JSON (leading decimal):

{"n": .5}

Valid JSON number:

{"n": 0.5}

A leading plus is not a JSON number

RFC 8259 §6 and ECMA-404 write number = [ minus ] int [ frac ] [ exp ]. A leading plus is not allowed. Plus is only legal in the exponent: exp = e [ minus / plus ] 1*DIGIT. JSON.parse("+1") and JSON.parse('{"n":+1}') throw, often with “Unexpected token +”. -1 and 1e+2 are valid; +1 is not. JSON5 allows a leading plus; this page does not.

Invalid JSON (leading plus):

{"n": +1}

Valid JSON number:

{"n": 1}

An incomplete exponent is not a JSON number

RFC 8259 §6 and ECMA-404 write exp = e [ minus / plus ] 1*DIGIT. After e or E and an optional sign, one or more digits are required. JSON.parse("1e") and JSON.parse("1e+") throw, often with “Exponent part is missing a number”. JSON.parse('{"n":1e}') and JSON.parse('{"n":1e+}') do too. 1e2, 1e+2, and 1e-2 are valid; 1e- is not.

Invalid JSON (incomplete exponent):

{"n": 1e+}

Valid JSON number:

{"n": 1e+2}

A hexadecimal prefix is not a JSON number

RFC 8259 §6 and ECMA-404 write number = [ minus ] int [ frac ] [ exp ]. Digits are decimal only. A 0x or 0X prefix is not allowed. JSON.parse("0x1") and JSON.parse("0XFF") throw, often with “Unexpected non-whitespace character after JSON”, because parse accepts 0 and then hits x. JSON.parse('{"n":0x1}') throws too, often with “Expected ',' or } after property value”. 255 and 0 are valid; 0xFF is not. JSON5 allows hexadecimal numbers (0xdecaf); this page does not. Write a decimal or a string.

Invalid JSON (hexadecimal prefix):

{"n": 0xFF}

Valid JSON number:

{"n": 255}

A literal newline in a string is not JSON

RFC 8259 §7 and ECMA-404 require control characters U+0000–U+001F inside strings to be escaped. unescaped starts at space (%x20), so a literal line feed (U+000A) or tab (U+0009) is invalid. A parse of a string value that contains a raw line feed throws, often with “Bad control character in string literal”. Write the two-character escape \n or \t. Newlines between tokens are still whitespace (RFC 8259 §2), so pretty-printed objects are fine. This is not JSON Lines — that format puts a newline between values, not inside a quoted string.

Invalid JSON (literal line feed in the string):

{"s": "hello world"}

Valid JSON (escaped line feed):

{"s": "hello\nworld"}

A \x or incomplete \u escape is not JSON

RFC 8259 §7 and ECMA-404 allow only ", \, /, b, f, n, r, t, and \u plus exactly four hex digits after the backslash. JSON.parse("\x41") throws, often with “Bad escaped character in JSON” — JavaScript \xNN is not JSON. JSON.parse("\u12") and JSON.parse("\u") throw, often with “Bad Unicode escape in JSON”, because \u needs four hex digits. \' is also invalid. {"s":"\u00e9"} is valid (é after parse). This is not JavaScript string syntax.

Invalid JSON (JavaScript \x escape):

{"s": "\x41"}

Invalid JSON (incomplete \u escape):

{"s": "\u12"}

Valid JSON (four hex digits):

{"s": "\u0041"}

True and None are not JSON literals

RFC 8259 §3 and ECMA-404 allow only the lowercase names true, false, and null. No other literal names are allowed. JSON.parse("True") and JSON.parse("None") throw, often with “Unexpected token T” or “Unexpected token N”. {"ok":True} and {"ok":None} fail the same way. {"ok":true} and {"ok":null} are valid. Those uppercase tokens are Python. json.dumps writes the lowercase JSON names; a pasted repr of a dict does not.

Invalid JSON (Python literals):

{"ok": True, "missing": None}

Valid JSON (lowercase literals):

{"ok": true, "missing": null}

undefined is not a JSON literal

RFC 8259 §3 and ECMA-404 allow only the lowercase names true, false, and null. No other literal names are allowed. JSON.parse("undefined") and {"ok":undefined} throw, often with “Unexpected token u” or “is not valid JSON”. {"ok":null} is valid. undefined is a JavaScript name. JSON.stringify omits a key whose value is undefined, but Validate never reaches stringify — parse rejects the token first.

Invalid JSON (JavaScript undefined):

{"ok": undefined}

Valid JSON (null):

{"ok": null}

A trailing comma is not JSON

RFC 8259 §4 and §5 write object = begin-object [ member *( value-separator member ) ] end-object and array = begin-array [ value *( value-separator value ) ] end-array. A comma may only appear between members or values, not before } or ]. JSON.parse('{"ok":true,}') throws, often with “Expected double-quoted property name”. JSON.parse("[1,]") throws, often with “Unexpected token ]” or “is not valid JSON”. {"ok":true} and [1] are valid; empty {} and [] are valid. JSON5 and JavaScript allow trailing commas; this page does not.

Invalid JSON (trailing commas):

{"ok": true,}

Valid JSON (no trailing comma):

{"ok": true}

A comment is not JSON

RFC 8259 §2 and ECMA-404 allow only space, tab, line feed, and carriage return as insignificant whitespace (ws = *(%x20 / %x09 / %x0A / %x0D)). There is no comment syntax. JSON.parse("// comment") and JSON.parse("/* x */ {}") throw, often with “Unexpected token /” or “is not valid JSON”. JSON.parse('{"ok":true} // note') throws after the object, often with “Unexpected non-whitespace character after JSON”. {"ok":true} and {"s":"// note"} are valid — slashes inside a string are not comments. JSON5 and JSONC allow // and /* */ comments; this page does not.

Invalid JSON (comments):

{"ok": true} // note

Valid JSON (no comments):

{"ok": true}

A single-quoted string is not JSON

RFC 8259 §7 and ECMA-404 write string = quotation-mark *char quotation-mark with quotation-mark = %x22 (U+0022). A single quote (U+0027) is not a string delimiter. JSON.parse("'hello'") and JSON.parse("{'ok':true}") throw, often with “Unexpected token '” or “Expected property name”. JSON.parse('{"s":\'ok\'}') throws too. {"ok":"true"} and {"s":"it's fine"} are valid — an apostrophe inside a double-quoted string is not a delimiter. JSON5 and JavaScript allow single-quoted strings; this page does not.

Invalid JSON (single quotes):

{'ok': true}

Valid JSON (double quotes):

{"ok": "true"}

An unquoted key is not JSON

RFC 8259 §4 and ECMA-404 write member = string name-separator value. A name is a string. RFC 8259 §7 writes string = quotation-mark *char quotation-mark with quotation-mark = %x22 (U+0022). An identifier or number is not a member name. JSON.parse("{ok:true}") and JSON.parse('{ok:"true"}') throw, often with “Expected property name or '}'”. JSON.parse("{1:true}") throws too. {"ok":true} is valid. JSON5 and JavaScript allow unquoted IdentifierName keys; this page does not.

Invalid JSON (unquoted key):

{ok: true}

Valid JSON (quoted key):

{"ok": true}

An unquoted value is not JSON

RFC 8259 §3 and ECMA-404 write value = false / null / true / object / array / number / string. The only literal names are lowercase true, false, and null. An identifier is not a value. JSON.parse('{"ok":yes}') and JSON.parse("yes") throw, often with “Unexpected token 'y'” or “is not valid JSON”. JSON.parse("[ok]") throws too. {"ok":"yes"} and {"ok":true} are valid. A YAML mapping such as ok: yes is not JSON — YAML 1.2 Core keeps yes as a string, and this page still rejects the identifier.

Invalid JSON (unquoted value):

{"ok": yes}

Valid JSON (quoted string or true):

{"ok": "yes"}

JSON Lines / NDJSON is not one JSON.parse

JSON Lines (jsonlines.org), also called newline-delimited JSON, NDJSON, or JSONL, is one JSON value per line with a \n terminator. Each line is valid JSON on its own. The file as a whole is not one JSON text. Docify’s Validate button runs a single JSON.parse on the whole textarea, so a two-record dump fails after the first value. This page does not split lines or parse each record.

Invalid as one JSON.parse (valid JSON Lines):

{"id": 1} {"id": 2}

One JSON array (different document, not JSON Lines):

[{"id": 1}, {"id": 2}]

What this validator shows

  • ✓JSON.parse success or failure — Valid JSON badge, or the browser error text
  • ✓Pretty output when valid — Validate and Prettify both stringify with 2 spaces
  • –No line gutter or syntax colors — the input is a plain textarea
  • –No as-you-type checking — click a button to parse

Validate JSON in the browser

Load sample Validate is John Doe / age 30 / hobbies 2-space JSON plus Valid JSON. Standard JSON, not JSON5 or JSON Lines. Nothing is uploaded.

Open JSON Formatter →

FAQ

What does Load sample Validate write on the live JSON page?
Load sample fills the compact object {"name":"John Doe","age":30,"email":"john@example.com","address":{"street":"123 Main St","city":"New York","country":"USA"},"hobbies":["reading","coding","gaming"]} and does not run Prettify, Minify, or Validate. Validate then runs the same JSON.parse then JSON.stringify(value, null, 2) path as Prettify: it writes the matching 2-space JSON and the Valid JSON badge. age is the number 30. This is not the older users / Jane Smith / total leftover. Standard JSON only — no comments, trailing commas, or JSON5.
What does “unexpected token” mean in a JSON parse error?
JSON.parse hit a character it does not allow at that position — often a missing comma, a trailing comma, a single quote, or an unquoted key. Docify shows the browser’s parser message; it does not add its own line-number gutter.
Why does JSON Lines / NDJSON fail Validate?
JSON.parse accepts one JSON text — one value. JSON Lines (also called newline-delimited JSON, NDJSON, or JSONL) is several values, one per line, with a \n terminator (jsonlines.org). Pasting {"id":1}\n{"id":2} parses the first object and then throws, usually “unexpected non-whitespace character after JSON”. Docify does not split lines or parse each record. Wrapping those records in a JSON array is a different document, not JSON Lines. Nothing is uploaded.
Is JSON5 valid JSON?
No. JSON5 allows trailing commas, single quotes, comments, and unquoted keys. Standard JSON (ECMA-404 / RFC 8259) does not. JSON.parse rejects those extras, and so does this page.
Does Docify validate JSON as I type?
No. Paste the text, then click Validate, Prettify, or Minify. Each button runs JSON.parse at that moment. There is no live-on-keystroke checker.
Can I validate JSON in my editor instead?
Yes. Most editors flag .json files with the same grammar. The online tool is for a quick paste when you want the raw JSON.parse error without opening a project.
Why do Infinity and NaN fail Validate?
JSON numbers are digit sequences (RFC 8259 §6 / ECMA-404). Infinity, -Infinity, and NaN are not permitted. JSON.parse("Infinity") and JSON.parse("NaN") throw; JSON.parse('{"n":Infinity}') does too. Those tokens are JavaScript, not JSON. JSON.stringify writes null for a non-finite Number, but Validate never reaches stringify for those tokens — parse rejects them first. A digit-sequence overflow such as 1e309 is different: parse succeeds and stringify writes null. Use null or a string if you need a sentinel. Nothing is uploaded.
Why does JSON 1e309 become null after Prettify?
JSON.parse converts each JSON number to a JavaScript Number (IEEE-754 binary64; ECMA-262). RFC 8259 §6 allows implementations to limit range and names 1E400 as a number that may not interoperate. Number.MAX_VALUE is 1.7976931348623157e+308. JSON.parse("1e308") is 1e308 (finite). JSON.parse("1e309") is Infinity (overflow). JSON.parse("-1e309") is -Infinity. JSON.stringify writes null for a non-finite Number (ECMA-262), so {"n":1e309} Prettify, Minify, and Validate output is {"n":null}. Validate still reports valid — parse succeeded. 1E309, 1e+309, and 10e308 are the same overflow. 1.8e308 is also Infinity. 1.7976931348623157e+308 stays MAX_VALUE. A quoted "1e309" stays the string. This is not the Infinity token (JSON.parse("Infinity") throws). This is not the 9007199254740993 integer-rounding case (that stays finite). A tiny exponent such as 1e-324 underflows to 0, not null. Keep magnitudes that must survive as JSON strings. The live formatter does not use BigInt. Nothing is uploaded.
Why does a leading-zero number fail Validate?
RFC 8259 §6 / ECMA-404 write integers as zero or a non-zero digit plus more digits. Leading zeros are not allowed. JSON.parse("01") and JSON.parse('{"n":01}') throw (often “Unexpected number”). 0 and 0.1 are valid; -01 is not. This is not C-style octal — 007 is not 7. Keep padded IDs as JSON strings ("007"). Nothing is uploaded.
Why do .5 and 1. fail Validate?
RFC 8259 §6 / ECMA-404 write number = [ minus ] int [ frac ] [ exp ]. The integer part is required; a fraction is a decimal point plus one or more digits. JSON.parse(".5") and JSON.parse("1.") throw (often “Unexpected token .” or “Unterminated fractional number”). JSON.parse('{"n":.5}') and JSON.parse('{"n":1.}') do too. 0.5 and 1.0 are valid; -.5 is not. This is not JSON5, which allows leading and trailing decimal points. Nothing is uploaded.
Why does a plus-prefixed number fail Validate?
RFC 8259 §6 / ECMA-404 write number = [ minus ] int [ frac ] [ exp ]. A leading plus is not allowed. Plus is only legal in the exponent: exp = e [ minus / plus ] 1*DIGIT. JSON.parse("+1") and JSON.parse('{"n":+1}') throw (often “Unexpected token +”). -1 and 1e+2 are valid; +1 is not. This is not JSON5, which allows a leading plus. Nothing is uploaded.
Why do 1e and 1e+ fail Validate?
RFC 8259 §6 / ECMA-404 write exp = e [ minus / plus ] 1*DIGIT. After e or E and an optional sign, one or more digits are required. JSON.parse("1e") and JSON.parse("1e+") throw (often “Exponent part is missing a number”). JSON.parse('{"n":1e}') and JSON.parse('{"n":1e+}') do too. 1e2, 1e+2, and 1e-2 are valid; 1e- is not. Nothing is uploaded.
Why does a hexadecimal number fail Validate?
RFC 8259 §6 / ECMA-404 write number = [ minus ] int [ frac ] [ exp ]. Digits are decimal only. A 0x or 0X prefix is not allowed. JSON.parse("0x1") and JSON.parse("0XFF") throw (often “Unexpected non-whitespace character after JSON”) because parse accepts 0 and then hits x. JSON.parse('{"n":0x1}') throws too (often “Expected ',' or '}' after property value”). 255 and 0 are valid; 0xFF is not. This is not JSON5, which allows hexadecimal numbers (0xdecaf). Write a decimal or a string. Nothing is uploaded.
Why does a newline inside a JSON string fail Validate?
RFC 8259 §7 / ECMA-404 require control characters U+0000–U+001F inside strings to be escaped. unescaped starts at space (%x20), so a literal line feed (U+000A) or tab (U+0009) is invalid. JSON.parse of a quoted string that contains a raw line feed throws (often “Bad control character in string literal”). {"s":"hello\nworld"} is valid. Newlines between tokens are still whitespace (RFC 8259 §2) — pretty-printed objects are fine. This is not JSON Lines. Nothing is uploaded.
Why does a \x or incomplete \u escape fail Validate?
RFC 8259 §7 / ECMA-404 allow only ", \, /, b, f, n, r, t, and u plus exactly four hex digits after the backslash. JSON.parse('"\x41"') throws (often “Bad escaped character in JSON”) — JavaScript \xNN is not JSON. JSON.parse('"\u12"') and JSON.parse('"\u"') throw (often “Bad Unicode escape in JSON”) because \u needs four hex digits. \' is also invalid. {"s":"\u00e9"} is valid (é after parse). This is not JavaScript string syntax. Nothing is uploaded.
Why do True and None fail Validate?
RFC 8259 §3 / ECMA-404 allow only the lowercase literals true, false, and null. True, False, and None are Python names, not JSON. JSON.parse("True") and JSON.parse("None") throw (often “Unexpected token T” / “Unexpected token N”). JSON.parse('{"ok":True}') and JSON.parse('{"ok":None}') do too. {"ok":true} and {"ok":null} are valid. Python json.dumps writes those lowercase tokens; a pasted dict repr does not. This page does not accept Python literals. Nothing is uploaded.
Why does undefined fail Validate?
RFC 8259 §3 / ECMA-404 allow only the lowercase literals true, false, and null. undefined is a JavaScript name, not JSON. JSON.parse("undefined") and JSON.parse('{"ok":undefined}') throw (often “Unexpected token u” or “is not valid JSON”). {"ok":null} is valid. JSON.stringify omits a key whose value is undefined, but Validate never reaches stringify — parse rejects the token first. This page does not accept JavaScript object literals. Nothing is uploaded.
Why does a trailing comma fail Validate?
RFC 8259 §4 / §5 write object = begin-object [ member *( value-separator member ) ] end-object and array = begin-array [ value *( value-separator value ) ] end-array. A comma may only appear between members or values, not before } or ]. JSON.parse('{"ok":true,}') throws (often “Expected double-quoted property name”). JSON.parse("[1,]") throws (often “Unexpected token ]” or “is not valid JSON”). {"ok":true} and [1] are valid; empty {} and [] are valid. This is not JSON5 or JavaScript, which allow trailing commas. Nothing is uploaded.
Why do comments fail Validate?
RFC 8259 §2 / ECMA-404 allow only space, tab, line feed, and carriage return as insignificant whitespace (ws = *(%x20 / %x09 / %x0A / %x0D)). There is no comment syntax. JSON.parse("// comment") and JSON.parse("/* x */ {}") throw (often “Unexpected token /” or “is not valid JSON”). JSON.parse('{"ok":true} // note') throws after the object (often “Unexpected non-whitespace character after JSON”). {"ok":true} and {"s":"// note"} are valid — slashes inside a string are not comments. JSON5 and JSONC allow // and /* */ comments; this page does not. Nothing is uploaded.
Why do single quotes fail Validate?
RFC 8259 §7 / ECMA-404 write string = quotation-mark *char quotation-mark with quotation-mark = %x22 (U+0022). A single quote (U+0027) is not a string delimiter. JSON.parse("'hello'") and JSON.parse("{'ok':true}") throw (often “Unexpected token '” or “Expected property name”). JSON.parse('{"s":\'ok\'}') throws too. {"ok":"true"} and {"s":"it's fine"} are valid — an apostrophe inside a double-quoted string is not a delimiter. JSON5 and JavaScript allow single-quoted strings; this page does not. Nothing is uploaded.
Why do unquoted keys fail Validate?
RFC 8259 §4 / ECMA-404 write member = string name-separator value. A name is a string. RFC 8259 §7 writes string = quotation-mark *char quotation-mark with quotation-mark = %x22 (U+0022). An identifier or number is not a member name. JSON.parse("{ok:true}") and JSON.parse('{ok:"true"}') throw (often “Expected property name or '}'”). JSON.parse("{1:true}") throws too. {"ok":true} is valid. JSON5 and JavaScript allow unquoted IdentifierName keys; this page does not. Nothing is uploaded.
Why do unquoted values fail Validate?
RFC 8259 §3 / ECMA-404 write value = false / null / true / object / array / number / string. The only literal names are lowercase true, false, and null. An identifier is not a value. JSON.parse('{"ok":yes}') and JSON.parse("yes") throw (often “Unexpected token 'y'” or “is not valid JSON”). JSON.parse("[ok]") throws too. {"ok":"yes"} and {"ok":true} are valid. A YAML mapping such as ok: yes is not JSON — YAML 1.2 Core keeps yes as a string, and this page still rejects the identifier. This page does not accept YAML or unquoted identifiers. Nothing is uploaded.

Related

← Back to all articles | Explore all tools →