Fast, practical, browser-based developer tools
Validate JSON instantly in your browser. You can also beautify, minify, sort keys, copy output, and download validated JSON. This tool is useful for developers, testers, API users, students, and anyone working with raw JSON data.
A JSON validator helps you catch broken syntax before it causes API, frontend, or config problems. This tool also includes formatting, minification, key sorting, copy, and download actions in one place for faster JSON workflows.
This JSON validator is designed to work directly in your browser during normal use. That makes it useful for local validation, debugging, cleanup, API testing, and structured data workflows.
For more details about site usage and analytics, read our Privacy Policy.
Paste your JSON into the input box, then choose the action you need. You can validate the syntax, format the output for readability, minify it for compact use, sort keys for consistency, and then copy or download the result.
{
"name": "john",
"skills": ["json", "api"],
"active": true,
"profile": {
"country": "US",
"role": "developer"
}
}
This validator runs your text through JSON.parse(). If it parses, the JSON is
syntactically valid: brackets balance, strings are properly quoted and escaped,
and the grammar of RFC 8259 is satisfied. That is a real and useful guarantee, but it is a
narrow one. Syntax validity says nothing about whether the data is the data you meant.
A green checkmark does not mean a required field is present, a date is in the right format, a number is in range, or that the document matches an API's contract. Those are questions of schema validity, enforced by JSON Schema or the receiving service, not by a syntax parser. It is entirely possible to have JSON that every parser accepts and that still gets rejected by the endpoint you send it to.
When valid-looking JSON fails, it is almost always because it is actually JavaScript. These
four things are legal in a .js file and illegal in JSON:
[1, 2, 3,] and a comma after the last
object property are both rejected. This is the single most common cause.
{'a': 1} is a JavaScript object literal, not JSON.
{a: 1} is likewise JavaScript. Every key
must be a double-quoted string.
// nor /* */ exists in
JSON. Config files that allow them (like tsconfig.json) use JSON5 or
JSONC, which are different formats.
Parse errors report where the parser gave up, which is usually a token or two
past the real mistake, not on it. A message like
Unexpected token ] in JSON at position 48 after a trailing comma points at the
bracket, because the comma made the parser expect another value and the bracket is where
that expectation broke. When an error lands on a closing bracket, a quote, or end-of-input,
look at what comes immediately before it.
A raw newline or tab pasted inside a string produces this too. Control characters
in the range U+0000–U+001F must be written as escapes such as \n and
\t; a literal line break inside quotes is a syntax error, which is exactly the
problem a JSON escaper solves.
Duplicate keys pass. RFC 8259 only says object names should be
unique, so {"id":1,"id":2} is valid JSON. JSON.parse() silently
keeps the last occurrence and discards the first, so a validator reports success while you
quietly lose a field. If two systems disagree on which duplicate wins, you get a bug no
validator will flag.
A leading byte-order mark fails. Files exported from Excel or saved as
"UTF-8 with BOM" on Windows begin with an invisible U+FEFF character, and
JSON.parse() throws on it even though the visible content looks perfect. Strip
the BOM before parsing.
A bare value is valid. Under RFC 8259 the top level can be any JSON value,
so 42, true, and "hello" are all complete, valid
documents — a change from the older RFC 4627, which required an object or array at the
root. And large integers still validate even though JavaScript cannot hold them precisely;
syntax checking never touches the 253 precision limit.
It is probably JavaScript, not JSON. Trailing commas, single quotes, unquoted keys,
and comments are all legal in a .js file and rejected by a JSON parser.
Code copied out of source often carries one of these.
RFC 8259 only says object keys should be unique, not that they must be, so
{"id":1,"id":2} is technically valid. JSON.parse() keeps the
last one and drops the rest without warning, which means a passing check can still hide
a lost field.
No. Validation confirms the syntax parses, not that required fields exist, types are right, or the document matches an API's expectations. Those are schema concerns handled by JSON Schema or the receiving service, not by a syntax check.
It likely starts with a byte-order mark (U+FEFF), an invisible character added by Excel and some Windows editors when saving "UTF-8 with BOM". Parsers throw on it even though the content looks fine. Re-save without the BOM.
Yes, under the current RFC 8259: any JSON value can stand alone at the top level, so
42, true, and "hello" are each complete
documents. The older RFC 4627 required an object or array at the root, which is why
some legacy parsers still reject bare values.
Usually just past it. The parser reports where it could no longer continue, so an error on a closing bracket or quote generally means the real problem — a stray comma, a missing value — is the token right before it.