Free · Fast · Privacy-first

Check JSON for Errors

Q: How do I find errors in JSON?

Paste your JSON into a validator like FixTools and let it do the work. The validator attempts to parse the JSON through a strict RFC 8259 parser and reports back the exact line and character where parsing failed, the token it actually found at that position, and the token the grammar expected to find there. For large files, the line and column numbers are critical: navigate directly to that location in your editor rather than scanning the entire file by eye, which is slow and unreliable for character-level mistakes that hide in plain sight.

Q: What should I do if my JSON has many errors?

JSON parsers always stop at the first fatal error they encounter. Fix that first reported error in your input and run the validator again. Sometimes one fix immediately reveals additional errors that were previously hidden by the first failure, since the parser could not reach them. Work through the errors one at a time in the order they are reported, revalidating after each individual fix. If the JSON is severely malformed (for example, it was truncated mid-stream or corrupted in transit) it may be faster to rebuild it from the original source rather than patching it character by character.

Q: Can I check JSON errors in large files?

Yes. FixTools processes JSON entirely inside your browser without any file size limit imposed by the service itself. Large files may take a noticeable moment to parse depending on your machine. If your file is several hundred megabytes the browser tab may slow during parsing because the entire string sits in JavaScript memory. For very large JSON files measuring hundreds of megabytes or more, a command-line tool like jq or Python's built-in json.tool module is more practical: python3 -m json.tool largefile.json > /dev/null reports any errors and exits cleanly.

Q: Can JSON have nested errors at multiple levels?

A JSON parser reports only the first error it encounters during a single pass, then stops. Fixing that error and revalidating may reveal additional errors at deeper nested levels of the document that the parser could not reach the first time. A single high-level mistake (such as a missing comma deep inside a nested object) can also cause all subsequent content to be parsed in the wrong context, potentially generating a cascade of confusing error messages downstream. Always fix errors strictly in the order they are reported rather than trying to guess at the structural cause.

Q: Is there a way to check JSON errors from the command line?

Yes, and it is the right move for files that are too large for browser memory. Python's built-in json module provides a quick check: python3 -m json.tool yourfile.json. If the file is valid, it prints the formatted JSON to standard output. If it is invalid, it prints an error message naming the line and column number. The jq command-line tool (jq . yourfile.json) also validates and pretty-prints in one shot. Both options work cleanly inside shell scripts and CI pipelines for automated checks that fail the build on invalid input.

Q: What character is most likely at the error position?

The most common characters at JSON error positions are: a comma sitting before a closing bracket (the classic trailing comma case), a single quote where a double quote was expected (often pasted from Python or Ruby code), a letter that starts an unquoted word like undefined or NaN or a property name that should have been quoted, a < character at position 0 indicating the body is HTML rather than JSON, a closing bracket or brace appearing when a value was still expected, or a backslash followed by an invalid escape character inside a string. Identify the character and the cause usually becomes clear.

Q: Can I check for errors across many JSON files at once?

Yes, and it is the right approach when a repository contains dozens or hundreds of JSON files. The simplest command for a Unix-like environment is find . -name "*.json" -print0 | xargs -0 -n1 jq . > /dev/null, which runs jq across every JSON file in the tree and exits with a non-zero status if any one fails. For a Python-only environment, replace jq with python3 -m json.tool. For Node.js setups, the jsonlint package on npm offers a similar batch mode. Wire any of these into a pre-commit hook or a CI job and broken JSON cannot enter the main branch. For ad-hoc one-shot checks during a refactor or migration, paste each file into FixTools individually to get clearer line-and-column reporting than the raw command-line output provides.

Something is wrong with your JSON and you cannot see it on inspection? FixTools surfaces the issue immediately, whether the cause is a trailing comma at the end of an array, a mismatched bracket somewhere in a deeply nested object, an unquoted key copied in from another language, or a stray character hiding inside what looks like a perfectly normal string value.

⚡

Pinpoints exact error location

🔒

Plain-language error descriptions

✨

Catches all JSON syntax errors

⚡

Unlimited checks, free forever

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.

Anatomy of a JSON Error Message: What "Unexpected Token at Position N" Actually Tells You

When a JSON parser reports an error like "SyntaxError: Unexpected token ',' at position 47", that compact message actually packs three useful pieces of information into one line. First, the token type: in this case a comma character. Second, the position: character offset 47 from the start of the input string, counting from zero. Third, the implication: a comma at that exact byte was not expected by the JSON grammar at that point in parsing. To map a raw position number into a human-friendly line and column number, you can count characters from the beginning of the file by hand, or paste the string into a tool that performs that conversion automatically. Position-based errors are accurate but require a translation step before they become quickly readable for humans.

Different JavaScript engines format error messages differently for the same invalid JSON input, which is one of the reasons debugging JSON across browsers can feel inconsistent. V8, used by both Chrome and Node.js, reports something like "SyntaxError: Unexpected token ',', ...snippet... is not valid JSON". SpiderMonkey in Firefox reports "SyntaxError: JSON.parse: expected property name or '}' at line 5 column 3 of the JSON data", which is more verbose but also more directly useful. JavaScriptCore in Safari reports the much shorter "SyntaxError: JSON Parse error: Expected '}'". All three engines have encountered the same underlying error but describe it through different lenses. A dedicated JSON checker like FixTools normalises these outputs into a consistent format that includes both the position and a clear description.

The most actionable single piece of information in any JSON error message is the position number. Go straight to that exact character in the input and look at what is there. What you find at that spot is almost always the problem directly: a comma where a closing bracket should be (trailing comma scenario), a single quote where a double quote should be, a letter at a point where a digit should be (unquoted key or undefined-style value), or a < character at position 0 (HTML response masquerading as JSON). The character at the error position is your primary clue. If the character at the position itself looks fine, look one character before it: the parser sometimes reports the location where it gave up rather than where the upstream mistake actually was.

Once you have caught and fixed the immediate error, the next move is to wire an automated error check into your CI pipeline so the same class of failure cannot reach the main branch again. A check JSON for errors step typically runs jq . over every changed JSON file in a pull request and fails the build on any non-zero exit code. For repositories with many JSON files, the find command piped into xargs runs the same check across the entire tree in one shell command. The Python equivalent, python3 -m json.tool, is interchangeable for the same purpose and is preinstalled on most Linux runners. Teams with pre-commit infrastructure add the check-json hook from the standard pre-commit library, which catches the failure on the developer's machine before the commit even lands locally. Each layer adds a little more friction to broken JSON reaching production, and the cumulative effect is that the validator stops being a debugging tool and becomes part of normal day-to-day workflow.

ECMA-262: JSON.parse specification RFC 8259: JSON syntax rules V8 blog: JSON parsing in Chrome

How to use this tool

💡

Paste the JSON you suspect has an error and click Validate to find it.

How It Works

Step-by-step guide to check json for errors:

1
Paste the JSON
Copy the JSON you want to check from wherever it currently lives, whether a file on disk, a captured API response in your browser network tab, a config snippet in your editor, or a log line from a failing service, and paste the full text into the FixTools validator input. Pasting the raw string rather than a formatted preview is important since the formatter may hide the actual characters.
2
Check for errors
Click Validate and FixTools scans the entire JSON through the browser native parser in a single pass, reporting every syntax error with the line number, column number, the offending token, and what the grammar expected at that point instead. Because the check runs locally, the result comes back essentially instantly even for large payloads measuring several megabytes in size.
3
Fix and re-check
Correct each reported error at the exact position the validator identifies. Re-run the validation after each fix rather than batching edits, since JSON parsers stop at the first fatal error and clearing one mistake often reveals the next one hiding behind it. Continue until the validator confirms the JSON is fully error-free and parseable end to end.

Real-world examples

Common situations where this approach makes a real difference:

Node.js developer

A developer's Node.js service parses an inbound webhook payload and crashes with "SyntaxError: Unexpected token < in JSON at position 0". They add a console.log of the raw body string before the parse call and discover the webhook endpoint is actually returning a 401 HTML login page whenever the API key header is missing or wrong. The JSON itself is not malformed because the JSON was never sent in the first place. Checking the raw string before assuming the JSON is broken saves significant time, and they add a status code guard before parsing.

Database administrator

A DBA is importing a JSON file into MongoDB using mongoimport and the operation fails with a parse error pointing at line 203. They paste the entire file into FixTools, which immediately reports "Unexpected token at line 203 column 8: found single-quote, expected double-quote". One record buried in the middle of an otherwise clean export has a string value written with single quotes, almost certainly copied in from a Python script during a manual data fix months ago. Replacing that one quote pair allows the full import to complete without further intervention.

Support engineer

A support engineer is reviewing logs from a customer environment where a configuration file is causing application startup to fail. The error message in the log is the unhelpful "Failed to parse config: position 1402" with no line context. The config file is 80 lines long. Pasting it into FixTools converts that byte offset into line 34 column 19 and reports "Unexpected token at line 34 column 19: found //, comments are not allowed in JSON". A developer had added a comment to document a setting without realising JSON does not support comments at all.

Student learning web development

A student is writing their first REST API project and hand-crafts a JSON test payload directly in a text file. Their fetch call returns a 400 error every time. They paste the JSON into FixTools and see "Unexpected end of input at line 12 column 1". The file contains 11 lines describing an object but the closing brace on line 12 is missing entirely. The formatter view shows the unclosed structure immediately on inspection, and the student picks up the habit of always closing every opened bracket before moving on to the next field.

Pro tips

Get better results with these expert suggestions:

Log the raw string before parsing

When JSON.parse fails inside your application code, the single most useful debugging move is to log the raw input string immediately before the parse call. Drop a console.log(JSON.stringify(str)) line right before the parse and capture the output. This shows you the exact bytes being handed to the parser, including any invisible characters, encoding issues, BOM marks, or unexpected prefixes like an HTML doctype that explain why the parser is failing in the first place.

Position 0 errors almost always mean wrong content type

A JSON parse error reported at position 0 almost always means the response body is not JSON at all. The character sitting at position 0 in those cases is typically < for an HTML document, ( as part of a JSONP wrapper, or whitespace from an empty response that the parser cannot consume. Check the actual HTTP status code and the Content-Type header of the response carefully. A 404 or 500 response often returns HTML even when the client originally requested JSON via an Accept header.

Use character counting for small JSON blocks

For short JSON strings under about 100 characters in total length, you can usually locate a position-based error by counting characters by hand: position 0 is the first character, position 1 is the second, and so on. For longer strings the manual count quickly becomes impractical, so paste the JSON into FixTools and let the tool convert the byte offset into a human-readable line and column you can navigate to directly in your editor or viewer without counting at all.

Check encoding when copying from PDFs or emails

Copying JSON snippets out of PDF files or HTML email messages can silently introduce typographic curly quotes (Unicode U+201C and U+201D) instead of the straight double quotes (U+0022) that JSON actually requires. The two look essentially identical on screen at normal font sizes but the curly versions break JSON parsing immediately. If your JSON appears correct on inspection yet keeps failing, paste it into a tool that reveals the actual code points around the quote characters and look for the wrong ones.

FAQ

Frequently asked questions

Paste your JSON into a validator like FixTools and let it do the work. The validator attempts to parse the JSON through a strict RFC 8259 parser and reports back the exact line and character where parsing failed, the token it actually found at that position, and the token the grammar expected to find there. For large files, the line and column numbers are critical: navigate directly to that location in your editor rather than scanning the entire file by eye, which is slow and unreliable for character-level mistakes that hide in plain sight.

JSON parsers always stop at the first fatal error they encounter. Fix that first reported error in your input and run the validator again. Sometimes one fix immediately reveals additional errors that were previously hidden by the first failure, since the parser could not reach them. Work through the errors one at a time in the order they are reported, revalidating after each individual fix. If the JSON is severely malformed (for example, it was truncated mid-stream or corrupted in transit) it may be faster to rebuild it from the original source rather than patching it character by character.

Yes. FixTools processes JSON entirely inside your browser without any file size limit imposed by the service itself. Large files may take a noticeable moment to parse depending on your machine. If your file is several hundred megabytes the browser tab may slow during parsing because the entire string sits in JavaScript memory. For very large JSON files measuring hundreds of megabytes or more, a command-line tool like jq or Python's built-in json.tool module is more practical: python3 -m json.tool largefile.json > /dev/null reports any errors and exits cleanly.

"Unexpected end of input" means the JSON parser reached the very end of the input string before the data structure was complete. The string terminated before all opened brackets and braces were closed, or a string value was opened with a double quote but never received its matching closing quote. To diagnose it, look at the last few lines of your JSON for a missing closing } or ] character, or for a string value that began somewhere but was never properly terminated. The error position usually points to the final byte rather than the upstream cause.

An error reported at position 0 means the very first character of the input string is not a valid JSON character. This almost always indicates that the content is not JSON at all: the server returned an HTML page (which starts with < for the doctype or root tag), a plain text error message, a JSONP wrapper of the form callback({...}), or a UTF-8 BOM byte order mark character was prepended to the file by the editor that saved it. Inspect the actual first bytes of the content, not just what it looks like on screen at a glance.

A JSON parser reports only the first error it encounters during a single pass, then stops. Fixing that error and revalidating may reveal additional errors at deeper nested levels of the document that the parser could not reach the first time. A single high-level mistake (such as a missing comma deep inside a nested object) can also cause all subsequent content to be parsed in the wrong context, potentially generating a cascade of confusing error messages downstream. Always fix errors strictly in the order they are reported rather than trying to guess at the structural cause.

Yes, and it is the right move for files that are too large for browser memory. Python's built-in json module provides a quick check: python3 -m json.tool yourfile.json. If the file is valid, it prints the formatted JSON to standard output. If it is invalid, it prints an error message naming the line and column number. The jq command-line tool (jq . yourfile.json) also validates and pretty-prints in one shot. Both options work cleanly inside shell scripts and CI pipelines for automated checks that fail the build on invalid input.

The most common characters at JSON error positions are: a comma sitting before a closing bracket (the classic trailing comma case), a single quote where a double quote was expected (often pasted from Python or Ruby code), a letter that starts an unquoted word like undefined or NaN or a property name that should have been quoted, a < character at position 0 indicating the body is HTML rather than JSON, a closing bracket or brace appearing when a value was still expected, or a backslash followed by an invalid escape character inside a string. Identify the character and the cause usually becomes clear.

Yes, and it is the right approach when a repository contains dozens or hundreds of JSON files. The simplest command for a Unix-like environment is find . -name "*.json" -print0 | xargs -0 -n1 jq . > /dev/null, which runs jq across every JSON file in the tree and exits with a non-zero status if any one fails. For a Python-only environment, replace jq with python3 -m json.tool. For Node.js setups, the jsonlint package on npm offers a similar batch mode. Wire any of these into a pre-commit hook or a CI job and broken JSON cannot enter the main branch. For ad-hoc one-shot checks during a refactor or migration, paste each file into FixTools individually to get clearer line-and-column reporting than the raw command-line output provides.