KeyError when the key looks present (tested)

If print(d) shows the key sitting right there and d[key] still raises KeyError, the key you're looking up isn't actually equal to the key that's stored — even though they look identical when printed. Dict lookup uses == and hash(), not a visual match, so two values that render the same text can still be different objects. We reproduced five distinct ways this happens.

1. Five reproduced causes, same visual trap

Each of these prints as if the key is there, then raises anyway:

In every case the printed representation of the two keys is indistinguishable. The fix is always to find the invisible difference, not to assume the key is simply missing — see Python KeyError: causes and fixes for the plain missing-key case instead.

2. Cause 1: int keys, string lookup (or vice versa)

1 and '1' print differently if you look closely, but it's easy to miss in a wall of output, and JSON makes it worse: json.loads() always produces string keys, even for numeric-looking ones.

>>> d = {1: 'a', 2: 'b'}
>>> d['1']
Traceback (most recent call last):
  ...
KeyError: '1'

>>> import json
>>> d = json.loads('{"1": "a"}')
>>> d
{'1': 'a'}
>>> d[1]
Traceback (most recent call last):
  ...
KeyError: 1

Fix: check type(key) against the actual keys (list(d.keys())[0].__class__), and cast explicitly — d[int(key)] or d[str(key)]. CSV rows and JSON objects are the two most common sources of this mismatch, since both can produce string keys for data that looks numeric.

3. Cause 2: trailing whitespace or newline from file reads

readlines() (and iterating a file object directly) keeps the trailing \n on every line. Printed, 'name\n' and 'name' can look the same in a terminal that just eats the newline visually.

>>> lines = open('keys.txt').readlines()
>>> lines
['name\n', 'age\n']
>>> key = lines[0]
>>> key == 'name'
False
>>> d = {'name': 'Alice', 'age': 30}
>>> d[key]
Traceback (most recent call last):
  ...
KeyError: 'name\n'

Fix: .strip() every line pulled from a file before using it as a key (or a lookup value) — key = line.strip(). If the traceback's key has a visible \n or extra spaces inside the quotes, this is the cause.

4. Cause 3: case sensitivity

Dict keys are ordinary strings underneath, and string comparison in Python is always case-sensitive — there's no special-casing for dict keys.

>>> d = {'Name': 'Alice'}
>>> d['name']
Traceback (most recent call last):
  ...
KeyError: 'name'

Fix: normalize case on the way in and out — store and look up with key.lower() consistently, or build the dict with a case-insensitive wrapper if the keys come from user input or an external API that doesn't guarantee casing.

5. Cause 4: looking at a different dict object than the one you're indexing

If a copy was taken before a mutation, or a variable got reassigned between the print() and the lookup, the two can diverge even though they share a name or started out equal.

>>> original = {'a': 1}
>>> snapshot = dict(original)
>>> original['b'] = 2
>>> print(original)
{'a': 1, 'b': 2}
>>> snapshot['b']
Traceback (most recent call last):
  ...
KeyError: 'b'

dict(original) (and .copy()) makes a shallow copy at that moment — later changes to original don't propagate to snapshot. The same confusion happens when a function parameter shadows an outer-scope variable of the same name: printing the outer one and indexing the parameter looks like the same object in the source code, but isn't. Fix: check id(d) at both the print and the lookup if you suspect this — if the ids differ, they're not the same object, no matter what the variable is named.

6. Cause 5: Unicode normalization (accented characters)

Some characters have more than one valid Unicode representation: an accented letter can be a single composed code point (NFC) or a base letter plus a separate combining accent mark (NFD). Both print identically; neither == nor dict lookup treats them as equal.

>>> import unicodedata
>>> nfc = unicodedata.normalize('NFC', 'café')
>>> nfd = unicodedata.normalize('NFD', 'café')
>>> nfc == nfd
False
>>> len(nfc), len(nfd)
(4, 5)
>>> d = {nfc: 'drink'}
>>> d[nfd]
Traceback (most recent call last):
  ...
KeyError: 'café'

This is rare but real — it shows up when keys come from different sources (one typed on macOS, which tends to produce NFD, versus one from a web form or API that sends NFC). Fix: normalize every key to the same form before using it, e.g. unicodedata.normalize('NFC', key), consistently on both the write and read side.

7. Fix checklist

• Print repr(key), not key — repr() shows quotes, \n, and other invisible characters that plain printing hides.
• Compare types: type(key) vs. type(list(d.keys())[0]). A silent int/str mismatch is the single most common version of this.
• If the key came from a file line, .strip() it. If it came from user input or an external API, consider .lower() and unicodedata.normalize() on both sides.
• If you printed one dict and indexed another, check id() on both at the point of failure — the same variable name does not guarantee the same object.
• For the plain "key is genuinely absent" case (typos, optional fields, unset env vars), see Python KeyError: causes and fixes.

Written with AI assistance. Measured on 2026-10-03 with Python 3.13.5 on Linux using plain python3 one-liners. Every traceback below is copy-pasted output, not paraphrased. PlainHeaders is our extension; Python is free.