Free · Fast · Privacy-first

Validate a JSON String

When a variable in your code might or might not contain JSON, you need a way to find out before you commit to JSON.parse.

⚡

Confirm a string is valid JSON before parsing

🔒

Identifies exactly what makes the string invalid

✨

Shows line and column of every error

⚡

Free, instant, runs in your browser

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.

Checking Whether a String Is JSON: Edge Cases You Need to Handle

A JSON string, in the RFC 8259 sense, is any sequence of bytes that conforms to the JSON grammar. The grammar is broader than developers usually expect. The top-level value can be an object, an array, a string, a number, a boolean, or null. So the value 42 by itself is valid JSON, as is true, as is the literal "hello" with the double quotes included. This matters when you write a quick check for whether a variable contains JSON: a naive starts-with-curly-brace test rejects valid JSON values that begin with a digit, a letter, or a double-quote character. If your data source ever returns top-level scalars, your check has to accommodate them.

The practical pattern for checking a string before parsing is to attempt the parse inside try-catch and decide policy in the catch clause. The block looks like try { const parsed = JSON.parse(candidate); handle(parsed); } catch { handleNonJSON(candidate); }. The interesting design choice is what handleNonJSON does. If the data is supposed to be JSON, the catch branch should log, alert, or return a typed error. If the field is a hybrid that legitimately holds either JSON or plain text, the catch branch is normal control flow. A standalone isValidJSON helper that returns a boolean is appropriate when you need to branch on the result without immediately parsing.

Edge cases that catch out developers writing string validators include the following. An empty string is not valid JSON. A whitespace-only string is not valid JSON. The value undefined is not a string at all and JSON.parse will coerce it to the literal text undefined, which then fails. Numbers with leading zeros, such as 007, are invalid per the grammar because they look like octal. Very long strings can blow the maximum call depth in some parsers if they contain deep nesting. Files saved with a UTF-8 BOM contain an invisible U+FEFF byte at the start that breaks the grammar even though the file looks empty up to that point. FixTools surfaces every one of these cases by name.

The distinction between a string validator and a string parser matters for performance-sensitive code paths. A pure validator answers the yes-or-no question of whether the input conforms to the grammar without producing the parsed value. A parser produces the in-memory data structure as a side effect of validation. JSON.parse in standard JavaScript is a parser: even when you only need the verdict, it still allocates the structure and then discards it if you ignore the return value. For batch validation of millions of strings, this allocation overhead adds up. Specialised libraries like simdjson and yyjson offer validate-only entry points that skip the allocation step and run measurably faster on bulk workloads. For typical interactive use, the standard parser is fast enough that the distinction is invisible, and the convenience of getting the parsed value for free outweighs any allocation cost.

RFC 8259 Section 3: Values MDN: JSON.parse() return value and exceptions

How to use this tool

💡

Paste the string you want to check. FixTools confirms whether it is valid JSON and explains any issues, useful before writing JSON.parse in your code.

How It Works

Step-by-step guide to validate a json string:

1
Copy the string value
Capture the exact string you want to check from wherever it lives: a variable inspector, a log line, an HTTP response body, a database row, or a localStorage entry. Copy the raw bytes rather than a rendered view so invisible characters and whitespace are preserved exactly as your code receives them.
2
Paste into FixTools
Paste the captured value into the FixTools JSON validator input. If you copied from a log that quoted the value, strip the surrounding quotes so the validator sees the same characters your runtime would see. Confirm the visible length matches the length you logged in code to rule out clipboard truncation.
3
Check the result
A green confirmation means the string conforms to RFC 8259 and JSON.parse will return cleanly. A red result includes the line and column of the failure and a description of what the parser expected at that point. Use the description to identify whether the cause is a syntax error, a wrong content type, or invisible characters.
4
Use in code
Once the sample validates, write the JSON.parse call with confidence. Keep a try-catch wrapper around it for production safety, because the next record may have a different shape than the sample you tested. The validator confirms the format for one specific input, not the entire universe of inputs your code will eventually see.

Real-world examples

Common situations where this approach makes a real difference:

Full-stack developer

A developer stores user preferences as a JSON string in a SQL text column. On read, the loader calls JSON.parse directly and crashes intermittently in production. Investigation reveals that early rows were inserted with plain text descriptions before the team standardised on JSON. They paste failing rows into FixTools to confirm the shape, then add a validation step before parsing that falls back to a default preferences object when the column does not validate. The crash rate drops to zero and the legacy rows are migrated on read.

Data analyst

An analyst receives a CSV export where one column is supposed to contain JSON metadata. Inspection shows the column is inconsistent: some rows have complete JSON objects, some have truncated structures, and some have plain English descriptions. The analyst pastes representative samples from each shape into FixTools to understand the failure modes before writing a cleanup script. The validator confirms which rows are fixable JSON, which are truncated, and which were never JSON to begin with, which determines the right path for each group.

Backend developer

A backend developer writes a webhook handler that receives several event types. Some bodies are JSON, others are URL-encoded form data, and a few are XML for a legacy partner. They paste samples of each body into FixTools while writing the handler, which clarifies which content types are valid JSON and which need a different parser. The handler ends up branching on Content-Type with explicit parser selection rather than calling JSON.parse blindly and catching errors.

Mobile developer

A mobile developer reads a value from Android SharedPreferences during a version upgrade. The value might be a JSON-serialised object from the new format or a plain string from the previous version. They paste samples from both shapes into FixTools, confirm which one validates and which one does not, and design a migration that detects the format on read and rewrites the storage in the new shape. The decision tree is informed by ground truth rather than guessed.

Pro tips

Get better results with these expert suggestions:

Check the type before validating

Before calling JSON.parse, confirm that the value is actually a string with typeof value === "string". JSON.parse on undefined throws the cryptic Unexpected token u in JSON at position 0 because parse coerces the argument to the literal text undefined first. A type guard up front produces a clearer error and prevents you from accidentally parsing null, numbers, or objects that happened to slip through your type system.

Distinguish empty string from empty JSON

The empty string is not valid JSON. The smallest valid JSON object is the two-character text consisting of an open and a close brace, and the smallest valid array is similarly two characters. If you want a default value that represents emptiness, choose null or one of the empty container literals rather than the empty string. Storing the empty string as a default leaves you with a value that fails parse and forces every reader to special-case it.

Validate a sample before writing a parser

Before writing parsing code for a new data source, paste several representative strings into FixTools. This confirms the format, exposes any edge cases such as null values, missing fields, or inconsistent types, and lets you design parsing logic that handles the real shapes rather than the shapes you assumed. Discovering format quirks in a validator is much cheaper than discovering them in production after a deploy.

Log string length and first and last characters

When debugging a JSON string that fails validation, log the length of the string and the first and last fifty characters separately. This pinpoints truncation, which shows up as a string that is shorter than expected and ends mid-value, and wrong content type, which shows up as a string that starts with an HTML tag. You get diagnostic value without paying the cost of logging an entire potentially huge payload.

FAQ

Frequently asked questions

The standard pattern in JavaScript is the helper function isValidJSON(str) { try { JSON.parse(str); return true; } catch { return false; } }. It returns true if parse succeeds and false if it throws a SyntaxError. For debugging, paste the failing string into FixTools, which reports the line and column where parsing failed and gives a description in plain language. Other languages have equivalent helpers: Python's json.loads, Go's json.Valid, and Java's ObjectMapper.readTree all provide the same yes-or-no answer with different error formats.

No. The empty string is not valid JSON. JSON.parse called on an empty string throws SyntaxError: Unexpected end of JSON input because the parser reaches the end of the buffer before finding any value. The minimum valid JSON values are an empty object containing only the braces, an empty array containing only the brackets, an empty string literal containing the two enclosing double quotes, the number zero, the booleans, and null. An empty variable contains no JSON at all and needs to be handled as a separate case.

A JSON string is a data format, specifically a text representation of structured data per RFC 8259. A JavaScript string containing JSON is a variable in your program whose contents happen to follow that format. The variable type is the JavaScript string primitive. JSON.parse interprets the contents as the JSON format and returns the corresponding JavaScript value. The distinction matters because not every JavaScript string is JSON. Most strings in a typical program are usernames, paths, or labels that have no relationship to the JSON grammar.

Yes. The text 42 with no quotes is valid JSON. JSON.parse called with that text returns the JavaScript number 42. The same applies to JSON.parse called with true, false, or null, which return the corresponding JavaScript values. These top-level scalar values became explicitly valid in RFC 8259. The earlier RFC 4627 restricted the top-level value to objects and arrays only, so very old parsers may still reject scalars. Modern parsers in every mainstream language accept them.

JSON.parse coerces its argument to a string first using the abstract ToString operation. JSON.parse(null) is equivalent to JSON.parse("null") and returns null. JSON.parse(true) is equivalent to JSON.parse("true") and returns true. JSON.parse(undefined) coerces to the literal text undefined, which is not valid JSON and throws SyntaxError. JSON.parse on an object calls toString on the object, which usually produces the unhelpful text object Object and also throws. In TypeScript, the function signature requires a string, which prevents these accidents at compile time.

For bulk validation, use a command-line approach. Python: python3 -c "import json,sys; [json.loads(line) for line in sys.stdin]" reads a file of one JSON document per line and exits on the first failure. The jq tool runs jq . over a file and validates as a side effect of parsing. For a database column, a query that casts the column to the database's native JSON type and selects rows where the cast fails will surface invalid rows. For Node.js, a short script that streams a file by line and parses each line in try-catch works well for log-shaped JSON.

Yes, especially when the column is a generic text or VARCHAR type rather than a native JSON type. Databases with native JSON, such as PostgreSQL jsonb and MySQL JSON, enforce validity on insert and reject malformed values at write time. Text columns accept any bytes, so invalid JSON can accumulate over years of inserts. A one-time validation pass identifies bad rows so they can be repaired or quarantined. Adding application-level validation on insert prevents new invalid values from joining the existing pile.

The message means the parser reached the end of the input buffer before the structure it was building was complete. A string that opens a brace or bracket without a corresponding close produces this error at the position of the missing close. A string that opens a string value with a double quote but never closes it also produces this error at the end of the buffer. Check the final characters of the failing string. If they look correct, work backwards to find the structure that was opened and never closed.

Once syntax validation passes, hand the parsed value to a JSON Schema validator like AJV in JavaScript, jsonschema in Python, or json-schema-validator in Java. The schema document declares which fields are required, what types they hold, what value ranges are acceptable, and what patterns strings must match. The validator walks the parsed structure against the schema and returns a list of violations using JSON Pointer paths to identify the exact field that failed. For a smooth migration between schema drafts, declare the $schema URL at the top of the schema file so the validator knows which draft to apply. The two-step workflow of syntax then schema produces clearer error messages than combining the checks, because a schema validator handed invalid JSON throws a generic parse error rather than the precise schema violation you actually want to see.