Skip to main content

JSON Validator

Validate JSON data online. Check syntax, view structure analysis with key count, nesting depth, and formatted output.

Ad (leaderboard)
Status
Keys
Depth
Type
Size
Rate this tool
0.0 / 5 · 0 ratings

Embed This Calculator

Add this calculator to your website for free. Copy the single line of code below and paste it into your HTML. The calculator auto-resizes to fit your page.

<script src="https://calchammer.com/embed.js" data-calculator="json-validator" data-category="everyday"></script>
data-theme "light", "dark", or "auto"
data-values Pre-fill inputs, e.g. "amount=1000"
data-max-width Max width, e.g. "600px"
data-border "true" or "false"
Or use an iframe instead
<iframe src="https://calchammer.com/embed/everyday/json-validator" width="100%" height="500" style="border:none;border-radius:12px;" title="Json Validator Calculator"></iframe>

Preview

yoursite.com/blog
Json Validator Calculator auto-resizes here
Ad (in_results)

How to Use the JSON Validator

Paste your JSON into the input area and click Validate JSON. The tool parses your input and reports whether it is valid or identifies the specific syntax error. When the JSON is valid, you see a formatted version in the output area along with statistics including the total key count, nesting depth, root data type, and document size. Use the Copy button to copy the formatted output to your clipboard.

This tool is essential for developers working with API responses, configuration files, database exports, and any other JSON data. Rather than waiting for a runtime error to tell you something is wrong with your JSON, validate it first and fix issues before they cause problems downstream.

Ad (in_content)

Understanding JSON Syntax Rules

JSON has a deceptively simple syntax that trips up even experienced developers. The specification requires that all strings use double quotes, not single quotes. Object keys must be quoted strings. Arrays and objects must not have trailing commas. There are no comments of any kind. Numbers cannot have leading zeros (except for the value 0 itself or decimals like 0.5). Boolean values must be lowercase true or false, and the null value must be lowercase null.

Many developers are accustomed to writing JavaScript object literals, which are more permissive than JSON. JavaScript allows single quotes, unquoted keys, trailing commas, and comments. When developers copy JavaScript objects and try to use them as JSON, the validator catches these differences immediately. Understanding the distinction between JavaScript objects and JSON is fundamental to working with web APIs.

Common JSON Errors and How to Fix Them

Trailing commas are the single most common JSON error. In JavaScript, {"a": 1, "b": 2,} is valid, but in JSON the trailing comma after the last value is a syntax error. The fix is simply to remove the comma after the last element. Single quotes are the second most common error. JSON requires "hello", not 'hello'. Unquoted keys like {name: "John"} must be changed to {"name": "John"}. Mismatched brackets are harder to spot in large documents, which is where a validator becomes indispensable.

Key Count and Nesting Depth Analysis

The key count tells you the total number of properties across all objects in your JSON document, including those in nested objects. The nesting depth measures how many levels deep the deepest value sits. These metrics are useful for understanding the complexity of a data structure. Deeply nested JSON with more than five or six levels can be difficult to work with and may indicate that the data model needs restructuring. Many APIs impose depth limits to prevent abuse, and knowing your depth helps you stay within those limits.

JSON Syntax Rules Explained

JSON, short for JavaScript Object Notation, defines two primary structures: objects and arrays. An object is an unordered collection of key-value pairs enclosed in curly braces {}. Each key must be a string wrapped in double quotes, followed by a colon and a value. Multiple key-value pairs are separated by commas. An array is an ordered list of values enclosed in square brackets [], with each value separated by a comma. Both structures can be nested to any depth, allowing you to represent complex hierarchical data.

The allowed value types in JSON are strictly limited. A value can be a string (double-quoted), a number (integer or floating-point, without leading zeros), a boolean (true or false, always lowercase), null (also lowercase), an object, or an array. There are no other value types. Notably, JSON does not support undefined, dates, regular expressions, functions, or any of the other complex types found in programming languages. Dates are typically represented as ISO 8601 strings such as "2026-04-07T12:00:00Z", and the application is responsible for parsing them.

The trailing comma issue deserves special emphasis because it accounts for a disproportionate number of validation failures. In many programming languages, a comma after the last element of a list or the last property of an object is perfectly acceptable and even encouraged for cleaner version control diffs. JSON, however, strictly forbids trailing commas. The input {"a": 1, "b": 2,} is invalid JSON and will be rejected by any compliant parser. Similarly, [1, 2, 3,] fails validation. This is one of the most frequent mistakes developers make when hand-editing JSON files, and it is the single biggest reason to use a validator before submitting data to an API or loading a configuration file.

Common JSON Validation Errors in Detail

Beyond trailing commas, there are several other frequent sources of JSON validation errors that are worth understanding in depth. Each one stems from a mismatch between what developers expect JSON to accept and what the specification actually permits.

Missing or Incorrect Quotes on Keys

In JavaScript, you can write {name: "Alice"} without quoting the key. In JSON, every key must be a double-quoted string: {"name": "Alice"}. This is non-negotiable. Some lenient parsers accept unquoted keys, but they are violating the specification, and your data will break when processed by a strict parser. Always double-quote every key in your JSON documents.

Single Quotes vs. Double Quotes

JSON requires double quotes for all strings, both keys and values. Using single quotes like {'name': 'Alice'} is invalid. This is a common mistake for Python developers, since Python uses single quotes interchangeably with double quotes and its str() representation of dictionaries uses single quotes. If you are converting Python data structures to JSON, always use the json.dumps() function rather than str(), because json.dumps() correctly produces double-quoted output.

Comments in JSON

The JSON specification does not allow any form of comments, neither single-line (//) nor multi-line (/* */). This is an intentional design decision by Douglas Crockford, who created JSON. He argued that comments were being used to hold parsing directives, which caused interoperability issues. If you need comments in configuration files, consider JSONC (JSON with Comments, used by VS Code), JSON5, YAML, or TOML. When you encounter JSON with comments, strip them before parsing or use a comment-tolerant preprocessor.

Unescaped Special Characters in Strings

JSON strings must escape certain characters with a backslash. Control characters (characters with code points below U+0020) must be escaped. The most common ones are newlines (\n), tabs (\t), carriage returns (\r), and backslashes themselves (\\). Double quotes within a string must be escaped as \". Forgetting to escape a backslash in a Windows file path like "C:\new\folder" produces an invalid JSON string because \n is interpreted as a newline and \f as a form feed. The correct representation is "C:\\new\\folder". This problem frequently surfaces when embedding file paths, regex patterns, or HTML snippets inside JSON.

Number Formatting Pitfalls

JSON numbers follow specific rules that differ from some programming languages. Leading zeros are not allowed: 007 is invalid and must be written as 7. Positive signs are not allowed: +5 is invalid, whereas -5 is valid. Hexadecimal notation like 0xFF is not supported. Infinity and NaN are not valid JSON values. If you need to represent special numeric values, you must encode them as strings or use a sentinel value and handle the conversion in your application code.

JSON in APIs and Configuration Files

JSON has become the dominant data interchange format for web APIs. When you send a POST request to a REST API with a Content-Type: application/json header, the server expects a strictly valid JSON body. If your request body contains any syntax error, the server will typically return a 400 Bad Request response, often with a cryptic parsing error message that can be difficult to debug. Validating your JSON payload before sending it eliminates this entire class of errors and speeds up API development significantly.

In the context of REST APIs, JSON validation matters at both ends of the communication. On the client side, you need to ensure that the data you are sending is well-formed. On the server side, you need to validate incoming JSON before processing it to prevent malformed data from corrupting your application state. Many web frameworks perform basic JSON parsing automatically, but structural validation, ensuring the right fields exist with the right types, requires additional schema validation tools like JSON Schema.

Configuration files are another major use case for JSON. Package managers like npm use package.json, TypeScript uses tsconfig.json, ESLint uses .eslintrc.json, and many cloud services like AWS CloudFormation and Azure Resource Manager use JSON templates. A syntax error in any of these files can prevent your build pipeline from running, your application from starting, or your infrastructure from deploying. The stakes are particularly high in CI/CD environments where a malformed JSON configuration can block an entire release process.

Database systems also rely heavily on JSON. PostgreSQL has native json and jsonb column types, MongoDB stores documents as BSON (a binary form of JSON), and many other databases support JSON querying. When importing data into these systems, invalid JSON causes insert failures that can interrupt batch processing jobs. Validating your JSON data before loading it into a database saves time and prevents partial imports that leave your data in an inconsistent state.

Beyond basic syntax validation, many organizations adopt JSON Schema to define the expected structure of their JSON documents. JSON Schema lets you specify which fields are required, what data types each field should have, acceptable value ranges, string patterns, and more. While this tool focuses on syntax validation, ensuring your JSON is syntactically correct is the essential first step before any schema-level validation can take place. A document that does not parse correctly cannot be validated against a schema at all.

Frequently Asked Questions

What is JSON validation?

JSON validation checks whether a string conforms to the JSON specification. The validator parses your input and reports whether it is well-formed or identifies the specific syntax error.

Why should I validate JSON?

Validating JSON before using it prevents runtime errors. A single missing comma or mismatched bracket can cause API requests and configuration loading to fail.

What are common JSON errors?

Trailing commas, single quotes instead of double quotes, unquoted keys, missing commas between items, comments, and mismatched brackets are the most frequent JSON errors.

Can JSON have comments?

No. The JSON specification does not allow comments. Use JSONC or YAML if you need comments in your configuration files.

What is the maximum size of a JSON document?

The specification has no limit. In practice, browser parsers handle hundreds of megabytes. This online tool works well with documents up to a few megabytes.

Related Calculators

Disclaimer: This calculator is for informational and educational purposes only. Results are estimates and should not be considered professional expert advice. Consult a qualified professional before making decisions based on these calculations. See our full Disclaimer.