JSON Validator

A parse error gives you a position and an expectation, and both matter. The position is where the parser gave up, which is at or after the real mistake — never before it. The expectation tells you what would have been legal there, and that is often the faster clue: "expected a property name" points at a stray comma before a closing brace, while "unexpected end of input" almost always means something was never closed. Read the message rather than only the line number, and work backwards from the reported position.

Reaching for a validator means something has already broken, and the better outcome is catching it sooner. An editor with JSON language support underlines a trailing comma as you type it. A schema attached to your config files gives you autocomplete as well as validation. A CI step that parses every JSON file in the repository turns a broken config into a failed build rather than a failed deployment. Use this tool for JSON arriving from elsewhere — an API response, a webhook payload, a file someone sent you — and let tooling handle the files you own.

Four things, in roughly this order: a trailing comma after the last item in an object or array; single quotes instead of double quotes; unquoted object keys; and comments, which JSON does not support at all. All four are legal in JavaScript, which is exactly why they appear so often — they are the habits of a more forgiving syntax applied to a strict one. The Repair tool fixes all four automatically if you would rather not do it by hand.

Because a parser reports where it noticed the problem, not where the problem began. An unclosed brace or an unterminated string is only detectable once the parser reaches something impossible, which can be many lines later — and for a missing closing brace, that is often the very end of the file. When the reported line looks innocent, work backwards: check that every string on the preceding lines is closed and that braces and brackets balance above it.

No — those are separate questions. Validation confirms that the syntax parses; it says nothing about whether the required fields are present, whether a value is the right type, or whether a date is in the expected format. For that you want JSON Schema, which describes the shape your data should have and can be checked in tests or at an API boundary. Syntax validation is the floor, not the ceiling.

Usually because what came back is not JSON at all. A server returning an HTML error page, a proxy timing out mid-response and truncating the body, or a gateway injecting its own error will all arrive at a client expecting JSON and fail to parse. The first line of the response is the tell: if it starts with a tag or a status page, the problem is the request or the server, not the payload. Pasting the raw response here is a quick way to see exactly what you actually received.

No. Every tool runs in your browser as JavaScript — your data is never uploaded, never logged, and never sent to a server. You can confirm it by watching the Network tab in devtools while you work, or by disconnecting from the internet after the page loads and seeing that everything still functions. That matters for JSON in particular, because API responses routinely contain personal data, tokens, and internal identifiers.