Invalid JSON: read it, then find the first error

Invalid JSON: read it, then find the first error

An API response arrives as one long line, or a config file fails with an unexpected token. You need the text indented so you can see the shape, and you need the first place the grammar breaks.

invalid json Updated

One line is hard to read, and a broken line will not format

JSON that came off the wire is often a single line because whitespace costs bytes. The data can be fine and still be miserable to inspect. Indenting puts nested objects and arrays on their own lines so you can see what belongs to what, and the values stay as they were.

Formatting has a precondition. The formatter on this site will not rewrite invalid JSON. It reports the line and column of the first error and points you at the validator. Comments and trailing commas are rejected. Duplicate keys produce a warning, and the last value wins. Input is limited to 5 MB. Large integers and strings are kept as written, which matters when a number is an identifier rather than something you want rounded.

A file that looks almost like JSON is still invalid: a trailing comma, a comment copied from JavaScript, a single-quoted string. Nothing here repairs that. You edit the source until it parses. Schema checks, required fields, and types your API expects are a separate problem. A document can be valid JSON and still be the wrong shape for the program that reads it.

Validate, then indent, then open the tree

If you already suspect the text is broken, start with the JSON Validator. Paste the document. When it fails, the message names the line and column and says what to fix in plain language. Correct that spot and run it again. The first error is the one that stops the parse. Later mistakes can be hidden until this one is gone.

When the validator accepts it, open the JSON Formatter. Indent for reading, or squeeze it back to one line if you need a compact payload. The formatter is the wrong tool for a file that still has comments or a comma before a closing brace. Those have to come out in the editor first.

A deep document is awkward even after it is pretty. The JSON Viewer draws a collapsible tree. You expand the branch you care about, search keys and values, and copy the path to a node. That path is how you tell a teammate which field you mean without pasting the whole blob.

Use the three in that order when something fails: validator, then formatter, then viewer. If the text already parses and you only hate the wrapping, skip straight to the formatter. If you are hunting one key inside a response you trust, the viewer is enough.

How to deal with invalid JSON

  1. Copy the smallest chunk that still fails, and remove secrets from it before you paste anything into a page.
  2. Paste it into the JSON Validator and read the line and column of the first error.
  3. Remove the cause it names. Trailing commas and comments are not valid JSON here.
  4. Paste the corrected text into the JSON Formatter and indent it, or minify it if you need one line.
  5. If the structure is deep, open the JSON Viewer, search for the key, and copy the path.

What these tools will not do

  • They do not repair invalid JSON. A trailing comma, a comment, or single quotes have to be fixed by hand.
  • A successful parse does not mean the fields match your API. There is no schema check in this path.
  • The formatter stops at 5 MB and will not indent a document that fails to parse.
  • Duplicate keys are warned, and the last value is the one that remains.

Frequently asked questions

Why does my JSON say unexpected token?

The validator points at the line and column of the first break. Common causes on this tool are trailing commas and comments, which are rejected because they are not valid JSON.

Can I format JSON that does not parse?

No. The formatter reports the first error and leaves the text unchanged. Validate and edit until it parses, then indent.

Does formatting change the data?

It changes whitespace. The formatter keeps large numbers and strings as written. Duplicate keys are the exception: you get a warning, and the last value wins.

When should I use a tree instead of indented text?

When the document is valid and you need one nested value, or a path you can copy. Indenting is better when you want to read the whole structure from top to bottom.

Often used together with the When the JSON will not parse.

  • JSON ValidatorDeveloper Tools

    Checks JSON syntax and explains any error in plain English.

  • JSON ViewerDeveloper Tools

    Shows JSON as a collapsible tree with search and copyable paths.

More from the blog

All guides