JSON Validator

Syntax is only the first question

The first check is whether the input can be parsed by the browser's built-in JSON.parse(). That catches grammar errors such as missing commas, trailing commas, single-quoted strings, unescaped control characters, malformed escape sequences, invalid number forms, and unbalanced braces or brackets.

Syntax validation answers one narrow question: “is this JSON text grammatically parseable?” It does not prove that the data has the fields your API requires, that IDs exist, that URLs are reachable, or that values satisfy a business rule. Those are schema or application-level checks.

JSON Is Not a JavaScript Object Literal

{
  "name": "Yoryantra",
  "active": true,
  "count": 3
}

{
  name: 'Yoryantra',
  active: true,
  count: 3,
}

JSON requires double quotes around object member names and string values, does not allow trailing commas or comments, and has no values such as undefined, NaN, or Infinity.

Top-Level Scalars Are Valid JSON

A complete JSON text does not have to start with an object or array. Values such as "hello", 42, true, and null are valid JSON texts under RFC 8259. An API may still impose its own rule that the payload must be an object or array.

Duplicate Object Names: Validity vs Interoperability

RFC 8259 says names within an object should be unique. Parsers commonly accept duplicate names anyway, but their behavior is not reliably interoperable: one implementation may keep the last value, another may expose every pair, and another may reject the document. Duplicate names therefore remain visible in formatted output and are reported as an interoperability warning rather than being silently collapsed.

{
  "role": "viewer",
  "role": "admin"
}

Large Integers and JavaScript Number Precision

JSON itself does not define JavaScript's numeric precision limit. In JavaScript, however, integers outside the safe range from -(2^53 - 1) to 2^53 - 1 may lose precision when converted to a number. This page flags integer tokens outside that range. The formatter works from the validated source text instead of JSON.stringify(JSON.parse(...)), so it does not silently rewrite a large integer token merely to pretty-print it.

If an identifier must remain exact across JavaScript systems, a decimal string is often safer than relying on an arbitrarily large JSON number. The correct representation still depends on the contract used by both producer and consumer.

How Error Locations Should Be Read

Parse error wording is produced by the browser engine and can differ between browsers. When the engine reports a character position or line and column, a nearby line is shown with a caret. Treat that location as a debugging hint: the actual mistake can sit just before the reported character, such as a missing comma on the previous property.

Syntax Validation vs JSON Schema Validation

A document can be perfectly valid JSON and still be invalid for your application. For example, {"age": -5} is valid JSON syntax, but a schema could require age to be a non-negative integer. Use syntax validation first when the parser itself is failing; use JSON Schema validation when you need to enforce shape, required properties, formats, ranges, or other contract rules.

BOMs, Unicode, and Portable JSON

RFC 8259 requires JSON exchanged between systems outside a closed ecosystem to use UTF-8 and says generators must not add a byte-order mark (BOM). Parsers are permitted to ignore a BOM for interoperability, so different software can behave differently. A leading BOM is reported explicitly instead of being silently removed.

JSON strings can contain Unicode characters directly or through \uXXXX escapes. A paired surrogate escape can represent a character outside the Basic Multilingual Plane, while an unpaired surrogate can still fit the JSON grammar and yet behave unpredictably across software. Those lone surrogate cases are reported separately from syntax errors.

The grammar and the browser parser are two different references

Interchange rules such as UTF-8, duplicate-name interoperability, number guidance, BOM handling, and Unicode edge cases come from RFC 8259. ECMA-404 defines the JSON syntax itself. The actual parse result and error wording in this page come from the JavaScript engine's JSON.parse semantics in ECMAScript.

After syntax, check the data contract