JSON Parse Error Fixer: Find and Fix Invalid JSON

How to use the JSON Parse Error Fixer: Find and Fix Invalid JSON

1. Paste the textPaste the JSON, the raw API response, or the exact error message into the box. If all you have is an error message, paste that.
2. Read the verdictThe banner says whether the text is valid, was repaired, is not JSON at all, or cannot be repaired automatically.
3. Review each problemOpen a problem to see its line and column, why it breaks JSON, and what changed. Problems marked “Check this” guess at meaning, so read them before you trust the result.
4. Compare with your browserThe “What your browser says” card shows the strict parser's own message with an explanation, and tells you when it pointed somewhere other than the real mistake.
5. Copy the resultChoose an indentation, then copy or download the repaired JSON, or use it as new input to keep working.

What a JSON parse error really tells you

A JSON parser reads text from left to right and stops at the first character that breaks the rules. The message names that character and often a position. The position is where the parser gave up, which is not always where the mistake is. A missing comma between two properties is only noticed when the parser reaches the next property name, which is usually on the following line. A missing closing quote is noticed even later, because the parser keeps reading the rest of the document as part of the string until it meets a line break or the end of the text.

That is why this tool shows two places when they differ: where your browser's parser stopped and where the first real problem sits. Looking at the earlier of the two, and at the line above it, finds most mistakes quickly.

• Missing comma: reported at the start of the next item, often one line below the real gap.
• Missing closing quote: reported at the end of the line or the end of the file.
• Trailing comma: reported at the closing bracket, one step after the comma itself.
• Missing or extra bracket: often reported at the very end, far from the cause.

When the text is not JSON at all

Many parse errors have nothing to do with syntax. The most common is “Unexpected token < in JSON at position 0”. The < is the start of an HTML tag, so the thing being parsed is a web page. Servers return HTML error pages, login screens, and proxy messages in place of data, and code that expects JSON then fails on the first character.

For each of the cases below the real fix is usually in the code that produced the text, not in the text itself. The tool says so, because repairing the symptom only hides the cause.

• An HTML page (404, 500, login, or a bot check): the tool shows the page title and heading and says what the page most likely means.
• The word undefined or the text [object Object]: a value was passed to the parser without being turned into JSON first.
• A markdown code fence: chat assistants wrap JSON in ``` lines. The fence is removed.
• Text around the JSON: an introductory sentence or a log prefix is removed and listed so you can check it.
• A JSONP wrapper: callback({...}); is unwrapped.
• Double-encoded JSON: text with a backslash before every quote is unescaped.
• Several documents: JSON Lines, or two responses pasted together, are combined into one array.

Reading error messages from different languages

Each language words the same problem differently. The same missing comma reads “Expected ',' or '}' after property value in JSON at position 13” in Chrome, “JSON.parse: expected ',' or '}' after property value in object at line 3 column 3” in Firefox, and “Expecting ',' delimiter: line 3 column 3 (char 13)” in Python. Chrome and Node.js have also rewritten their messages in recent versions, so many guides still describe an older wording such as “Unexpected token } in JSON at position 5”.

Paste any of these messages and the tool names the runtime, explains the meaning in plain English, and lists the most common causes and what to check. It recognises Chrome, Edge, and Node.js; Firefox; Safari; Python; Java with Jackson and Gson; Go; .NET with Newtonsoft.Json and System.Text.Json; PHP; Ruby; Rust with serde_json; and Swift.

• Chrome, Edge, Node.js: “Unexpected end of JSON input” means the text is empty or was cut off.
• Firefox: “JSON.parse: unexpected character at line 1 column 1” usually means HTML or plain text at the very start.
• Safari: “JSON Parse error: Unrecognized token '<'” is HTML again.
• Python: “Expecting value: line 1 column 1 (char 0)” means empty text or text that is not JSON.
• Go: “invalid character '<' looking for beginning of value” is HTML once more.

Why repaired JSON can still be wrong

A parser can tell whether text is valid. It cannot tell whether it is right. Every automatic repair is a guess, and some guesses change meaning. This tool marks those repairs with “Check this” so you can read them first.

Two further problems are invisible to a normal parser. Duplicate property names are legal syntax, but many parsers keep only the last value and silently discard the rest. And numbers larger than 9,007,199,254,740,991 are rounded by JavaScript without any error, so a 64-bit ID can change when it is parsed and printed again. This tool keeps the digits exactly as written and warns you about both.

• NaN, Infinity, and undefined have no JSON form, so they become null. JavaScript's own JSON.stringify does the same, but null may mean something different to your application.
• A number with leading zeros, such as the ZIP code 01234, becomes a string so that no digit is lost.
• A missing value becomes null, which keeps the structure valid but hides a gap.
• Cut-off data is closed with brackets. That makes it valid but cannot bring back what was lost.
• Text removed before or after the JSON is listed so you can check that nothing important went with it.

Your data stays on your device

The checking and repair run in your browser, and the code behind this tool makes no network requests. Nothing you paste is sent to a server, saved, or logged by this page. You can confirm it yourself: open the Network panel in your browser's developer tools, paste some JSON, and watch for a request that carries your text. You will not see one.

That matters for JSON in particular, because people paste API responses that can contain access tokens, email addresses, or customer records.

Limits and accuracy

• It repairs syntax and the common patterns described above. It cannot know what a missing value should have been, so those repairs are guesses and are marked.
• Error messages are matched against the known wording of the languages listed. A message from another library, or from a much newer version, may not be recognised.
• It does not check JSON against a schema, so valid JSON can still be wrong for your application.
• Text over about 1.5 million characters is not checked in the page.
• Line and column numbers count UTF-16 characters, as JavaScript does. Other languages may count bytes or code points, so they can report different columns for text that contains emoji or accented letters.

Frequently asked questions