Validate JSON Online

How to Validate JSON Online

1. Paste or Upload Your JSON: Paste any JSON text into the Input (JSON) panel, or drag and drop a .json file onto the editor. The validator accepts anything from a single primitive (true, null, a number, a quoted string) to multi-megabyte object trees. Files never leave your browser session.
2. Click Validate: Press the Validate button. The tool parses the input with the browser's JSON.parse() and reports either a green "Valid JSON" banner or the line and column of the first syntax error — for example, Unexpected token } in JSON at position 247 mapped to line 12, column 5.
3. Read the Error Details (If Invalid): The error panel shows the offending line number, column number, and a human-readable description (mismatched bracket, unexpected character, unterminated string). The input panel scrolls to the offending character so you can fix it in context. Common culprits: trailing commas, single quotes, unquoted keys, comments, NaN / Infinity literals — none of which are legal in standard JSON.
4. Fix and Re-Validate, Then Format or Minify: Edit the input, click Validate again, and repeat until the banner turns green. Once valid, switch to JSON Formatter to pretty-print with indentation or JSON Minifier to strip whitespace for production payloads.

Why Validate JSON?

JSON is everywhere — REST APIs, config files (package.json, tsconfig.json, AWS IAM policies, Firebase rules), webhook payloads, NoSQL documents, JWT claims — and a single misplaced comma can break an entire pipeline. RFC 8259 (the current IETF JSON standard, jointly authoritative with ECMA-404) defines a strict grammar: double-quoted strings only, no trailing commas, no comments, no NaN or Infinity, only true/false/null as literals. Validating before you ship catches these problems while they're still cheap to fix.

• Debug API integrations — When a request returns 400 Bad Request with "Invalid JSON", paste the body in and you'll see the exact character that tripped the server. Saves trawling a 600-line payload by eye.
• Check hand-edited config files — tsconfig.json, package.json, AWS IAM policies, Kubernetes manifests, GCP service-account keys — one stray comma after the last property and your build, deploy, or container won't start. Validate after every edit.
• Verify data exports — JSON dumps from MongoDB, Firestore, BigQuery, or ETL pipelines occasionally arrive truncated or with mixed encodings. Validate the file before feeding it to a downstream consumer that will produce far worse error messages.
• Sanity-check copy-pasted JavaScript objects — JS object literals look like JSON but aren't: they permit unquoted keys, single quotes, trailing commas, comments, and undefined. Validation immediately surfaces the difference.
• Sanitize user input in apps — Webhook bodies, custom filter expressions, configuration overrides — validate on the client before sending so users get instant feedback and your backend doesn't waste cycles on malformed payloads.
• Learning the spec — Type, validate, read the error, fix, repeat. Faster than reading the RFC.

Working with related formats? Try JSON to CSV, JSON to YAML, JSON to XML, or CSV to JSON.

Standard JSON vs JSON5 vs JSONC — What This Validator Accepts

This validator checks standard JSON only. If your file is JSONC (the dialect VS Code uses for tsconfig.json and settings.json) or JSON5 (an ES5-inspired superset), strip comments and trailing commas before validating, or use a tool that targets that dialect specifically.

Common JSON Errors and What They Mean

Frequently Asked Questions

Does this validator check against a JSON Schema?

No — this is a syntax validator only. It confirms your input is well-formed JSON per RFC 8259, but it does not check that fields match a contract (e.g., "age must be an integer between 0 and 150"). For schema validation you need a JSON Schema engine such as Ajv (Node/browser), python-jsonschema, or everit-org/json-schema (Java). Syntax validity is a prerequisite for schema validation, so this tool is still the right first step.

Does it accept JSON5 or JSONC?

No. JSON5 (which permits comments, trailing commas, single quotes, hex numbers, NaN, and Infinity) and JSONC (the VS Code dialect with comments and trailing commas, used in tsconfig.json and settings.json) will both fail validation here. That's by design — the tool reports compliance with the standard, not with any superset. Strip non-standard features first or use a JSON5-aware parser.

Why does my JSON fail on a trailing comma?

RFC 8259 grammar treats , strictly as a separator between elements, with no provision for one after the last element. JavaScript permits trailing commas (since ES5 in arrays, ES2017 in function calls, ES2017 in object literals), which is why developers reach for them by reflex — but standard JSON parsers including JSON.parse(), Python's json module, Go's encoding/json, and Java's Jackson all reject them. Remove the comma after the last property or element.

How do I handle unescaped backslashes in strings?

A literal backslash in a JSON string must be written as \\. Common offenders: Windows file paths ("C:\Users\Alice" is invalid — write "C:\\Users\\Alice"), regex source (write "\\d+" not "\d+"), and LaTeX (\\ becomes \\\\). If a parser complains about an "invalid escape", scan for lone backslashes followed by characters other than ", \, /, b, f, n, r, t, or u — those are the only legal escape sequences.

Can JSON have multi-line strings?

Not directly. RFC 8259 says a string runs until its closing " and a raw newline character inside that string is invalid. The standard escapes are \n (newline) and \r (carriage return). If you have a multi-line block to encode, either escape the newlines ("line one\nline two") or split it into an array of lines (["line one", "line two"]). JSON5 and YAML allow real line breaks; standard JSON does not.

Can I put comments in JSON?

Per RFC 8259, no — and the document explicitly notes that Douglas Crockford removed comments from JSON early on because implementations were using them for parsing directives, which broke interoperability. If you want comments, use JSON5, JSONC, or YAML; alternatively, add a convention like an underscore-prefixed key ("_comment": "explanation here") that consumers ignore.

What about NaN, Infinity, and -Infinity?

Not legal in standard JSON. The RFC states explicitly that "numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted." Many parsers (Python's json with allow_nan=True, JavaScript's JSON.stringify when given these values) emit them anyway as an extension — but the result will fail strict validation. Use null, a quoted string "Infinity", or your own sentinel value instead.

Why does a top-level number or string sometimes get rejected by other validators?

The original RFC 4627 (2006) required a JSON document to be either an object or an array at the top level. RFC 7159 (2014) and the current RFC 8259 (2017) loosened this — a single primitive like 42, "hello", true, false, or null is now a valid JSON document. Old validators or parsers may still reject these. This tool follows the current spec and accepts top-level primitives.

How large a file can I validate here?

The validator handles inputs up to several megabytes comfortably; beyond ~10 MB performance depends on your browser and device RAM since JSON.parse() reads the whole document into memory. For very large files (logs, dumps), use a streaming parser on the command line: jq . file.json > /dev/null (errors on stderr), python -m json.tool file.json > /dev/null, or ijson for true streaming in Python.

Does the validator send my data anywhere?

No. All parsing happens client-side via the browser's JSON.parse() after the page loads — no upload, no server round-trip, no logging. You can validate API keys, PII, healthcare data, or internal configs safely. Disconnect from the network after the page loads and validation still works.