CDRN

Validate JSON syntax

  • Dashboard
  • Documentation
  • API
checks the syntax of a JSON string and reports the line and column of any error

What is a JSON validator used for?

A JSON validator has a more modest, but more precise, role than a formatter: it does not rewrite anything. It takes a string and answers a binary question: is this text JSON conforming to RFC 8259? If yes, the tool hands back control. If not, it indicates exactly the line, the column and a JSON excerpt around the problem, to help the developer fix it immediately.

In practice, it is the tool you reach for as soon as a parser somewhere returns a cryptic error message like SyntaxError: Unexpected token } in JSON at position 217. Rather than counting characters by hand in an editor, you paste the complete string, read the position and see the offending excerpt.

Validation and formatting: two distinct operations

The two are often confused. Our JSON formatter takes valid JSON and rewrites it with readable indentation. The validator, on the other hand, just gives a syntactic verdict. It does not perform semantic validation: it does not know whether an email field looks like an email, nor whether the structure matches a JSON Schema. For that, you use dedicated tools (ajv in Node, justinrainbow/json-schema in PHP).

The classic debug chain is: validate first (the tool indicates the syntax error), format next (the now-valid payload becomes readable), compare finally with another reference payload using our JSON comparator.

The most frequent JSON errors

  • Trailing comma: {"a": 1, "b": 2,}. Tolerated by JavaScript, ECMAScript and JSON5; rejected by pure JSON. This is the number one error when copy-pasting from a code editor.
  • Single quotes instead of double quotes: {'a': 1} is invalid. JSON accepts only double quotes, around both keys and string values.
  • Unquoted keys: {a: 1}, valid JavaScript syntax but invalid JSON.
  • Unescaped control characters in a string: a raw line break, a tab. JSON requires \n, \t, \r.
  • Comments: // comment or /* */. Accepted in JSONC (VS Code config) or JSON5, rejected in pure JSON.
  • Incorrect encoding: a UTF-8 BOM at the start of the file, latin-1 content poorly converted. The validator often returns a generic message for these cases.
  • Unterminated structure: a { or [ without closing, frequent when a payload is truncated during copy-paste.

How the validator locates the error

The tool uses PHP's json_decode() with the JSON_THROW_ON_ERROR flag. PHP returns a message containing a byte position (position 217), which we convert into a line/column pair by counting the newlines before the offset. An excerpt of about 80 characters is then sliced around the position to give context. This is usually enough to spot the error: a misplaced quote, an extra comma, a missing bracket.

Beware: the position reported by PHP is not always exactly the offending character. It is often after the error, at the point where the parser gave up. If the excerpt shows "name": "Alice", }, the actual error is the comma, not the brace.

Typical use cases

  • Corrupted configuration: composer.json, package.json, tsconfig.json that prevent a build from starting. You paste, see the line, fix it.
  • Truncated API response: a proxy cut the payload. The structure is not terminated, the validator flags it.
  • Webhook payload: a third-party service sends malformed JSON. The validator lets you see the problem on the sender's side without diving into application code.
  • JSON built by concatenation: a practice to avoid but common, especially in bash or SQL. The validator reveals unescaped double quotes.

Tool limits

The validator does not perform schema validation. It does not say that the email field is missing, that the value is not an integer or that the expected array does not have the right length. For these structural checks, you use JSON Schema. The validator also does not correct the JSON: it does not try to add a missing brace, nor to remove an extra comma. This is a choice: automatic correction too often hides real errors.

Frequently asked questions

What is the difference with a linter?

A linter goes further: it also checks style rules (alphabetical order, naming conventions), detects duplicate values, suggests improvements. The validator stays on syntactic conformance.

My JSON is valid, but my application rejects it?

Check the encoding (UTF-8 without BOM), the server-side size limit, the expected types. Syntactically correct JSON can still fail to match the application schema.

Does the validator keep my JSON?

No. Processing is synchronous server-side, without persistence. For very sensitive data, still prefer a local validation via jq or a PHP script.

Example request

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

Input schema

Field Type Required Default
input text ✓ –

Endpoints

  • GET https://cdrn.fr/api/v1/tools - lists every available tool
  • GET https://cdrn.fr/api/v1/tools/json-validator - returns the schema for this tool
  • POST https://cdrn.fr/api/v1/tools/json-validator/execute - runs this tool with a JSON payload