A complete guide to formatting and validating JSON, how exact error locations are calculated across different browsers, and a real syntax-highlighting bug caught during testing.
Launch the JSON Formatter/Validator →The JSON Formatter/Validator takes any JSON text you paste in and offers three operations: Pretty-Print (reformat with clean, readable indentation and syntax highlighting), Minify (strip all unnecessary whitespace to produce the smallest possible valid representation), and Validate Only (confirm whether the JSON is syntactically correct without producing reformatted output). When the input contains a syntax error, the tool reports the exact line and column where the problem occurs, along with the specific offending line of text and a visual pointer marking the exact character position.
Valid output is also syntax-highlighted, with object keys, string values, numbers, booleans, and null each rendered in a distinct color, making the structure of complex, deeply nested JSON considerably easier to visually parse than plain, uncolored text.
JSON's syntax rules are strict and unforgiving compared to many other data formats: a single missing comma, an extra trailing comma, a missing closing brace, or an unescaped quotation mark inside a string will cause the entire document to fail parsing, with no partial result returned. This makes pinpointing exactly where a syntax error occurs disproportionately valuable compared to formats with more forgiving parsers, since in a large JSON document, a single misplaced character can be genuinely difficult to spot by eye without being told precisely where to look.
This tool reports not just that an error occurred, but the specific line number, column number, the full text of that offending line, and a caret symbol (^) positioned directly underneath the exact character where the problem was detected, which collectively turns a frustrating "something is wrong somewhere in this 200-line file" situation into an immediate, precise "here is exactly what to fix" answer.
JavaScript's built-in JSON.parse() function, which every browser provides natively, reports syntax errors as plain text messages — but critically, different browser engines format that error message text differently from each other. Chrome's V8 engine reports something like "Unexpected token... in JSON at position 42," while Firefox's SpiderMonkey engine instead reports "JSON.parse: unexpected character at line 3 column 7 of the JSON data." Research specifically into this behavior also surfaced evidence that Safari's JavaScriptCore engine can, in some cases, omit position information from its JSON error messages entirely.
Because this tool's exact-location error reporting depends on successfully extracting a line and column number from the browser's own error message text, relying on only one of these message formats would mean the feature worked perfectly in some browsers and degraded to a generic, unhelpful message in others. To address this, the tool checks for both the position-based format and the line/column-based format, and additionally includes a manual fallback: a simple character-by-character scanner that tracks brace, bracket, and string-quote balance through the text, which can independently estimate an error's likely location even when neither of the two known message formats is detected at all. This fallback is deliberately honest about its own more limited scope — it reliably catches structural problems like unmatched brackets or unterminated strings, but acknowledged directly in its own design as not catching every possible JSON syntax error type, such as a simple missing comma between two otherwise valid values.
During development, an initial version of the syntax highlighting logic was written, tested against sample JSON, and found to produce completely plain, uncolored output for every string and object key, despite numbers, booleans, and null values highlighting correctly. Investigating the actual cause (rather than assuming the highlighting regular expression itself was simply wrong) revealed a sequencing bug: the code was escaping HTML-sensitive characters (converting literal quotation marks into ", for safe display) before running the highlighting pattern, which specifically searches for literal quotation marks to identify where strings and keys begin and end. Once those quotation marks had already been converted into multi-character HTML entities, the highlighting pattern could no longer find them, silently failing to colorize anything that depended on detecting a quote character.
The fix reordered the process: the highlighting pattern now runs first against the original, unescaped JSON text to correctly identify keys, strings, numbers, and other tokens, and HTML-escaping is applied selectively afterward, both to the identified tokens and to the plain text segments between them. This fix additionally closed a real security consideration that the original (broken) version had accidentally avoided only by luck: properly escaping content after identifying it, rather than before, ensures that if someone pastes JSON containing a string value with literal HTML tags inside it (such as {"html": "<script>alert(1)</script>"}), that content is safely displayed as plain visible text rather than risking being interpreted as actual HTML by the browser.
JSON (JavaScript Object Notation) has become the dominant data interchange format across modern software, used for API request and response bodies, configuration files, data export and import, and countless other contexts where structured data needs to be represented as readable text. Its popularity stems from being simultaneously simple enough for a human to read and write directly, and precise enough for software to parse unambiguously — a balance that's harder to achieve than it might initially seem.
Despite that relative simplicity, hand-written or minified JSON is still genuinely easy to get wrong, especially when working with deeply nested structures, API responses copied from documentation, or configuration files edited directly in a plain text editor without any built-in validation. A missing comma, an extra trailing comma (which, unlike in JavaScript object literals, is not permitted in strict JSON), or a stray unescaped character can silently break an entire application that depends on successfully parsing that data.
Having a fast, reliable way to both validate correctness and reformat for readability, without needing to install a dedicated code editor extension or run a command-line tool, covers a genuinely common daily need across web development, API testing, configuration management, and data analysis work.
Pasting JSON with a missing comma between two object properties, like {"name": "test" "value": 1}, produces a clear error identifying the exact line and column where the parser expected a comma but found something else, along with the offending line and a pointer directly beneath the problem character.
All parsing, formatting, and validation happen entirely within your browser using JavaScript's native JSON.parse() and JSON.stringify() functions. No network request of any kind is made by this tool, and nothing you paste is ever transmitted anywhere, logged, or stored.
This can happen on browsers whose JSON error message format isn't one of the two patterns this tool recognizes, and where the structural fallback scanner also can't pinpoint the specific error type involved (such as a missing comma, which doesn't break bracket or quote balance). This is explained in detail in the Cross-Browser Error Format section above.
Nothing you paste is transmitted anywhere by this tool, since all processing happens locally in your browser. As with any tool, however, it's good general practice to be thoughtful about pasting genuinely sensitive data into any web page.
Pretty-Print adds consistent, readable indentation and line breaks to make the JSON's structure easy to visually follow. Minify does the opposite, removing all non-essential whitespace to produce the smallest possible valid representation, often used when JSON size matters, such as reducing network transfer size.
No. This tool checks only whether the text is syntactically valid JSON according to the JSON specification itself, not whether it conforms to any particular expected structure, required fields, or data types that a schema might define.