Free · Fast · Privacy-first

Fix Invalid JSON

Invalid JSON arrives from many directions: a hand-edited config file with a trailing comma after the last property, an API response that quietly wrapped real JSON inside an HTML error page during an outage, a template engine that forgot to suppress a comma when iterating over the final item in a loop, or a serialiser that wrote single-quoted strings because the source data lived in a Python dict.

⚡

Trailing comma after last element, remove the final comma before ] or }

🔒

Single quotes instead of double quotes, replace ' with " around strings and keys

✨

Unquoted keys, add double quotes around all property names

⚡

Comments in JSON, JSON does not allow comments; remove any // or /* */ lines

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.

The Five Most Common JSON Fixes: Trailing Commas, NaN, Control Characters, and More

Trailing commas account for roughly half of all JSON syntax errors in practice, by a wide margin over every other category. They appear when developers copy object literals out of JavaScript or TypeScript source code, where trailing commas have been legal since ES5 and are actively encouraged by tools like Prettier and most modern style guides as a clean diff aid. JSON templates that emit a comma after every iteration without suppressing the final one are another common source. The fix is always the same regardless of cause: find the comma sitting immediately before a closing } or ] and delete it. In a large nested file there may be multiple trailing commas at different nesting levels, so fix each one and revalidate to surface the next.

NaN, undefined, and Infinity are JavaScript-specific values that have no equivalent representation in the JSON specification at all. RFC 8259 defines only four primitive types: strings, numbers (which must be finite IEEE 754 values), booleans, and null. A JavaScript serialiser that calls JSON.stringify on an object containing NaN or undefined will either silently drop the offending key or write null in its place, depending on context. A more permissive serialiser that writes NaN literally into the output produces invalid JSON that strict parsers reject. The fix is to replace NaN and Infinity with null, ensure undefined properties are either removed or replaced with a valid value before serialisation, and configure your serialiser to fail loudly rather than emit invalid tokens.

Control characters, meaning ASCII codes 0x00 through 0x1F, must be escaped when they appear inside JSON string values. An unescaped raw newline (0x0A), tab (0x09), or carriage return (0x0D) embedded directly inside a string value is invalid even though the file may look fine in many editors. This error is particularly common with JSON generated by systems that include raw newlines in multi-line text fields like blog post content or log messages. The fix is to replace each raw control character with its JSON escape sequence: \n for newline, \t for tab, \r for carriage return. Other control characters use the \uXXXX four-digit Unicode hex format, for example \u0000 to represent the null byte explicitly.

Fixing invalid JSON one document at a time gets old quickly when the same generator keeps producing the same defects. The durable solution is to add a validation gate in the CI pipeline that runs jq . or python3 -m json.tool over every JSON artifact the build produces, failing the pipeline on the first non-zero exit status. Combined with a pre-commit hook on the developer side, this two-layer defence catches both hand-edited mistakes and generator regressions before either can reach production. For services that emit JSON over the wire at runtime, add a contract test that snapshots a representative response and validates it on every test run, so any future change to the serialiser that breaks JSON validity fails the test suite immediately rather than surfacing as a customer-facing parse error later. Treat invalid JSON as a build-blocking defect, not a runtime curiosity, and the recurrence rate drops sharply.

RFC 8259 Section 6: Numbers RFC 8259 Section 7: Strings and escape sequences MDN: JSON.stringify() behaviour with undefined and NaN

How to use this tool

💡

Paste your invalid JSON and click Validate to get the exact error location and what needs to be fixed.

How It Works

Step-by-step guide to fix invalid json:

1
Paste the invalid JSON
Copy the JSON string that is failing somewhere in your stack and paste the entire text into the FixTools validator input. Use the raw bytes rather than a pretty-printed preview from another tool, since the formatter may quietly normalise the content and hide the actual problem your downstream parser is hitting. Include any leading or trailing characters too.
2
Read the error message
FixTools reports the precise line and column where parsing stopped along with the category of error involved. Common messages include "Unexpected token" naming the specific character found, "Expected comma" when two values appear without a separator, and "Unexpected end of input" when a closing bracket is missing. Read both the position and the description to understand what the parser actually saw.
3
Fix the error
Correct the issue at the exact reported location. Common edits are: add a missing comma between sibling values, remove a trailing comma sitting before a closing bracket, replace single quotes around a string with double quotes, add double quotes around an unquoted property name, or close an unbalanced bracket. Each fix is usually a one or two character change once you can see the exact spot.
4
Revalidate
Click Validate again immediately after each individual fix. JSON parsers stop at the first fatal error encountered, so clearing one mistake often reveals additional errors that were hiding behind it deeper in the document. Repeat the cycle of fix and revalidate until the JSON shows as fully valid with no remaining errors anywhere in the input string.

Real-world examples

Common situations where this approach makes a real difference:

JavaScript developer

A developer is building a configuration-driven UI where the settings are stored as JSON inside a database column. One config record was inserted at some point in the past by a script that used JSON5 syntax with trailing commas and inline comments. When the UI loads that specific config row, JSON.parse throws and the entire screen crashes. The developer pastes the record value into FixTools, sees three trailing commas and two inline comments flagged with line and column numbers, edits all five in the input panel, revalidates to confirm a clean parse, and updates the database row with the fixed payload.

Python data engineer

A data engineer serialises Python objects to JSON files using the standard library json.dumps function as part of an overnight pipeline. One specific object contains a float value of float("nan") that crept in from a numeric calculation upstream. Python's json module writes NaN directly into the output by default, since the behaviour is configurable, and the resulting file then fails every downstream strict JSON parser. The engineer adds allow_nan=False to the json.dumps call so the serialiser raises a ValueError instead of writing invalid JSON, forcing the NaN to be handled at the source where the calculation produced it.

iOS developer

An iOS developer receives JSON from an internal server that includes a multi-line text field with raw newline characters embedded directly inside a string value. NSJSONSerialization throws a parse error every time. Pasting the problematic payload into FixTools shows the explicit message "Invalid character in string: found unescaped newline at line 6 column 42". The server is inserting raw newline bytes into JSON string content without escaping them first. The correct fix is server-side: escape newlines to \n before inserting any user-provided multi-line text into the JSON structure during serialisation.

Content editor

A content editor updates a JSON-based CMS configuration file using a plain text editor on Windows and saves the change. The CMS rejects the config on the next startup with a vague parse error and refuses to load the new settings. Checking the file in FixTools confirms the JSON itself is syntactically valid against RFC 8259. The real issue turns out to be CRLF line endings the Windows editor wrote, while the CMS parser expects Unix LF endings only. This case illustrates how encoding and line-ending issues can masquerade as JSON errors, and why testing the actual artifact in the actual consumer matters.

Pro tips

Get better results with these expert suggestions:

Fix the source, not just the symptom

When you locate a JSON error in an API response or a generated artifact, trace the problem back to where the JSON is actually produced rather than patching the broken output by hand. A template that generates trailing commas will keep generating them on every run. A serialiser misconfigured to emit NaN will do the same on the next invocation. Fixing the generator at the source prevents the error from recurring on the next deploy or the next request, which is significantly cheaper than chasing it repeatedly.

Use a regex to bulk-remove trailing commas

For large files containing many trailing commas across multiple nested levels, a regex substitution is far faster than fixing each occurrence by hand. The pattern ,\s*([}\]]) matches a comma followed by optional whitespace and a closing bracket or brace, and you replace the entire match with just the captured bracket. Always test the replacement on a copy of the file first to catch any false positives, especially around commas embedded inside string content, and revalidate after to confirm the change cleared the errors.

Check for BOM characters at the file start

Files saved with a UTF-8 byte order mark (U+FEFF) have an invisible character at byte position 0 that breaks strict JSON parsers even though the file otherwise looks completely correct in your editor. This is valid UTF-8 in some contexts but invalid in the JSON specification, which permits no leading bytes before the first JSON value. The BOM looks like a blank line at the very start of your file. Most modern editors offer a save option for UTF-8 without BOM that resolves the issue cleanly.

Distinguish truncated from malformed JSON

If your JSON ends with "Unexpected end of input", the underlying content may be truncated rather than syntactically malformed. Network timeouts, buffer overflows on the producer side, file write interruptions, and storage quotas all produce incomplete JSON that looks broken in the same way as a missing bracket. Before debugging the syntax line by line, confirm the file or response is actually complete by checking its byte length against the expected size or the Content-Length header reported by the server.

FAQ

Frequently asked questions

Trailing commas are far and away the most common JSON syntax error in real codebases. JSON does not allow a comma after the last element in an array or after the last property in an object, even though most modern programming languages do. An example of the error: {"name": "Alice",} contains a trailing comma after the value "Alice" that makes the entire object invalid. This mistake is so frequent because JavaScript object literals allow trailing commas freely, style guides encourage them for cleaner diffs, and muscle memory keeps producing them in JSON contexts where the parser rejects the same syntax that the editor accepted seconds earlier.

JSON is a strict data interchange format specified by RFC 8259 and was designed from the start to be minimal, unambiguous, and parseable by any programming language with a small amount of code. JavaScript is a full programming language that added trailing comma support specifically for developer convenience and cleaner version control diffs. JSON's grammar was intentionally kept simpler than JavaScript's, and trailing commas were deliberately excluded because a comma in the grammar implies another element follows. If no element follows, the structure is ambiguous, and the spec authors chose to prohibit ambiguity in a format that aims for universal interoperability.

FixTools identifies and explains every error with precise line and column information and a description of what the parser found versus what it expected. For common issues like trailing commas, single quotes, or missing brackets, the actual edit is a small manual change you make in the input panel and then revalidate. There is no aggressive auto-fix mode because automatic correction requires making assumptions about your intent. For example, deciding whether a missing comma should be added before or after a specific value, or whether a dangling comma indicates a forgotten value, is better decided by the developer who knows the original data shape.

"Unexpected end of input" means the JSON parser reached the end of the input string while it was still in the middle of parsing a structure. The most common cause is a missing closing bracket } or ] somewhere earlier in the file, leaving the parser inside an object or array context when the input ran out. It can also indicate an unterminated string, where an opening double quote was placed but the matching closing double quote was never found before the end of the file. Check the final lines of your JSON for missing closing characters or an unclosed quoted string.

Neither NaN nor undefined nor Infinity are valid JSON values, so they need to be replaced before serialisation reaches a parser. Replace NaN with null when the absence of a numeric value is acceptable in your domain, or with a sentinel like 0 or a default if not. Replace undefined with null since undefined has no JSON representation at all. Replace Infinity with either the maximum representable number for your domain or with null depending on what makes semantic sense. In JavaScript, you can use a JSON.stringify replacer function to catch and convert these values during serialisation in one place.

Fixing JSON means correcting the raw syntax so the string can be parsed at all by an RFC 8259 parser: removing trailing commas, adding missing quotes around keys, balancing brackets, escaping control characters. Fixing JSON Schema errors means changing the data values inside parseable JSON so they match the constraints declared by a schema document: providing required fields that are missing, correcting field types from string to integer, bringing numeric values within declared ranges. The two are independent: you can have syntactically perfect JSON that fails schema validation, and you can have a schema-shaped object that fails parsing.

If JSON was cut off in the middle of a string value or somewhere deep inside a nested structure, the appropriate fix depends on exactly where the cut happened. If the truncation point is at the very end and you only need to recover the structure, you can manually add the missing closing characters: close the open string with a ", then close any unclosed arrays and objects in the correct nesting order. If the truncation happened in the middle of an important value, you cannot reliably guess what the complete value originally was, and the only correct fix is to obtain a complete copy of the data from the source system.

Invisible characters in JSON come from several reliable sources. A BOM (byte order mark U+FEFF) gets prepended to UTF-8 files by some editors that default to BOM mode. Zero-width spaces (U+200B) sometimes get accidentally inserted by word processors that auto-correct copied text. Non-breaking spaces (U+00A0) often arrive from HTML or PDF content that used them for layout. Control characters like raw newlines can be copied from any plain text source. A hex editor, a Unicode-aware code editor, or any tool that displays raw code points will reveal these. The fix is to identify the offending code point and either remove or escape it appropriately.

For ninety-five percent of use cases, an off-the-shelf validator like the standard library JSON.parse plus a schema library such as AJV is the right answer. They are battle-tested, fast, and updated against new spec drafts as those drafts ship. A custom validator only makes sense when you have unusual requirements: streaming validation of multi-gigabyte payloads where you cannot afford to hold the whole structure in memory, schema dialects that no mainstream library supports, or extreme low-latency constraints where every microsecond counts. Even in those cases, start with an existing library and profile its behaviour before deciding to write your own. The maintenance cost of a hand-rolled validator over years of changing spec drafts is substantial, and most teams underestimate it on day one. FixTools leans on standard browser JSON.parse for exactly this reason.