JSON Validator

Step 1: Paste your JSON

Click inside the JSON Input area and paste your JSON data. You can paste anything from a single object to a complex nested structure with arrays, nested objects, strings, numbers, booleans, and null values.

Step 2: Choose your action

The tool provides three buttons:

• Validate: Checks whether the pasted JSON is syntactically valid according to the JSON specification (RFC 8259). If the JSON is valid, a green "Valid JSON" message appears together with a pretty-printed copy of your data. If it is invalid, a red "Invalid JSON" message appears with the error text from the JSON parser. In most browsers the message includes the position of the problem, which helps you pinpoint it.

• Format: Also called pretty-printing or beautifying. Takes valid JSON (compact or already formatted) and rewrites it with consistent 2-space indentation and line breaks between elements, which makes nested data easy to read. The formatted result replaces the text in the input box and is also shown in the output area.

• Minify: Removes all unnecessary whitespace, newlines, and indentation from valid JSON to produce the most compact representation possible. Minified JSON is identical in data content to formatted JSON but takes significantly less space, which reduces payload size in API responses and file transfers. The minified result replaces the text in the input box and is also shown in the output area.

Format and Minify only work on valid JSON. If your JSON has an error, they do nothing, so click Validate first to see what needs fixing.

Step 3: Review and copy the output

After validating, the result area shows either a success message or the error description. After formatting or minifying, the transformed JSON appears in the input box and in the output area, so you can select it and copy it wherever you need it.

What Format and Minify do to your data

Format and Minify read your JSON with the browser's JSON parser and write it back out, so the result is always clean, valid JSON with the same data. Because the data passes through JavaScript, a few details can change:

• Very large integers (beyond about 9 quadrillion) and numbers with more than about 17 significant digits can lose precision.

• Number notation is normalized: 1.0 becomes 1 and 1e3 becomes 1000.

• If an object repeats the same key, only the last value is kept.

• Escaped Unicode characters (such as \u00e9) may be written as the plain character.

• Keys that look like whole numbers (such as "1" and "2") may be moved to the front of an object in ascending order.

If you need byte-for-byte exact output, such as for signed payloads or very large IDs, keep the original text and use the validator only to check it.

The JSON specification (defined in RFC 8259 and ECMA-404) has strict syntax rules. Every rule violation produces invalid JSON. Understanding the rules helps you write correct JSON from the start and interpret error messages when the validator finds a problem.

Strings must be double-quoted

JSON strings must always use double quotation marks. Single quotes are not valid JSON.

• Valid: {"name": "Alice"}

• Invalid: {'name': 'Alice'} (single quotes are not valid JSON)

• Invalid: {name: "Alice"} (unquoted keys are not valid JSON)

Keys must be strings

In a JSON object, every key must be a string enclosed in double quotes. Numeric keys, unquoted identifiers, and boolean keys are not valid.

• Valid: {"id": 1, "active": true}

• Invalid: {id: 1, active: true} (keys must be quoted)

• Invalid: {1: "one"} (numeric keys are not valid)

No trailing commas

JSON does not allow a comma after the last element in an array or the last property in an object. This is one of the most common sources of JSON errors, especially when developers paste JSON that originated from JavaScript code where trailing commas are accepted.

• Valid: {"a": 1, "b": 2}

• Invalid: {"a": 1, "b": 2,} (trailing comma after last property)

• Valid array: [1, 2, 3]

• Invalid array: [1, 2, 3,] (trailing comma after last element)

No comments

JSON does not support comments of any kind. Neither the double-slash style (//) nor the block comment style (/* */) is valid in JSON. This surprises developers who work with JSON5 or JSONC (JSON with Comments), which are extensions that do support comments but are not valid standard JSON.

• Invalid: {"name": "Alice" // this is the user name}

• Invalid: {"name": /* primary */ "Alice"}

Valid value types

JSON values must be one of: string (double-quoted), number (integer or floating point, no quotes), boolean (true or false, lowercase, no quotes), null (lowercase, no quotes), array (square brackets), or object (curly braces).

• Valid: {"count": 5, "price": 9.99, "active": true, "data": null}

• Invalid: {"active": True} (True is capitalized: must be lowercase true)

• Invalid: {"active": TRUE} (same problem)

• Invalid: {"price": $9.99} (currency symbols are not valid in JSON numbers)

• Invalid: {"value": undefined} (undefined is a JavaScript value, not a JSON value)

• Invalid: {"value": NaN} (NaN is not a valid JSON value)

• Invalid: {"value": Infinity} (Infinity is not a valid JSON value)

Numbers must follow the number format

JSON numbers cannot have leading zeros (except for the single character zero itself, or zero followed by a decimal point). They also cannot start with a plus sign or a bare decimal point, and cannot end with a decimal point.

• Valid: {"count": 0} and {"ratio": 0.5}

• Invalid: {"count": 007} (leading zeros not permitted)

• Invalid: {"ratio": .5} and {"ratio": 5.}

Unicode escape sequences and control characters

JSON strings support Unicode escape sequences in the form \uXXXX where XXXX is a four-digit hexadecimal code point. This is valid. However, control characters (code points U+0000 through U+001F, which include a raw tab and a raw line break) must be escaped if they appear inside strings. A raw line break inside a string is a common cause of errors when JSON is copied from a text editor.

The root element

A valid JSON document can have any single JSON value as its root: a string, number, boolean, null, array, or object. However, the most common root elements in practice are objects and arrays. Many parsers and APIs expect an object or array at the root.

The exact wording of an error message differs between browsers (Chrome, Firefox, and Safari each describe errors differently), but the causes are the same.

Unexpected token

This is the most generic JSON error. It means the parser encountered a character it did not expect at the position indicated. Common causes: single quotes instead of double quotes, an unquoted key, a JavaScript keyword (true/false/null) written with wrong capitalization, or a value type not supported by JSON (undefined, NaN, Infinity).

Fix: Check the character at the error position. Ensure all strings use double quotes and all keys are double-quoted strings.

Trailing comma

A comma appears after the last element in an array or after the last property in an object. Browsers usually report this as an unexpected closing brace or bracket, or as an expected property name.

Fix: Remove the trailing comma. The last item in a list or the last property in an object should not be followed by a comma.

Unexpected end of JSON input

The JSON is incomplete. An opening bracket, brace, or string was never closed. An empty input produces the same kind of error.

Fix: Check for unclosed braces, brackets, or quotation marks. Paste the JSON into the validator and count opening and closing braces and brackets to find the mismatch.

Missing colon or comma

Two values appear next to each other without a separating colon (in an object) or comma (in an array or between properties). A common cause is a missing colon between a key and its value.

• Invalid: {"name" "Alice"} (missing colon)

• Valid: {"name": "Alice"}

Comments causing parse failures

If JSON was copied from a configuration file that uses JSONC (JSON with Comments) syntax, the comments cause parse failures in standard JSON parsers.

Fix: Remove all comments from the JSON before validating or using it in production.

Special values from JavaScript

Developers who serialize JavaScript objects to JSON sometimes produce values that JavaScript recognizes but JSON does not. When JavaScript serializes data properly, undefined properties are dropped, NaN and Infinity become null, and functions are dropped. If these appear as raw text in the JSON, for example when someone pasted a JavaScript object literal instead of real JSON, they cause parse errors.

Fix: Ensure all values conform to the six valid JSON value types. Replace any undefined, NaN, Infinity, or function references with appropriate JSON values (null, a number, or a string description).

When to Format (Pretty-Print) JSON

Formatted JSON uses consistent indentation and line breaks to make the structure visible and human-readable. Use formatted JSON when:

• Reading and debugging: when you need to understand the structure of an API response, configuration file, or data payload. Formatted JSON makes nesting levels and key-value relationships immediately visible.

• Code reviews: when JSON content needs to be reviewed by team members, consistent formatting makes review easier.

• Documentation: when JSON examples appear in API documentation, technical specifications, or README files, formatted JSON is significantly more readable than compact JSON.

• Development and testing: during development, formatted JSON in log output and debug views makes debugging faster. Most API testing tools (Postman, Insomnia) format JSON responses by default.

• Version control: formatted JSON in configuration files is easier to diff in version control (git), since changes appear on individual lines rather than within a long compact string.

When to Minify JSON

Minified JSON removes all whitespace, newlines, and indentation without changing any data. Use minified JSON when:

• API responses and network transmission: smaller payload size means faster transmission over HTTP. For large, deeply indented JSON payloads, removing whitespace can reduce size noticeably, often by 20% to 40% or more.

• Embedding JSON in source code: when JSON appears as a string literal in code, minified JSON is often more practical.

• Production configuration files where file size matters: server-side configuration processed programmatically does not need human-readable formatting.

• Cookies and URL parameters: space is limited there, so compact JSON is preferred (and it must be properly encoded).

Size comparison example

As an illustration, a formatted JSON object with 10 properties and 2 levels of nesting might occupy around 800 bytes with formatting. The same content minified might occupy around 450 bytes. At scale, across thousands of API calls per second, this difference is meaningful.

JSON is central to modern web development. Understanding where it appears and how it is used helps contextualize why a validator is a practical everyday tool.

• REST APIs: The overwhelming majority of REST APIs use JSON as their data format for both requests and responses. When a frontend application sends data to a backend, it typically sends a JSON body in the HTTP request. When the backend responds, it returns JSON. Any malformed JSON in a request causes the server to reject the request (usually with a 400 Bad Request status). Any malformed JSON in a response causes the client-side JSON parser to throw an error.

• Configuration files: Many development tools and frameworks use JSON for configuration: package.json (Node.js package management), tsconfig.json (TypeScript configuration), .eslintrc.json (ESLint rules), .prettierrc.json (Prettier configuration), and many more. Invalid JSON in a configuration file prevents the tool from starting and produces a parse error that is sometimes difficult to trace. Note that some tools, such as TypeScript and VS Code, accept comments in their own config files (JSONC), which a strict JSON validator will flag.

• Data storage: Many databases store JSON directly: PostgreSQL has a native JSON/JSONB column type, MongoDB stores documents in BSON (binary JSON), Firebase stores data as a JSON tree, and many other modern databases support JSON natively. Invalid JSON cannot be stored in JSON columns.

• Local Storage and IndexedDB: Browser storage mechanisms such as localStorage and sessionStorage hold strings, so JavaScript objects are typically serialized with JSON.stringify() before storage and deserialized with JSON.parse() after retrieval. If the stored string is not valid JSON, JSON.parse() throws a SyntaxError.

• Webhooks and third-party integrations: Webhooks send JSON payloads from one service to another. Payment processors, CRM systems, marketing tools, and countless other services communicate via JSON webhooks. Malformed JSON in a webhook payload causes the receiving service to reject it.

JSON is sometimes confused with or compared to similar data formats. Understanding the distinctions helps clarify when JSON is the right choice and when its limitations matter.

• JSON vs XML: XML (Extensible Markup Language) was the dominant data interchange format before JSON's rise. JSON is generally preferred today because it is more concise, directly maps to JavaScript objects, and is easier to read and write by hand. XML has advantages for documents with mixed content (text with embedded markup), supports namespaces, and has richer schema validation options. Most modern APIs use JSON; legacy enterprise systems often still use XML.

• JSON vs YAML: YAML (YAML Ain't Markup Language) is a human-friendly data serialization format that is largely a superset of JSON. YAML supports comments (unlike JSON), uses indentation-based structure, and is commonly used for configuration files (Docker Compose, Kubernetes manifests, GitHub Actions). YAML is more complex to parse correctly than JSON and its whitespace-sensitivity creates a different category of hard-to-spot errors.

• JSON vs JSON5: JSON5 is an extension of JSON that allows single quotes, trailing commas, unquoted keys, and comments. JSON5 is valid in environments that explicitly support it but is not valid standard JSON. If you are working with JSON5 content, standard JSON validators will report errors on the JSON5-specific features.

• JSON vs JSONC: JSONC (JSON with Comments) is used by Visual Studio Code for its configuration files. Comments are stripped before parsing. Like JSON5, JSONC is not valid standard JSON.

• JSON vs CSV: CSV (Comma-Separated Values) is a flat tabular format for simple datasets. JSON supports nested structures, arrays, and typed values (numbers and booleans, not just strings), making it more versatile for complex data. CSV is more compact for large datasets of simple tabular data.

Thetoolity's JSON validator processes all data locally in your browser using JavaScript. Your JSON data is not sent to any server by this tool.

This matters particularly when working with JSON data that contains sensitive information: API responses with personal user data, configuration files with API keys or credentials, database exports with confidential records, or any proprietary business data. Because the processing happens on your device, you can paste this data into the validator without it leaving your browser. As a general habit, avoid pasting live production secrets into any online tool if you can use sample data instead.

The validator relies on the JSON parsing engine built into your browser, which is the same engine JavaScript uses when your code calls JSON.parse(). This means validation results match what you would get from parsing the JSON in a browser JavaScript environment.

Thetoolity brings together a growing collection of free, fast, and clean online tools for developers, data engineers, and anyone working with JSON. Our JSON validator provides three functions in one interface: syntax validation with parser error messages, pretty-print formatting for readability, and minification for compact production output. All processing runs locally in your browser.

No accounts. No subscriptions. No cluttered interfaces. Just a clean, instant JSON validator.

Explore the full collection at Thetoolity.com and find generators, converters, calculators, checkers, and testers, all free and all instant.