A JSON Validator Is Not JSON Schema (RFC 8259 vs a Contract)

DevOkk splits the jobs. JSON Validator is RFC 8259 with a line and column on the first error. Default {"ok":true} passes. {"ok":true,} fails. JSON Schema Validator is draft 2020-12 against a schema you paste. JSON Formatter pretty-prints after (or while) the text parses. JSON5 is a different dialect on JSON5 Validator. The how-to for messy API pastes is How to format and validate JSON. Common breaks are How to fix invalid JSON.

No account. Syntax and schema parse in the browser. That still does not make a production dump a good paste.

RFC 8259 is a grammar, not your types

JSON is objects, arrays, strings, numbers, true, false, null. Keys in objects are strings in double quotes. No comments. No trailing commas. No undefined. No single quotes. That is the validator’s universe.

{"age":"30"} is valid JSON. A schema that says age is integer will fail it. {"age":30} is valid JSON and may still fail a schema that requires minimum: 0 if you send −1. The syntax tool will smile through both the string and the negative integer.

If you only ever use a syntax validator, you will ship fixtures that CI’s schema step rejects. That is not the validator lying. You asked the wrong question.

What the JSON validator’s primary output is

The page is built so the headline is Valid RFC 8259 JSON or Invalid JSON with a position. It will not pretty-print as the main result. Copy copies the validation report. After the document is valid, indent it on the formatter if you need to read it. After you need a path, use JSON Viewer. After you need a graph, use JSON to Graph Visualizer.

JSONLint lives in the same mental slot as the syntax page. DevOkk’s extra is the rest of the hub, including schema. Do not assume JSONLint is checking your draft-07 file unless that product’s current UI says so.

JSON Schema is a different program

A schema is a document that describes other documents: required properties, types, formats, $ref, combinators. Draft 2020-12 is what DevOkk’s schema tool targets. Older drafts exist in the wild. If your team’s file is draft-04, read the schema tool’s own limits instead of assuming 2020-12 silently “upgrades” it.

Schema success means “this instance satisfies this schema,” not “the backend will accept it.” The backend can have extra rules: unique database keys, rate limits, auth. Schema failure means “this instance does not satisfy this schema,” not “the JSON is syntactically broken.” Run syntax first when the paste might not even be JSON (HTML error page, truncated copy, undefined).

BOM, NDJSON, and numbers JSON.parse will accept

A UTF-8 BOM at the start of a file makes some parsers unhappy and others skip it. If the first error is column 1 on a file that “looks fine” in an editor, strip the BOM. That is still syntax, not schema.

NDJSON (one JSON value per line) is not one JSON document. The validator wants a single value. Split lines, then validate each. Two objects concatenated }{ fail as one document. The fix-invalid guide covers that shape.

JSON numbers are IEEE-ish in browsers. Integers larger than Number.MAX_SAFE_INTEGER can round. Syntax still says valid. Your money field may already be wrong. Schema type: integer does not restore precision that JSON.parse lost. Use strings for identifiers that must not round.

{"ok": true} with a leading ) from a copy-paste of a console snippet fails. HTML error pages that contain a { somewhere fail as JSON unless the whole body is a JSON value.

Duplicate keys: valid enough to hurt

{"a":1,"a":2} is accepted by JSON.parse. The surviving value is 2. RFC 8259 says keys should be unique; typical browsers do not throw. A syntax validator that wraps JSON.parse cannot show you the discarded 1. A schema that requires a to be 1 will see 2 and fail, which looks like a schema bug if you thought both keys were there.

If uniqueness matters, do not trust a syntax-only page. Compare keys in a linter that flags duplicates, or inspect the parsed object and remember what was lost.

JSON5, JSONC, and “JSON with comments”

{a:1,} is illegal JSON and legal JSON5. // comment is illegal JSON. If the file is a Babel or TS config that was always JSON5, the RFC 8259 page is supposed to fail. Open JSON5 Validator. If the API requires RFC 8259, strip the extensions; do not relax the validator. The dialect article is JSON vs JSON5: what validators accept.

Repair tools that emit strict JSON from messy text are a third job. Use them when you intend to leave the dialect, not when you intend to keep JSON5.

Worked example: valid, wrong, then schema

1. Paste {"ok":true}. Syntax validator: valid. Schema that requires status string: fail.
2. Paste {"ok":true,}. Syntax: invalid, trailing comma, line and column. Schema never runs on a document that is not JSON - or it never should. Fix the comma first.
3. Paste {"age":"18"}. Syntax valid. Schema {"type":"object","properties":{"age":{"type":"integer"}},"required":["age"]} fails.

That sequence is the whole product split.

Unicode, trailing commas in pretty-print, and “it worked in JavaScript”

Pretty-printers that emit trailing commas are JSON5 or JS, not JSON. If you format in an editor with a JS parser and then paste into the RFC 8259 validator, you will “break” a file the editor liked. That is the dialect split, not a DevOkk defect.

Unescaped control characters in strings fail JSON. Some logs paste a raw newline inside a string. The line/column on the validator is the point of the tool. The formatter will not invent an escape for you as a silent repair.

Deeply nested objects can be valid and still crash a naive recursive pretty-printer. Validity is not “fits in this textarea comfortably.” Size limits are a product constraint, not RFC 8259. If the document is valid and still the wrong shape, that is a schema job, not another comma.

true versus "true" and empty arrays

{"ready":true} and {"ready":"true"} are both valid JSON. Only one is a boolean. Schema type: boolean catches the string. A syntax validator will not. Empty array [] is valid. Schema minItems: 1 fails it. null is valid JSON. Schema type: object fails it. These are the weekday tickets that look like “the validator is broken.”

JSON.parse('{"n":1e2}') is 100. Syntax valid. If a schema expected a string identifier "1e2", you already lost. Scientific notation in JSON numbers is legal; it is still a number.

Schema drafts and $ref are not syntax

Draft-04, draft-07, and 2020-12 disagree about some keywords. DevOkk’s schema tool targets 2020-12. A syntax-valid instance can fail because $ref did not resolve, or because unevaluatedProperties did something you did not expect. That ticket belongs on JSON Schema Validator, not on the RFC 8259 page. Do not “fix” valid JSON by deleting required fields until a schema you did not read goes green.

OpenAPI files are YAML or JSON with a schema language inside. Validating the OpenAPI file as RFC 8259 is necessary and nowhere near sufficient.

A schema that requires age to be an integer will fail "30" even though RFC 8259 is happy. That is the whole split in one ticket.

Size, secrets, and the textarea

The validator is for documents you are willing to keep as a string in the page. A huge dump belongs in a worker with a size cap, not this input. Tokens, session cookies, and customer PII still should not be a casual paste; see What not to paste into online developer tools. Local parse is not a license. localStorage can remember the draft for up to 30 days. Clear it.

YAML and XML are not JSON. Validate YAML on YAML Validator, XML well-formedness on XML Validator, then convert if you must: YAML to JSON, XML to JSON.

Valid JSON can still be the wrong contract

Open JSON Validator when the question is “is this RFC 8259.” Open JSON Schema Validator when the question is “does this instance match this schema.” Open JSON Formatter when the question is “make it readable.” A green syntax result is the start of review, not the end of QA. The contract lives in the schema file - or in the API - not in the fact that the braces matched.