Free · Fast · Privacy-first

Is This Valid JSON?

Not sure if a string is valid JSON? Paste it into FixTools.

⚡

Instant yes/no answer on any JSON string

🔒

Error location when not valid

✨

Plain-language explanation of what is wrong

⚡

Free, no sign-up, browser-based

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this JSON Validator to your website

Drop the JSON Validator into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/json/json-validator?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Validator by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/json/json-validator?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Validator by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

What Makes JSON Valid: The Complete Checklist

Valid JSON has to satisfy every grammar rule in RFC 8259 simultaneously. The top-level value must be one of: an object delimited by braces, an array delimited by brackets, a string delimited by double quotes, a number consisting of digits with optional decimal and exponent parts, the literal true, the literal false, or the literal null. Every string in the document, including every property name in every object, must be enclosed in double quotes. Every property in an object consists of a quoted name, a colon, and a value. Adjacent values inside an object or array are separated by exactly one comma. No comma appears after the last value. All braces and brackets are matched and properly nested.

Beyond the structural rules, there are content constraints. No comments are allowed anywhere in the document, neither the slash-slash style nor the slash-star style. All numbers are finite IEEE 754 values: NaN and Infinity are not permitted. All escape sequences inside string values use one of the eight allowed backslash escapes or the backslash-u four-hex-digit form. Every control character from U+0000 through U+001F that appears inside a string value must be written as an escape sequence rather than as a literal byte. The text itself must be encoded in UTF-8, UTF-16, or UTF-32, with UTF-8 being the practical default in virtually every modern system.

A useful mental model for quick manual checks on small JSON snippets is this triplet: every key is wrapped in double quotes, every comma is followed by another value, and every opening bracket has a matching closing bracket somewhere later in the document. If those three conditions hold for a small object, it is very likely valid. For anything larger or more nested, eyeball inspection becomes unreliable. The human visual system misses trailing commas and mismatched brackets routinely, especially in JSON that has been hand-edited or merged from multiple sources. A validator catches these in milliseconds with no judgment calls.

There is a useful distinction to draw between syntactic validity and semantic validity that the yes-or-no answer alone does not capture. A document can be syntactically valid JSON, meaning it parses without complaint against RFC 8259, while still being semantically wrong for the application that consumes it. The required field might be missing, the numeric value might fall outside the expected range, the string might fail a regex pattern, or the array might have the wrong number of elements. JSON Schema validation handles the semantic layer once syntax has been confirmed. Across draft versions, the semantic vocabulary has expanded steadily: Draft-07 added if/then/else conditional logic, Draft 2019-09 added unevaluatedProperties for compositional schemas, and Draft 2020-12 added prefixItems for tuple validation. A complete validity check therefore answers two yes-or-no questions in sequence: is this syntactically JSON, and does the parsed value satisfy the declared schema?

RFC 8259: The JSON Data Interchange Syntax JSON.org grammar railroad diagrams

How to use this tool

💡

Paste any text to find out if it is valid JSON. You get a clear yes or no, and if no, the exact reason and location.

How It Works

Step-by-step guide to is this valid json?:

1
Paste your text
Copy the string, file contents, or response body you want to check from wherever it currently lives. Paste it into the FixTools input area exactly as it appears in the source. Avoid retyping characters because that can introduce typos that did not exist in the original, which makes the validation result reflect your retyping rather than the actual data you intended to check.
2
Click Validate
Click the Validate button to run the check. The validator processes the input synchronously using the browser JavaScript engine and returns a result before you finish moving the mouse. There is no upload, no round trip to a server, and no waiting for a queue. The yes-or-no answer appears next to the input so you can see both the data and the verdict on the same screen.
3
Read the answer
A green confirmation means the input is valid JSON and any standard parser will accept it. A red message includes the line, column, unexpected character, and a description of the failure. The combination of all four pieces tells you exactly what went wrong, where, and what to do about it, with no need to consult a separate error reference or guess at the intent of a terse engine message.
4
Fix if needed
When the input is invalid, navigate to the reported line and column in your source editor and apply the fix that matches the error description. Common fixes are removing a trailing comma, replacing single quotes with double quotes, closing an unclosed bracket, or escaping a control character inside a string. Save the file and revalidate to confirm the fix worked and no other errors were lurking behind the first one.

Real-world examples

Common situations where this approach makes a real difference:

Developer receiving data

A developer receives a data file from a business partner and is not certain whether it is JSON, JSON5, or some proprietary format the partner cooked up. They paste the first few hundred characters into FixTools to find out. The validator reports invalid JSON at line one because of single-quoted strings, confirming the file is JSON5 rather than RFC 8259 JSON. The developer adjusts the import strategy to use a JSON5 parser, which the partner had been assuming was available but had never confirmed in writing.

Technical support

A support agent is troubleshooting a customer issue and the customer pastes their config file directly into the chat thread. The agent pastes it into FixTools to confirm the format before going deeper. The validator reports valid JSON, which means the file is not the cause of the failure the customer is hitting. The agent moves on to other suspects without wasting time investigating a JSON format issue that does not exist, and the resolution time drops by an entire diagnostic step.

Product manager

A product manager is reviewing an API contract document before it goes to external partners. The document includes example JSON payloads for each endpoint. They paste each example into FixTools to confirm the examples themselves validate. Two examples fail: one has a trailing comma in an array, one has an unquoted property key. They flag both for the author to fix before the document is published. The partners receive examples they can copy directly into integration tests without first having to repair them.

Automated testing setup

A developer is writing test fixtures for a new API and hand-creates ten JSON files representing different request shapes. Before committing, they paste each fixture into FixTools to confirm validity. Three of the ten have problems: a trailing comma, a missing closing brace, and a stray single quote. Fixing them before commit avoids confusing test failures later when a teammate runs the suite and sees a parse error in a fixture rather than a real test failure in the system under test.

Pro tips

Get better results with these expert suggestions:

JSON is case-sensitive for keywords

The literals true, false, and null must appear in lowercase exactly as written. Capitalised variants such as True, False, TRUE, or NULL are not valid JSON and the parser will reject them with an Unexpected token error. This rule trips up developers coming from Python, where the equivalent literals are True, False, and None, and developers coming from Ruby, where nil is the analogue of null. Always lowercase JSON literals regardless of what the source language uses.

Check bracket balance before anything else

The fastest manual sanity check on a JSON document is to count opening braces against closing braces, and opening brackets against closing brackets. If the totals do not match, the document is invalid before you even start looking for subtler issues. For large files where counting by eye is impractical, a formatter that indents the document by nesting level will visually expose unclosed structures because subsequent content will sit at the wrong indent depth.

Whitespace outside strings does not matter

JSON ignores whitespace, including spaces, tabs, and newlines, when it appears outside of string values. The compact form and the indented form of the same document are equally valid and parse to the same value. If a validator rejects an indented document but accepts the compact form of the same data, the cause is usually an invisible character that the indentation introduced, such as a non-breaking space or a tab disguised by the editor as four spaces, rather than the indentation itself.

A valid JSON string includes the outer quotes

If you are checking whether the JSON value representing the text hello is valid, the JSON itself is the five letters of hello surrounded by two double-quote characters, for a total of seven characters. The double quotes are part of the JSON syntax, not optional decoration. A JavaScript string variable that holds the five letters with no quotes is not yet JSON. To make it JSON, pass it through JSON.stringify, which adds the enclosing quotes and escapes any internal quote or control characters.

FAQ

Frequently asked questions

Paste it into FixTools and click Validate. The validator parses the input with the browser JSON.parse function and returns either a green valid result or a red invalid result with line, column, and a description of the failure. As an alternative for quick checks in a browser console, run try { JSON.parse(yourString); console.log("valid"); } catch (e) { console.log("invalid:", e.message); }. FixTools gives more readable output with a real line and column rather than a raw character offset, which makes it faster for manual debugging during development.

The top-level value must be one of the seven permitted JSON values: an object, an array, a string, a number, true, false, or null. All property names in all objects must be double-quoted strings. All string values must use double quotes. No trailing commas may appear after the last item in an object or array. No comments are permitted anywhere. Numbers must be finite, so NaN and Infinity are not allowed. All control characters inside strings must be escaped. All opening braces and brackets must have matching closing counterparts in correct nesting order.

Yes. The four-letter word null with no surrounding quotes is a valid top-level JSON value. JSON.parse called with the input null returns the JavaScript null value. The same holds for true and false, which are the only other unquoted non-numeric literals permitted in JSON. These three keywords cover the cases where you need to represent absence or a boolean state at the top of a document without wrapping the value in an object or array. RFC 8259 explicitly allows all three as standalone documents.

Yes. The two-character text consisting of an open brace immediately followed by a close brace is the empty object literal and is valid JSON. The corresponding bracket pair is the empty array literal and is also valid. The empty string literal, two double-quote characters in sequence with nothing between them, is a valid JSON string. The number zero is valid JSON. The literal null is valid JSON. The truly empty input, no characters at all, is not valid JSON because the parser reaches end of input before finding any value.

No. Syntactic validity means the bytes parse cleanly into a value. It does not say anything about whether the value matches what your application expects. A response can be perfectly valid JSON while still missing required fields, having wrong types in some properties, containing values that violate a business rule, or having an entirely different structure than your code is written for. Syntax validation is the first gate; schema validation against a defined JSON Schema is the second gate; application-level business rule checks are the third. All three are needed.

No. JSON is a data interchange format, not a code format. It cannot contain function literals, expressions, getters, setters, regular expressions, or any other JavaScript construct that does not reduce to a string, number, boolean, null, object, or array. JSON.parse is safe from code injection for exactly this reason: there is no construct in JSON that triggers code execution during parsing. Any attempt to embed something that looks like code, such as a literal function expression, immediately fails the grammar check and produces a parse error.

No. JSON5 is a superset of JSON that adds developer conveniences such as single-quoted strings, unquoted property names, trailing commas, comments, hexadecimal numbers, and a leading-plus sign on numbers. A document that uses any of those JSON5 features is not valid RFC 8259 JSON and will fail in a standard parser. JSON5 requires a dedicated parser such as the json5 npm package. Do not assume that a tool which accepts JSON5 is doing standard JSON validation; the verdict will be more lenient than what your production parser will accept.

Any Unicode string can be a JSON property name as long as it is wrapped in double quotes and any special characters inside it are properly escaped. Names with spaces, leading digits, punctuation, emoji, non-Latin scripts, or even an empty string are all valid as property names. This is broader than the rules JavaScript imposes on object literal keys, where some character combinations require bracket notation. In JSON the only rule is that the name is a valid JSON string, which any sequence of properly escaped characters between double quotes satisfies.

Wire validation into CI so any pull request that introduces invalid JSON fails the build before it can merge. A typical GitHub Actions job runs find . -name "*.json" -print0 | xargs -0 -n1 jq . > /dev/null over the entire tree, exiting non-zero on the first failure. For repositories with hundreds of JSON files, parallelise the check using GNU parallel or xargs with the -P flag to cut wall-clock time. Add a pre-commit hook using the check-json hook from the standard pre-commit framework so the same check runs on the developer machine before the commit even reaches the remote. For schema-level validity, layer AJV or ajv-cli on top of the syntax check to confirm each JSON document matches its declared schema. The cumulative effect of multiple checking layers is that invalid JSON simply cannot reach the main branch under normal workflow, which removes an entire category of recurring debugging cost from the team.