What is the difference between a JSON validator and a JSON schema validator?

A JSON validator checks syntax — whether the text can be parsed at all. A JSON Schema validator checks structure — whether the parsed value has the required properties, types and ranges. You normally need both, in that order.

Are comments allowed in JSON?

No. RFC 8259 defines no comment syntax, so // and /* */ make a document invalid. Formats that appear to allow them (JSONC, JSON5, tsconfig.json) are supersets handled by their own parsers, not by standard JSON.

Is a trailing comma really invalid?

Yes, in JSON — although it is legal in JavaScript object literals, which is why the mistake is so common. JSON5 permits trailing commas; standard JSON does not.

Does validation modify my data?

No. The document is parsed and discarded; nothing is written, stored or returned other than the valid/invalid verdict and the error position.

Developer🔒 Browser (client-side)API available📴 Works offlinebeginner

JSON Validator

Checks whether a JSON document is syntactically valid and reports the exact line and column of any problem.

Data stays in your browser

Ready to runInstant execution

All tools →

Result

—

What does this tool do?

Checks whether a JSON document is syntactically valid and reports the exact line and column of any problem.

Why would I use it?

A webhook or config file is failing and you suspect broken JSON.
You want to confirm generated JSON before sending it to an API.
You are teaching or debugging a serialization library.

Real-life example

Input

{"name": "yas", "count": }

Output

Error at line 1, column 24: Unexpected token }

The validator pinpoints where the parser stopped.

Input → Process → Output → Next

Input: Paste the JSON document.
Process: The browser parses it with the standard JSON parser.
Output: Valid ✓ or an error with line/column and the unexpected token.
Next action: Fix the reported location, then format the JSON for readability.

Common mistakes

Using single quotes — JSON requires double quotes.
Leaving trailing commas after the last property.
Including comments — JSON has no comments.

What the result means

Valid means any conformant parser will accept it; the error message tells you the first offending position.

Privacy & security

Your input is processed entirely in your browser and never sent to a YAS server.

API

Endpoint

POST https://yas.sh/api/v1/tools/json-validator

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/json-validator" \
  -H "Content-Type: application/json" \
  -d '{"input":"{\"a\":}"}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/json-validator", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "input": "{\"a\":}"
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/json-validator", json={"input":"{\"a\":}"})
data = r.json()

Field	Type	Required	Description
input	string	Yes	JSON text

Success response

{ "slug": "json-validator", "valid": false, "error": "..." }

Validate JSON syntax; returns the parser error if invalid.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How JSON Validator works

Validation runs the input through the same JSON.parse the runtime uses, inside a try/catch. If the parse succeeds the document is valid per RFC 8259 and any conformant parser in any language will accept it. If it throws, the engine's SyntaxError message carries the byte offset where the parser gave up, which is converted into a line and column by counting newlines up to that offset.

The reported position is where parsing became impossible, not necessarily where the mistake is. A missing closing brace on line 4 is usually reported at the end of the document, because everything after it is still a legal continuation until the input runs out. Read the error position as an upper bound and work backwards to the last structurally complete element.

This is syntax validation, which is distinct from schema validation. Syntax answers 'can this be parsed'; schema (JSON Schema, OpenAPI, Zod) answers 'does this have the right fields and types'. A document can be perfectly valid JSON and still be rejected by an API for missing a required property.

When to use it: real-world scenarios

A webhook endpoint returns 400 and you cannot see why

Paste the exact request body from your provider's delivery log. If it fails to parse, the sender is producing malformed JSON — often a template that interpolated an unescaped quote or newline into a string value. That moves the bug from your handler to the sender.

CI fails after a config edit

package.json, tsconfig.json or a CI manifest broke the build with an opaque error. Validating the file gives a line and column instead of a stack trace from the tool that loaded it. Note that tsconfig.json permits comments and therefore is not strict JSON.

Verifying generated output before shipping it

Code that builds JSON by string concatenation is fragile; a value containing a quote or a newline breaks the document. Validating the generated artefact catches the escaping bug before it reaches a consumer that fails silently.

Checking LLM tool-call output

Model output that must be machine-readable frequently arrives wrapped in a markdown code fence or with a trailing comma. Validation tells you whether you need to strip the fence or run the JSON Repair tool before parsing.

Pro tips

When the error is reported at the last character of the document, you are almost always missing a closing brace or bracket. Fold the document in an editor and check the nesting depth returns to zero.
Validate before you format. Formatting an invalid document only tells you it is invalid; validation tells you where.
Empty input is not valid JSON. Neither is a bare word such as undefined or NaN — those are JavaScript literals, not JSON values.
A top-level scalar is legal. "hello", 42 and null are each complete, valid JSON documents under RFC 8259, even though older parsers required an object or array at the root.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

Duplicate object keys are accepted, matching RFC 8259, which leaves the behaviour undefined. If your consumer rejects duplicates you need a dedicated linter.
Only the first error is reported. The parser stops at the first impossible token; fixing it can reveal a second error further on.
No schema, type or business-rule checking is performed, and no size, depth or key-name policy is applied.
Extremely deep nesting can exhaust the parser's stack in the browser before a useful message is produced.

Frequently asked questions

What is the difference between a JSON validator and a JSON schema validator?: A JSON validator checks syntax — whether the text can be parsed at all. A JSON Schema validator checks structure — whether the parsed value has the required properties, types and ranges. You normally need both, in that order.
Are comments allowed in JSON?: No. RFC 8259 defines no comment syntax, so // and /* */ make a document invalid. Formats that appear to allow them (JSONC, JSON5, tsconfig.json) are supersets handled by their own parsers, not by standard JSON.
Is a trailing comma really invalid?: Yes, in JSON — although it is legal in JavaScript object literals, which is why the mistake is so common. JSON5 permits trailing commas; standard JSON does not.
Does validation modify my data?: No. The document is parsed and discarded; nothing is written, stored or returned other than the valid/invalid verdict and the error position.