JSON Validator

No. Syntax validation only checks `JSON.parse` rules: braces, quotes, commas, and literal types. A file can be syntactically valid yet violate your API (wrong field types, missing required keys). Use JSON Schema, OpenAPI, or integration tests for semantic guarantees; use this page when you need a fast pass/fail on raw text.

They are derived from the engine’s reported character index in your pasted string. Minified one-line JSON always shows line 1 with a large column. If your editor counts UTF-16 code units differently than the browser for rare surrogate pairs, the caret may shift slightly—still close enough to locate a stray comma.

Other stacks allow relaxed modes: trailing commas, NaN, Infinity, or unquoted keys. Strict JSON forbids those. `json.dumps` may also escape Unicode differently yet remain valid. If this tool says invalid, compare against RFC 8259 and normalize quotes or remove comments before shipping cross-language.

All parsing is local to your tab. That makes the tool safe for internal config snippets, but remember clipboard history extensions and screen recorders still exist—treat secrets as secrets regardless of tooling.

That page optimizes for edit-format-copy loops. This page foregrounds validation messaging and only shows prettified output after a successful parse, which matches QA flows (“is this prod response JSON-shaped at all?”) before you drop it into Postman collections.

Standard `JSON.parse` consumes one top-level value. NDJSON streams need line-by-line parsing in a script. If you paste multiple root objects back-to-back without an array wrapper, validation fails by design—wrap them in `[ ]` or validate each chunk separately.