Free · Fast · Privacy-first

JSON Formatter and Validator

Formatting JSON and validating it should happen together because there is no point beautifying invalid JSON.

⚡

Format and validate in one step

🔒

Highlights exact error location

✨

Explains what went wrong

⚡

Free, no account required

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

FreeNo signupWhite-label

Add this JSON Formatter to your website

Drop the JSON Formatter 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-formatter?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="JSON Formatter by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

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

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

Why Formatting and Validation Are the Same Operation Under the Hood

To format JSON, a tool must parse it first. Parsing means traversing every token in sequence: the opening brace or bracket, each key string, the colon separator, the value token, the comma delimiter, and finally the closing brace or bracket. If any token is out of place or malformed, the parser throws an error at that exact position. A trailing comma after the last item in an array, a single-quoted string key instead of a double-quoted one, an unquoted identifier used as a key, or a mismatched closing bracket each causes a parse error at a specific character position. This means any formatter that actually works by parsing its input is inherently a validator. A tool that "formats" JSON without parsing it is doing text manipulation on a string and will silently produce incorrect output for invalid input.

The most common JSON syntax errors that are frequently missed without a validator are: trailing commas (which are valid in JavaScript object and array literals but explicitly invalid in JSON), single-quoted strings (valid in JavaScript, invalid in JSON), NaN and Infinity values (valid JavaScript number literals but not defined in the JSON specification), and comment syntax (// and /* */ comments, valid in JavaScript and JSONC, but invalid in standard JSON). These errors are introduced most often when developers copy data from JavaScript source code into a standalone JSON file, because the two syntaxes look very similar but diverge in exactly these points.

RFC 8259 and ECMA-404 are the two authoritative specifications that define what constitutes valid JSON. RFC 8259 is published by the Internet Engineering Task Force and is the standard for JSON in network protocols. ECMA-404 is the ECMA International standard. Both define JSON as a strict text format that excludes comments, trailing commas, single-quoted strings, and unquoted keys. Both require all object keys to be double-quoted strings. FixTools uses the browser's native JSON.parse() for validation, which is a conformant implementation of these standards, so the validation result exactly matches what any production JSON parser in Python, Java, Go, or Ruby will accept or reject.

Several validation edge cases bite developers regularly. Duplicate keys in a single object are permitted by RFC 8259 but the behaviour of parsers when they encounter duplicates is unspecified: most keep the last value seen, some keep the first, and a few raise an error. The result is data loss that no syntax validator catches because the document is technically legal. Number precision is another quiet trap: JSON allows arbitrary-precision numbers in the grammar but JavaScript parses them all as 64-bit floats, so an integer like 9007199254740993 loses precision and round-trips as 9007199254740992. For financial or identifier data, serialise large integers as strings or use a BigInt-aware parser. Finally, the line separator U+2028 and paragraph separator U+2029 are legal in JSON strings but break some legacy JavaScript eval-based deserialisers, so escape them defensively when targeting older clients.

Syntax validation is also distinct from semantic validation, and conflating the two leads to confusion in bug reports. Syntax validation asks: is this text parseable as JSON per RFC 8259? Semantic validation asks: do the parsed values satisfy the expected schema, type constraints, and business rules? FixTools handles only the first. For the second, run the parsed result through a JSON Schema validator like Ajv in JavaScript or jsonschema in Python, both of which check required fields, type compatibility, regex patterns on strings, numeric ranges, and array length constraints declared in a schema document. The two layers compose: a payload that passes FixTools but fails schema validation has correct syntax but wrong content, and the error message from each tool isolates which layer failed.

RFC 8259, Full JSON Syntax Definition ECMA-404, The JSON Data Interchange Standard MDN: JSON.parse(), validation behaviour

How to use this tool

💡

Paste your JSON and click Format. Any syntax errors are highlighted with an explanation; valid JSON is formatted and displayed.

How It Works

Step-by-step guide to json formatter and validator:

1
Paste your JSON
Paste the JSON you want to validate and format into the editor input area. The tool accepts any JSON string regardless of its current formatting state, including minified, partially indented, or manually edited JSON with inconsistent whitespace.
2
Click Format
FixTools validates the JSON using the browser's native JSON.parse(). If syntax errors exist, their exact line and column positions are reported and no formatting is attempted. If the JSON is valid, it is formatted immediately with your chosen indentation setting.
3
Fix errors or copy output
If errors are reported, the error message tells you the line and position of the problem. Fix the syntax in the input field and click Format again. If the JSON is valid, copy the formatted output with the copy button and use it in your project.

Real-world examples

Common situations where this approach makes a real difference:

Backend developer

A developer writes a JSON config file by hand and gets an unexpected parse error in production. Pasting the config into FixTools immediately highlights the problem: a trailing comma after the last key in the "database" object, introduced when a commented-out configuration line was deleted but the comma on the preceding line was not removed at the same time. The exact error position and explanation make the fix immediately obvious without searching through a long config file.

API developer

An API developer receives a bug report that a client application crashes when parsing a specific response. Pasting the raw response JSON into FixTools reveals it contains a NaN value in a numeric calculation field, which the API was producing for a division-by-zero case in the backend logic. The formatter flags it as invalid because NaN is not a valid JSON value per RFC 8259, confirming that the bug is a serialisation error in the API, not a parsing error in the client.

DevOps engineer

An engineer updating a Kubernetes resource configuration stored as JSON pastes the modified file into FixTools before applying it to the cluster. The validator catches a missing comma between two top-level keys that were added in the same editing session. Catching this syntax error before the apply command prevents a failed deployment and the need to investigate cluster state or roll back a partially applied configuration.

Data pipeline developer

A developer building an ETL pipeline receives JSON data from a legacy system that uses single-quoted strings for all string values, a common output format for some older PHP and Python serialisation libraries. Pasting a sample record into FixTools confirms the format is invalid per RFC 8259. The validator output tells them exactly what is wrong and confirms they need a preprocessing step to convert single quotes to double quotes before passing the data to any standard JSON parser.

Pro tips

Get better results with these expert suggestions:

Trailing commas are the most common error

JSON does not allow trailing commas after the last item in an array or the last key-value pair in an object. JavaScript object literals do allow them, so developers who copy JS data structures into JSON files encounter this error frequently. The validator reports the exact position of the trailing comma. Look for a comma immediately before a closing } or ] bracket.

Keys must be double-quoted strings

Valid JSON requires all object keys to be double-quoted strings. The form {name: "Alice"} is valid JavaScript but invalid JSON because the key is unquoted. The form {"name": "Alice"} is valid JSON. If the validator reports "unexpected token" at the position of a key, check whether the key has double quotes on both sides and that they are standard ASCII double quotes, not curly or smart quotes.

Use line numbers to locate errors quickly

When the validator reports an error at a specific line and column, use the Ctrl+G (Windows/Linux) or Cmd+L (macOS) shortcut in many editors to jump to that line number directly. In the browser input area, count from the top or use Ctrl+F to search for the text near the reported position. Going directly to the error location is much faster than scanning a large JSON payload manually.

NaN and Infinity are not valid JSON

JavaScript defines NaN and Infinity as special numeric values. The JSON specification does not include them. If your serialiser produces these values in JSON output (which some JavaScript serialisers do for floating-point edge cases), the resulting text fails validation in any RFC 8259-compliant parser. Replace NaN with null and Infinity with a sentinel number like 1e308 or null before serialising, depending on what the receiving application expects.

FAQ

Frequently asked questions

Yes. When you click Format, FixTools passes the input to the browser's JSON.parse() function, which validates the syntax against the RFC 8259 specification. If parsing fails because of a syntax error, the error position and a description of the problem are displayed and no formatted output is produced. If parsing succeeds, the parsed data structure is immediately re-serialised using JSON.stringify() with your chosen indentation, producing the formatted output. The two operations happen sequentially in the same single click.

The validator catches all JSON syntax errors defined by RFC 8259: missing commas between key-value pairs or array items, trailing commas after the last item, unquoted key names, single-quoted strings instead of double-quoted strings, mismatched or missing brackets and braces, invalid escape sequences inside strings, numbers in invalid formats (like leading zeros or hexadecimal notation), and values that are not valid JSON (NaN, Infinity, undefined). It does not validate data types or required fields against a schema, which requires a separate JSON Schema validator.

Yes. Use the dedicated JSON Validator tool at fixtools.io/json/json-validator if you only need to check the validity of a JSON string without changing its formatting. The validator uses the same RFC 8259-compliant JSON.parse() check but leaves the whitespace structure of the input unchanged, so you get the validation result without any reformatting of your document.

JSON syntax validation checks that the text is parseable as JSON per RFC 8259. JSON Schema validation checks that the parsed data conforms to a defined schema: required fields are present, values have the correct data types, strings match regular expression patterns, numbers fall within specified ranges, and arrays have the expected number of items. FixTools performs syntax validation only. JSON Schema validation requires a schema document and a schema validator like Ajv for JavaScript or jsonschema for Python.

Several invisible or non-obvious issues can cause this. A byte order mark (BOM) at the start of the file is invisible in most text editors but rejected by strict JSON parsers. Invisible Unicode control characters inside string values can cause parser errors at unexpected positions. A trailing newline or space after the final closing brace is usually harmless but can cause issues in some strict parsers. Windows-style CRLF line endings inside string values can also cause problems. Paste the JSON into FixTools and check the error message for the exact position of the unexpected character.

FixTools does not auto-correct syntax errors because any correction involves guessing the intended structure. Removing a trailing comma is unambiguous, but a missing closing bracket could be fixed in multiple valid ways depending on where the developer intended the structure to end. Automatic correction of incorrect JSON can silently change the meaning of the data, which is worse than reporting the error. The tool shows the exact error position so you can make the correct fix yourself in the source.

Yes. The browser's native JSON.parse() is a compiled, highly optimised function that handles files of several megabytes in milliseconds. For very large files of tens of megabytes, the parsing step itself remains fast but rendering the syntax-highlighted output in the browser can take longer because the browser must create a large number of DOM elements for each line and token. Validation feedback for large files is fast even if rendering takes a moment.

Yes, for any parser that implements RFC 8259 correctly. The browser's JSON.parse() is a conformant implementation of the JSON standard, so it accepts and rejects the same input as Python's json.loads(), Java's ObjectMapper, Go's json.Unmarshal(), Ruby's JSON.parse(), and other specification-compliant parsers in any language. Non-standard parsers that accept a superset of JSON (such as those accepting comments or trailing commas) will be more permissive and may accept input that FixTools correctly flags as invalid.

Three causes account for almost every case. First, the downstream service may apply a JSON Schema check on top of RFC 8259 syntax validation, requiring specific fields, types, or value ranges that your data does not satisfy. Second, it may enforce a maximum depth or maximum array length to prevent denial-of-service attacks; a payload nested 200 levels deep is syntactically valid but rejected by Jackson with its default 1000-depth limit or by Go encoding/json under custom limits. Third, the service may require a specific top-level type such as an object rather than a bare array or scalar, which RFC 7159 permits but older RFC 4627 parsers reject. Run the schema check and depth check explicitly to isolate which rule is failing.

The validation itself is safe: JSON.parse cannot execute arbitrary code, unlike the legacy eval() approach. However, two risks remain when handling untrusted JSON. Prototype pollution is the most common: a payload containing a __proto__ key can mutate Object.prototype if your code does an unsafe deep merge into an existing object after parsing. Use Object.create(null) for target objects and disallow __proto__, constructor, and prototype keys explicitly. The second risk is resource exhaustion: a deeply nested or extremely large input can consume excessive memory during parsing. Set explicit input size limits at your API gateway and use a streaming parser like clarinet or ijson when accepting multi-megabyte uploads.