</>Indentio

XML & JSON error messages explained

Reference · Updated July 2026

Parser error messages are written for parser authors, not for the person holding the broken file. This index translates them. Find the message you were given below — each entry says what actually went wrong, and links to the full explanation where there is more to know.

In a hurry? Paste the document straight into theJSON validator orXML validator. Both underline the exact line and column and explain the problem in plain English, entirely in your browser — nothing is uploaded.

JSON error messages

A note that saves a great deal of time: when a JSON error reportsposition 0, char 0, or line 1 column 1, your JSON is almost certainly not malformed. Something that was never JSON arrived instead — an HTML page, an empty body, or a filename.

Unexpected token < in JSON at position 0

You received HTML, not JSON — a 404 page, a 500 page, or a login redirect. No JSON document begins with an angle bracket. Log the response body before parsing it.

Full explanation →

Unexpected token '<', "<!DOCTYPE "... is not valid JSON

The same error in newer Node and Chrome, reworded. The quoted preview shows you exactly what arrived — an HTML document.

Full explanation →

Unexpected token o in JSON at position 1

You passed an object to JSON.parse. JavaScript converted it to the string [object Object] first. The value was already parsed — remove the extra parse call.

Full explanation →

Unexpected end of JSON input

The document ended early: an empty response body, a truncated download, or an unclosed bracket. An empty string is not valid JSON, so a 204 No Content response triggers this too.

Full explanation →

Expecting value: line 1 column 1 (char 0)

Python’s version of the same problem. Failing at char 0 means the input was empty, was HTML, or was a filename string passed to json.loads instead of file contents.

Full explanation →

Extra data: line 2 column 1

Parsing succeeded, then found more content. Your file holds several JSON documents — usually NDJSON, one object per line. Parse it line by line rather than in one call.

Full explanation →

Expecting property name enclosed in double quotes

A key is unquoted or single-quoted, or a trailing comma left the parser expecting another key. JSON requires double quotes on every key.

Full explanation →

Invalid control character at

A literal newline or tab sits inside a string. Characters below U+0020 must be escaped as \n and \t.

Full explanation →

JSON.parse: unexpected character at line 1 column 1 of the JSON data

Firefox’s wording for a response that was never JSON. Same diagnosis as “Unexpected token <”.

Full explanation →

Unexpected token } in JSON

Almost always a trailing comma before the closing brace. JSON, unlike JavaScript and Python, forbids it.

Full explanation →

Duplicate key

The specification permits duplicate keys but leaves the result undefined — most parsers keep the last one silently. Strict linters reject it. Deduplicate the source.

Full explanation →

XML error messages

XML parsers distinguish well-formedness errors fromvalidity errors. Everything below is a well-formedness failure — the document did not parse at all. Schema validation against a DTD or XSD only runs once a document parses cleanly, so fix these first.

Content is not allowed in prolog

Something sits before the XML declaration — most often an invisible UTF-8 byte-order mark, a leading blank line, or an HTML error page returned instead of the file.

Full explanation →

Data at the root level is invalid. Line 1, position 1.

The .NET wording for exactly the same problem: illegal bytes before the root element.

Full explanation →

Start tag expected, '<' not found

The PHP and lxml phrasing when the document does not begin with markup. Check for a BOM, leading whitespace, or a non-XML file.

Full explanation →

The string '--' is not permitted within comments

Two consecutive hyphens appear inside a comment, which XML forbids anywhere in a comment. Usually caused by commenting out a block that already contained a comment.

Full explanation →

The document is not mappable to XML 1.0 due to two consecutive hyphens in a comment

The same rule, reported at serialisation time by Java DOM and some XSLT processors — meaning the comment was probably generated in code rather than typed.

Full explanation →

The reference to entity must end with the ';' delimiter

A bare ampersand in your text. In XML, & begins an entity reference, so a literal one must be written &amp;. URLs with query strings are the classic case.

Full explanation →

XML document structures must start and end within the same entity

An element was opened and never closed, so the parser reached end of file still waiting. The reported position is the end of the document, not the real mistake — look for the unclosed tag.

Full explanation →

Premature end of file

The document was truncated: an interrupted download, a partially written file, or an empty response. Check the file size first.

Full explanation →

The element type must be terminated by the matching end-tag

A mismatched or missing closing tag. XML nesting is strict and case-sensitive, so <User>…</user> counts as mismatched.

Full explanation →

Invalid byte 1 of 1-byte UTF-8 sequence

The declared encoding does not match the actual bytes — typically a Windows-1252 file declared as UTF-8, failing at the first accented character. Re-save it as real UTF-8.

Full explanation →

The processing instruction target matching "[xX][mM][lL]" is not allowed

An XML declaration appears somewhere other than the very first bytes — often because two documents were concatenated, or a template emitted output before the declaration.

Full explanation →

Attribute value must be quoted / duplicate attribute

Every attribute value needs matching quotes, and no element may carry the same attribute twice. Watch for smart quotes pasted from a word processor.

Full explanation →

Reading any parser error

Three habits solve most parse failures faster than searching for the message verbatim:

  • Trust the position only as a hint. Parsers report where they gave up, which is usually just after the real mistake. A missing comma is reported at the following token; an unclosed tag is reported at end of file. Look backwards from the reported spot.
  • Failures at the first character are a different class of bug. They mean the content is not the type you expected at all, so inspect the raw bytes rather than the syntax.
  • Print what you actually received. Most “invalid JSON” and “invalid XML” reports over HTTP are error pages in disguise. One log line of the response body settles it immediately.

Hit a message that is not listed here? Send it to us — reader reports decide what gets added next.