Single-quoted keys rejected
Input
{'id': 7}Result
Expected property name or '}' in JSON at position 1
JSON strings, including keys, require double quotes. Single quotes are valid JavaScript but not valid JSON.
JSON Tools
JSON Validator
Validate JSON syntax and inspect parsed output in a readable form.
{
"name": "Softkey Tools",
"stack": [
"Angular",
"TypeScript",
"SSR"
],
"published": true
}Understand the format
How JSON Validator works
Validation answers one narrow question precisely: can a strict JSON parser read this text at all, and if not, where does it stop?
Syntax validity is not schema validity
There are two very different questions people mean by "is this JSON valid?". The first is syntactic: does the byte sequence match the JSON grammar? The second is semantic: does the document contain the fields, types, and value ranges a particular API expects? This tool answers the first question. A payload can parse perfectly and still be rejected by a server because a required field is missing or a number is out of range.
Answering the syntax question first is worth the ten seconds it takes. It removes an entire class of confusing failures, and it turns a vague "the request failed" report into a specific "the body is truncated after byte 812".
Reading parser error messages
Parser messages point at the position where the grammar was first violated, which is often slightly after the real mistake. A missing closing brace, for example, is usually reported at the end of the document, because the parser only discovers the problem when the input runs out. Read the reported position as a starting point and then scan backwards for the nearest unbalanced structure.
When the input has been copied from a log viewer or a terminal, the most common corruptions are invisible: a truncated tail, a zero-width character, a byte-order mark before the opening brace, or a newline inside a string literal that was never escaped.
Step by step
How to use JSON Validator
- Paste the exact payload, including the outermost braces or brackets, into the input box.
- Read the status banner: a green banner means the text parses, a red banner reports the first grammar violation.
- Fix only the reported issue, then check the banner again rather than making several speculative edits at once.
- When the banner turns green, review the normalised output to confirm the types are what you expected.
The validator runs in your browser, which means malformed data, internal field names, and copied log fragments never leave the machine.
Worked examples
JSON Validator examples explained
Valid payload with a surprising type
Input
{"id": "7", "active": "false"}Result
{ "id": "7", "active": "false" } — parses successfullyBoth values are strings. The document is valid, yet an API expecting a number and a boolean will still reject it. That is a schema problem, not a syntax problem.
Reference
Frequent parser errors and their usual cause
| Message pattern | Usual cause | Fix |
|---|---|---|
| Unexpected end of JSON input | The payload was truncated when copied, or a brace is unclosed. | Re-copy the full body and check that braces and brackets balance. |
| Unexpected token } in JSON | A trailing comma before the closing brace or bracket. | Delete the comma after the final member. |
| Expected property name or } | Unquoted or single-quoted keys. | Wrap every key in double quotes. |
| Bad control character in string literal | A raw newline or tab inside a string. | Escape it as \n or \t. |
| Unexpected token | A UTF-8 byte-order mark before the first brace. | Strip leading invisible characters before the document starts. |
Practical Guide
How teams use JSON Validator
Common use cases
- Check webhook bodies, fixtures, and request payloads copied out of logs.
- Catch trailing commas, invalid quotes, or missing braces before retrying a failing request.
- Verify that hand-edited sample data still parses.
Checks before trusting the result
- A successful parse proves syntax only, never that the payload satisfies business rules.
- Confirm number and boolean types after copying data out of spreadsheets or chat tools.
- Pair validation with JSON Compare when you need to know what changed between two versions.
Troubleshooting
Common mistakes and how to fix them
- Treating a green banner as proof the API will accept the request.
- Follow syntax validation with schema validation against the API contract or an OpenAPI definition.
- Duplicate keys in the same object.
- The grammar permits them but behaviour is implementation-defined; most parsers keep the last one. Remove duplicates rather than relying on that.
- Assuming a bare value is invalid.
- Since RFC 8259, any JSON value is a valid document, so 42, "text", true, and null all parse on their own.
FAQ
JSON Validator questions, answered
What is the difference between a JSON validator and a JSON Schema validator?
A JSON validator checks the grammar. A JSON Schema validator checks a document against a declared contract: required properties, types, formats, and value constraints. You normally need both, in that order.
Are comments allowed anywhere in JSON?
No. Neither // nor /* */ is part of JSON. Formats such as JSONC and JSON5 add them, and configuration tools that accept comments strip them before parsing.
Is an empty string valid JSON?
No. An empty document contains no value, so parsing fails. An empty JSON string value, written as "" inside a document, is perfectly valid.
Why does my payload fail only in production?
Usually because of size or encoding rather than syntax: a proxy truncating the body, a gateway limit, or a charset mismatch. Validate the exact bytes the server received, not the version in your editor.
Do you store the payloads I validate?
No. Validation calls the browser JSON parser in the page, so nothing is uploaded or retained.
Go deeper
Specifications and guides
- JSON Debugging Workflows for API Teams — A practical guide to formatting, validating, and diffing payloads before they hit production.