Free JSON Validator

JSON Validation: Two Layers, Two Different Questions

A JSON validator answers a binary question, is this a well-formed JSON document?: by handing the input to the same parser the browser uses internally and reporting whether it accepts the syntax. This tool does that and only that. It does not check whether the data inside the document means what you intended it to mean. That second question (does the document have the shape, types and constraints your application expects?) is schema validation, the territory of tools like Ajv (covered below). The two activities complement each other and answer different questions; using one when you wanted the other is a category error. A useful analogy is the spelling-check / grammar-check distinction in word processors: spelling check (syntax) tells you whether each word is a real word; grammar check (schema) tells you whether the sentence makes sense; both are useful, neither replaces the other, and neither tells you whether the essay is good. {"phoneNumber": 12345} is well-formed JSON, but if your application expected a string formatted as "+1-555-555-1234", it is wrong, and a syntax validator cannot tell.

Beyond syntax-checking, this tool also offers a best-effort "Fix common issues" pass that rewrites the four most frequent ways developers accidentally write invalid JSON: trailing commas, single-quoted strings, unquoted keys, and undefined literals (rewritten to null). It is a heuristic, not a parser, so always review the corrected output before adopting it.

A Short History of JSON

JSON has a remarkably short biography. The acronym was coined at State Software, Inc., a small consultancy Douglas Crockford and Chip Morningstar co-founded in March 2001 to build what would later be called Ajax web applications. The first JSON message was sent in April 2001 from a computer in Morningstar's Bay-Area garage. Crockford does not claim to have invented JSON, the format already existed inside the JavaScript language as an object-literal subset; his contribution was to peel it off, give it a name, put up a website (json.org went up in 2002 with a description of the grammar in three notations and a JavaScript reference parser), and lobby for adoption. December 2005 is the moment most historians point to as JSON crossing into the mainstream: that month, Yahoo! began offering some of its web services in JSON. The IETF picked it up next: RFC 4627 ("The application/json Media Type for JSON"), authored by Crockford himself, was published in July 2006 as an informational document, not Standards Track. Standards bodies caught up in 2013-2014: ECMA-404 1st edition in October 2013 (deliberately minimal, six pages of substantive content), RFC 7159 in March 2014 (loosened the top-level restriction so any JSON value, not only objects and arrays, could be a complete document), and the current pair in December 2017: RFC 8259 (now Internet Standard STD 90) and ECMA-404 2nd edition normatively aligned with it. The two pair-bond: each normatively references the other and contains a commitment to keep them consistent. Also published as ISO/IEC 21778:2017.

The JSON Grammar in 200 Words

A JSON document is a single value, optionally surrounded by whitespace. There are exactly six value types: object: an unordered collection of zero or more name/value pairs, written {"k": v, "k2": v2}; array: an ordered sequence, [v, v2, v3] (arrays preserve order by spec); string: a sequence of Unicode characters wrapped in double quotes (single quotes not allowed; backslash escapes \", \\, \/, \b, \f, \n, \r, \t plus \uXXXX; control characters U+0000 through U+001F must be escaped); number: a strict ASCII form (optional minus sign, integer part with no leading zeros, optional fractional part, optional exponent with e or E); true / false: JSON booleans, lowercase only; null: the absence of value, lowercase only. Whitespace between tokens is permitted and ignored. No comments. No trailing commas. Object keys must be double-quoted strings. The grammar fits on one page. The strict number form forbids hex (0xFF), octal (0777), + sign, Infinity, NaN, and trailing decimal points like 1.; this catches anyone hand-writing JSON in environments that accept the looser ECMAScript numeric forms, most commonly, anyone who has ever pasted a hex colour code into a JSON file.

Why the Grammar Is So Strict, Crockford's Design Choices

Two deliberate omissions account for most of the friction users feel when writing JSON by hand. No comments. JavaScript has both // and /* */ comments; JSON, the JavaScript subset, has neither. Crockford's stated reason, posted on Google+ in 2012, has been quoted thousands of times since: "I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't." The argument is that comments invite extension, if // @schema foo.json is in your config and your tool reads it, then your config file is no longer JSON. No trailing commas. A comma is a separator, not a terminator. [1, 2, 3] is legal but [1, 2, 3,] is not. The reason is the same as for comments: simplicity of the grammar and uniformity across parsers. The cost is that anyone editing a multi-line JSON object (adding a property, rearranging properties, deleting the last property) has to think about the comma. No undefined. JavaScript has undefined; JSON does not. Use null or omit the property entirely. BOM in input. A byte-order mark (U+FEFF) at the start of a JSON document is forbidden in transmitted JSON, but parsers MAY ignore one if it shows up. In practice, files saved as "UTF-8 with BOM" by older Windows editors silently break some parsers and silently work in others.

Common Errors and What Each Diagnostic Means

• Trailing comma. Chrome reports "Unexpected token } in JSON at position N"; Firefox reports "expected double-quoted property name". Same fault from opposite ends, V8 reports the symptom (it expected a property name and got a closing brace), SpiderMonkey reports the same expectation in human-readable form. Cure: delete the trailing comma.
• Single-quoted strings. Chrome reports "Unexpected token ' in JSON at position N". JSON requires double quotes, period. The auto-fix changes ' to " in obvious cases but watch for apostrophes inside string values that then need escaping.
• Unquoted keys. JavaScript object literals allow bare identifiers as keys ({name: "Alice"} is legal JS). JSON does not, keys must be strings, and strings must be double-quoted. Catches anyone copy-pasting a JavaScript object into a JSON context.
• Comments. Forbidden in JSON. If the document is meant to be JSONC or JSON5 (covered below), it should be saved with the relevant extension and parsed with a parser that understands those dialects.
• Unescaped backslash. Inside a JSON string, \ is the escape character. "C:\Users\Alice" fails because \U and \A are not recognised escapes. The cure is to double every backslash: "C:\\Users\\Alice".
• Unescaped control characters. A literal newline, tab, or other character in U+0000-U+001F inside a JSON string is forbidden. Most users hit this when they paste a multi-line string into a JSON value without escaping the newlines as \n.
• NaN and Infinity. Not part of the JSON grammar. The browser's JSON.parse will reject them. JSON.stringify produces null when asked to serialise NaN or Infinity, so the round-trip silently loses information.
• Empty input. Throws "Unexpected end of JSON input." The gotcha is that an HTTP response that came back with Content-Type: application/json but an empty body produces this error in fetch().then(r => r.json()) chains.

JSON Schema, The Standard for Shape Validation

JSON Schema is a JSON-based vocabulary for describing the structure and constraints of JSON documents. The first proposal was submitted by Kris Zyp in October 2007; the IETF Internet-Draft series began with draft-zyp-json-schema-00 on 5 December 2009. Successive drafts evolved through a half-dozen authors and editors over the next decade and a half. The current stable version is the 2020-12 draft (the "2020-12" name refers to the development snapshot it derived from; the actual formal release was 16 June 2022). The four most-used assertion keywords carry most of the daily work: type (constrain a value to one of the six JSON types or a list of acceptable types), required (a list of property names that an object must contain), properties (a map of property name to sub-schema for the value), and items (a schema applied to every element of an array). Combined with minimum, maximum, minLength, maxLength, pattern (regex), format (date-time, email, IPv4, etc.) and the composite keywords (allOf, anyOf, oneOf, not), JSON Schema can express almost any "shape" constraint your data needs to satisfy. The schema is itself a JSON document, which is recursive in a way that some people find elegant and some find dizzying.

Ajv, The Dominant JavaScript Schema Validator

If you want to do schema validation in JavaScript, the canonical answer is Ajv (Another JSON Schema Validator) by Evgeny Poberezkin. Its trick is to compile the schema to optimised JavaScript: rather than walking the schema and the data tree at runtime, it generates a function that hard-codes every check and runs at native speed. This makes it dramatically faster than naive validators on large documents and on hot validation paths. Ajv supports JSON Schema drafts 04, 06, 07, 2019-09 and 2020-12; it's the validator built into express-validator, AWS API Gateway request validation and many of the major Node.js frameworks. For Python, the canonical pick is jsonschema by Julian Berman; for Java, Networknt's json-schema-validator. The point is that schema validation is a solved, mature, well-tooled problem, but it's a problem you have to opt into by writing the schema. This tool does not write the schema for you; it does syntactic validation only.

JSON5 and JSONC, The Relaxed Supersets

JSON5 is a formal superset of JSON specified at json5.org, originally designed by Aseem Kishore in 2012 and now maintained by Jordan Tucker. It allows everything strict JSON forbids: comments (both // and /* */), trailing commas, single-quoted strings, unquoted object keys (when they're valid ECMAScript identifiers), hexadecimal numbers, leading/trailing decimal points (.5 or 5.), Infinity and NaN, and signed numbers. JSON5 documents typically use the .json5 extension and are parsed by libraries like the json5 npm package. JSONC is Microsoft's informal "JSON with Comments" mode, used in VS Code's settings files (settings.json, launch.json, tasks.json). Comments are allowed by spec; trailing commas are tolerated by the reference parser but flagged with warnings. The relaxed forms are for human-edited configuration files where the discipline of strict JSON gets in the way; for machine-to-machine data interchange, strict JSON is still the right choice. This tool uses the browser's strict JSON.parse and so will reject both, strip comments and trailing commas before pasting, or use a JSON5/JSONC parser to convert to strict JSON first.

Streaming Validators for Very Large Inputs

Browser JSON.parse loads the entire document into memory as a single object tree. For most inputs this is fine; for log files, multi-gigabyte API exports or sensor-data dumps, it isn't. The streaming approach is to consume the document as a token stream and emit events ("array start", "string value", "object key") without ever holding the whole structure in memory at once. clarinet by Marak Squires is the canonical Node.js streaming JSON parser, modelled on the SAX XML parser pattern. Oboe.js by Jim Higson (originated in his 2013 dissertation) is the browser-friendly equivalent, designed to consume JSON over fetch as it streams in and emit events for every matched JSONPath; it's no longer actively maintained but the technique it pioneered is still useful. JSONStream on npm wraps clarinet for pipe-friendly Node usage. A pure-browser tool like this one is bounded by available memory; if you're validating gigabyte-scale JSON, run a streaming parser in Node or use jq --stream at the command line.

Where JSON Validation Matters in Real Workflows

Configuration files are the highest-leverage case: tsconfig.json, package.json, ESLint and Prettier configs, Docker Compose, AWS IAM policies. A single invalid character can break the build; a syntactic validator catches it before the build does. API responses are next: developing against an external API often means staring at a payload and asking "is this thing actually valid JSON?" before chasing a parsing bug deeper in the code. Webhook payloads (Stripe events, GitHub Actions triggers, Slack incoming webhooks) are JSON; a quick paste-and-validate catches the cases where a malformed signature or a stray byte has corrupted the body. Log entries (Splunk, Datadog, Loki structured logs) are line-delimited JSON; one bad line breaks the whole ingest pipeline. Generated JSON files (lockfiles, build manifests, test fixtures) sometimes drift in noisy ways during normal development; a syntax validator catches the cases where the generation step itself failed.

The Honest Limits of a Syntax-Only Validator

A syntactic validator cannot catch logic errors. It cannot tell you that a "phone number" field contains an integer instead of a string; that a "date" string is malformed but happens to be a valid string; that a required field is missing; that a number that should be positive is negative; that two fields that should match don't. All of those are schema-validation problems. The right pipeline for a production system is: (1) syntactic validation as a first gate (does this parse as JSON at all? (2) schema validation as a second gate) does it have the shape you expect? (3) business-logic validation as a third gate, does the data make sense given other state? Tools exist for all three layers; this one handles only the first. The advantage of pasting a payload into a syntactic validator first is that it isolates the cheapest, most common failure mode (a stray comma, a missing brace) from the more expensive schema errors that would otherwise drown them out.

Privacy: Why Browser-Only Matters Here

JSON validation on a server requires uploading the document. For ordinary public-data examples this is harmless. For API responses that contain authentication tokens, customer PII, internal employee records, configuration secrets, or unreleased product data, it is not. Even with the most scrupulous deletion policy, the upload sits in server logs, possibly in a CDN cache, possibly in an analytics pipeline, possibly in a backup. This tool runs JSON.parse in your browser via JavaScript. The pasted document never crosses the network, verify in DevTools' Network tab while you click a button, or take the page offline (airplane mode) after it loads and confirm the validator still works. Safe for validating webhook payloads with secrets, API responses with auth headers, configuration files with database credentials, or any other JSON that you would not want copied onto a stranger's hard drive.

Frequently Asked Questions

What counts as valid JSON?

A JSON document is a single value, optionally surrounded by whitespace. Valid types are object ({}), array ([]), string (in double quotes only), number (no leading zeros, no hex, no +, no NaN, no Infinity), boolean (lowercase true or false) or null. Object keys must be double-quoted strings. No comments. No trailing commas. The full grammar is in RFC 8259 (December 2017, Internet Standard STD 90) and ECMA-404 second edition.

What does "Fix common issues" do?

It runs a heuristic regex pass that rewrites the four most frequent JSON mistakes: trailing commas (removed), single quotes around strings (changed to double), unquoted object keys (wrapped in double quotes), and undefined literals (changed to null). It is not a real parser, so always review the output before adopting it, if your input has nested complications (e.g. apostrophes inside strings that themselves use single-quote delimiters) the simple substitutions can corrupt the data.

How do I validate JSON inside my own application?

Every modern language ships syntactic JSON parsing in its standard library: JavaScript / TypeScript JSON.parse (throws SyntaxError), Node.js JSON.parse on a string or stream, Python json.loads / json.load (raises json.JSONDecodeError), Go encoding/json Unmarshal, Java com.fasterxml.jackson or org.json, Rust serde_json. For schema validation use Ajv (JS), jsonschema (Python) or Networknt's json-schema-validator (Java). Wrap the parse call in try/catch and surface the parser's diagnostic message to the user, that's typically more actionable than a generic "JSON error" string.

Can I validate JSON5 or JSONC (JSON with comments)?

Not directly. This tool uses the browser's strict JSON.parse, which follows RFC 8259, comments, trailing commas, single quotes and unquoted keys are syntax errors. If your input is JSON5 (json5.org, Aseem Kishore 2012, maintained by Jordan Tucker) or VS Code's JSONC, install the json5 npm package or the jsonc-parser package, convert to strict JSON, then validate. The "Fix common issues" pass handles a subset of the differences but is not a full JSON5 / JSONC parser.

Is there a size limit?

No hard limit, but the browser's JSON.parse loads the entire document into memory as a single object tree. Tens of thousands of lines work comfortably; multi-gigabyte log dumps will exhaust memory. For very large JSON, run a streaming parser like clarinet (Marak Squires) or Oboe.js (Jim Higson, 2013), or use jq --stream at the command line, which can process arbitrary-size documents without ever loading the whole thing.

Are my JSON documents uploaded?

No. JSON.parse runs in your browser via JavaScript. The pasted document never crosses the network, verify in DevTools' Network tab while you click Validate, or take the page offline after it loads and confirm the tool still works. Safe for validating webhook payloads with secrets, API responses with auth headers, or configuration files with database credentials.