How to validate JSON (RFC 8259)
Check syntax before you ship configs, API fixtures, or hand-edited payloads.
Validation answers a different question than formatting. Pretty-printing makes JSON readable; validation asks whether the text is legal JSON at all. JSON Quiet can do both in the browser. This guide focuses on what RFC 8259 requires, how strict and relaxed modes differ on this site, and why catching syntax errors early saves time in CI and production.
What RFC 8259 is
RFC 8259 is the modern Internet standard for the JSON data interchange format. It defines the grammar for objects, arrays, strings, numbers, true, false, and null. It also clarifies encoding expectations (UTF-8 is the practical default on the web) and removes ambiguity that older informal descriptions left open.
Important: RFC 8259 is about syntax, not about your application’s schema. A document can be perfectly valid JSON and still be the wrong shape for your API (missing required fields, wrong types). Schema checks (JSON Schema, OpenAPI, etc.) are a separate layer. JSON Quiet’s Validate button targets syntactic validity so parsers and JSON.parse-style APIs will accept the text.
Why validation matters
- APIs — clients and servers reject invalid JSON with opaque 400 errors; validating locally shows the real syntax issue first.
- Config and IaC — one trailing comma can break a deploy; validating before commit avoids “works on my machine” surprises.
- Hand edits — copying from JavaScript object literals often introduces single quotes, comments, or
undefined, none of which are JSON. - Shared fixtures — tests that load JSON files fail loudly when a fixture is broken; validate when you edit fixtures.
Strict mode (recommended)
In Options, choose RFC 8259 (recommended) for strict validation. In this mode, the document must follow standard JSON rules. Typical failures include trailing commas after the last property, single-quoted strings, unquoted object keys, comments (// or /* */), and JavaScript-only values such as NaN, Infinity, or undefined.
Use strict mode whenever the JSON will leave your editor: production configs, public API examples, and anything another language’s JSON library must parse. Interoperability is the point of the standard — if it only parses in one forgiving tool, it is not portable JSON.
Relaxed mode
Relaxed validation is a convenience while you clean up a messy paste. It can be more forgiving of certain common issues (for example trailing commas) so you can iterate toward a valid document without fighting every rule at once. Treat relaxed mode as a workshop setting, not as a stamp of production readiness.
When the payload looks right, switch back to strict RFC 8259 and Validate again. Ship only what passes strict mode unless you control every consumer and know they accept the same extensions — which is rare across languages.
Skip validation
Options also allow skipping validation. That can help if you only want to rearrange whitespace on text you already trust. Skipping does not make invalid JSON valid; it only stops the tool from checking. Prefer Validate when you are unsure.
How to validate with JSON Quiet
- Open the formatter and paste JSON, open a file, or load a public URL.
- Open Options and select RFC 8259 (or Relaxed while cleaning up).
- Click Validate.
- Read the status line. Success confirms syntactic validity; failure messages often include line and column.
- Fix the first error, then validate again — parsers usually stop at the first problem, so later issues appear after earlier ones are fixed.
You can Format after a successful validation to pretty-print, or Format first if you need readability to find the bad token. See how to format JSON for the pretty-print workflow.
Reading error messages
When validation fails, start at the reported line and column. Look for an extra comma, a missing brace, or a string that was never closed. If the message is vague, compare the surrounding text to patterns in the common JSON errors guide. Fix one issue at a time and re-validate; chasing multiple hypothetical bugs at once is slower.
What validation does not guarantee
Valid JSON can still contain wrong business data, unsafe content, or encoding problems outside the editor. Validation here does not scan for malware, does not enforce your schema, and does not replace security review of untrusted input in your applications. It answers: “Can a standards-compliant JSON parser read this text?”