Skip to content

YAML error

“did not find expected key”

The parser was inside a mapping and expected either another key at the same indentation or the end of the block, but found something that cannot be a key: a line dedented by the wrong amount, a list dash, or an invisible character. Line up the indentation of the line it reports with its siblings.

By yamltojsonfree · Published · Updated

What the parser is telling you

YAML groups keys into a mapping by their column. While reading the mapping, the parser accepts exactly two things on the next line: a key at the same column, or a line further left that closes the block. Anything else, such as a key at a column that belongs to no open block, a - where a key should be, or a ] from an unclosed bracket, produces this message.

The location it prints is where it gave up, which is usually the first line after the mistake, and the “while parsing a block mapping” line above it in the full message names where that mapping started. In kubectl and Helm the number counts from the start of the current document, not the file, and is often one lower than you would count by hand.

Who prints this message

libyaml and its ports: go-yaml behind kubectl, Helm, kustomize and Docker Compose, Ruby’s Psych, and PyYAML with the C loader. The pure-Python PyYAML loader says “expected <block end>, but found ...” for the same situations.

The causes, with fixes

Broken YAML on the left, the corrected form on the right. The fix under each pair is the one that applies to that cause.

A key dedented to a column that belongs to nothing

port sits at one space: too far left to belong to the server block at two spaces, too far right to be a top-level key. The parser closes the inner block, then finds a key at column 2 where it expected column 1.

Broken

server:
  host: localhost
 port: 80

Fixed

server:
  host: localhost
  port: 80

Fix: Every sibling key must sit at exactly the same column. Files that mix two-space and four-space indentation are the usual source.

A list item where a key was expected

Inside a mapping, a line starting with - is a sequence entry, and a mapping cannot hold bare sequence entries next to keys. This is common in env: blocks and Compose environment: sections that mix the two styles.

Broken

env:
  NAME: api
  - DEBUG=1

Fixed

env:
  NAME: api
  DEBUG: "1"

Fix: Pick one style for the whole block: all key: value lines, or all - item lines.

An invisible character at the start of a line

A byte-order mark or another invisible character pasted into the middle of a file is not whitespace, so the parser sees a key that starts before the expected column. The line looks identical to its neighbours in most editors.

Broken

a: 1
\uFEFFb: 2

Fixed

a: 1
b: 2

Fix: The broken example shows the byte-order mark as \uFEFF; in the file it is invisible. Show invisible characters in your editor, or run the file through cat -A. The control characters page covers the rest of this family.

Find it fast

  1. 1.Look at the line before the one reported and compare its indentation with the line above it, counting spaces.
  2. 2.If the reported line begins with -, decide whether the block is a mapping or a list and make every line match.
  3. 3.If the indentation looks right, look for an unclosed [, { or quote earlier in the document; the parser may have swallowed several lines before failing here.
  4. 4.Paste the document into the YAML validator on this site, which marks the line and, for unclosed brackets and quotes, names the line where the delimiter was opened.

The same error in other parsers

ParserMessage
libyaml, go-yaml (kubectl, Helm, Compose), Ruby Psychdid not find expected key
PyYAML, pure-Python loaderexpected <block end>, but found '<block mapping start>' or '-'
js-yaml (Node, most browser tools)bad indentation of a mapping entry
yaml (npm)All mapping items must start at the same column
This site’s validatorA mapping entry isn’t lined up with the block it belongs to.

Frequently asked questions

Why is the line number one below the mistake?

The parser only discovers the problem when it reads the next token, so it reports the line where it stopped rather than the line that is wrong. Start from the reported line and work upward. Go-based tools such as kubectl also print a number that is often one lower than the line you would count in an editor, and they count from the start of the current YAML document rather than the file.

Is this the same as “inconsistent indentation”?

Yes in practice. Linters and editors describe the same situation as inconsistent or wrong indentation; “did not find expected key” is how libyaml and go-yaml report it. yamllint, for example, prints “wrong indentation: expected 2 but found 1” for the first example above.

How do I find the wrong line in a large Kubernetes manifest?

Split the file at the --- separators, because kubectl reports lines within one document. Then paste that document into the validator on this site, which marks the exact line, or run yamllint on the file, which names the expected and actual indentation.

Related errors

“mapping values are not allowed in this context”

The parser hit a colon followed by a space in the middle of a value, where YAML only allows a colon after a key. Quote the value if the colon is part of it, or fix the line above if the parser was still reading it.

Read the fix

“bad indentation of a mapping entry”

js-yaml reports several unrelated mistakes under this one message: an unquoted value containing a colon, a sibling key indented differently, a key nested under a key that already has a value, or a value starting with @ or a backtick. Check the reported line for each, in that order.

Read the fix

“control characters are not allowed”

The file contains a byte that YAML forbids anywhere in a document: a control character such as a terminal escape code, a form feed, a NUL byte or DEL. The usual source is coloured command output redirected into a file. Find the byte with grep and delete it.

Read the fix

“error converting YAML to JSON”

kubectl does not parse YAML directly. It converts each document to JSON first, and this wrapper means that conversion failed because the YAML is malformed. The real error is the part after “yaml: line N:”, and N counts from the start of that document, not from the top of the file.

Read the fix

All six underlying mistakes, ordered by cause rather than by message, are in the guide Common YAML errors and how to fix them. Every one of them is caught with the exact line and a suggested fix by the free tools below; nothing is uploaded.

YAML to JSON

Convert YAML into formatted or minified JSON, with errors pinned to the exact line.

Open

JSON to YAML

Turn JSON back into readable YAML, with control over indentation and key order.

Open

YAML Validator

Check YAML for syntax errors and get a plain-English explanation of what went wrong.

Open

YAML Formatter

Reformat messy YAML with consistent indentation and keep your comments intact.

Open