IndexError: Fix List Index Out of Range in Python

You've written a loop that works on every test case, deployed it with confidence, and at 2 AM your phone buzzes: IndexError: list index out of range. Nothing about the code changed. What changed was the data — an empty API response, a short batch on the last page, one record fewer than yesterday. This error fires when your code asks for a list position that doesn't exist: index 3 on a 3-item list (valid slots are 0–2), [0] on an empty list, or -4 on a 3-item list. It shows up most often in four places: hand-rolled range(len()) loops with a + 1 that overshoots, pagination code that assumes every page is full, pop() or remove() calls that shrink a list mid-loop, and straight-line reads like rows[0] after a query that sometimes returns nothing. The fix is usually a one-line guard or a corrected bound, but finding which line matters — the traceback points at the exact indexing expression, and len() at that spot tells the whole story. This article walks through reading that traceback, the negative-indexing rules that surprise people, why slicing never raises, and when a len() check beats try/except (and vice versa).

Your Index Hit len(): Why Valid Positions Stop One Short

A list of length n owns exactly n slots, numbered 0 through n - 1. That's the entire rule, and every IndexError is this rule being broken: the code asked for a slot outside that span. The most common violation is indexing with len(items) itself — on a 3-item list that's items[3], one past the last real slot 2. It reads naturally ("the item at the length") but it's always wrong, and Python raises instead of returning None or wrapping around. The second classic is the empty list. [] has length 0, which means it has no valid indexes whatsoever — not even [0]. Code like rows[0] after a database query or API call works for months, then crashes the first night the upstream returns zero records. Both cases share one diagnostic: print len() beside the index at the crash line and the mismatch is obvious. The fix is mechanical. For the last element write items[len(items) - 1] (or items[-1]), and for possibly-empty data read defensively with rows[0] if rows else default. These aren't style preferences; they're the boundary check the list itself enforces. The traceback helps more than most beginners expect. Its final line names the exception, and the frame just above it prints the exact source text of the failing read plus the file and line number. When several bracket reads share one line, split them across lines and rerun -- the guilty expression identifies itself. Tuples and strings enforce the same span with their own messages (tuple index out of range, string index out of range), so the same counting rule transfers directly.

orders = ["o-101", "o-102", "o-103"]
print("length:", len(orders))
print("valid slots: 0 to", len(orders) - 1)
print("last:", orders[len(orders) - 1])

# Index equal to len() is one past the end
try:
    print(orders[len(orders)])
except IndexError as exc:
    print("orders[3] -> IndexError:", exc)

# Empty lists have no valid index at all
rows = []
print("empty guard:", rows[0] if rows else None)

range(len()) Off-by-One: The Extra +1 That Crashes the Last Pass

The range(len()) idiom exists to visit every valid position exactly once, because range(n) yields 0 through n - 1 — the same span as the list's slots. The crash creeps in when someone "fixes" the loop by adding + 1, usually after confusing range() (which excludes its stop) with the list (which they fear excludes its last item). range(len(items) + 1) yields one extra value, len(items) itself, and the body reads one past the end on its final pass. What makes this nasty is timing: the loop prints every correct element first, so logs look healthy right up to the traceback. It also hides in refactors — a loop that once iterated range(count) where count was already len - 1 gets "simplified" into the overshoot. The repair is to delete the + 1, but the durable fix is to stop hand-rolling counters. for item in items needs no bound at all, and for i, item in enumerate(items) hands you correct indexes that can't drift. Reserve arithmetic on len() for the rare cases (sliding windows, pairwise compares) where you genuinely need it, and there write range(len(items) - 1) deliberately. Reviewers catch this class in seconds by scanning loop bounds for + 1 and - 1. Every adjustment to a range() stop deserves a boundary test: one run with a single-element list and one with an empty list. enumerate(items, start=1) covers display numbering without touching the index math, and reversed(range(len(items))) covers backward walks. When the bound is right, the loop has no way to overshoot.

items = ["red", "green", "blue"]

# Correct: range(len()) stops at len() - 1
for i in range(len(items)):
    print(i, items[i])

# The classic overshoot: + 1 walks one past the end
try:
    for i in range(len(items) + 1):
        print(items[i])
except IndexError as exc:
    print("overshoot -> IndexError:", exc)

# Cleaner: let enumerate() own the counter
for i, color in enumerate(items):
    print(i, color)

Negative Indexes Stop at -len: When -4 on 3 Items Raises

Negative indexes count back from the end: -1 is the last element, -2 the one before, down to -len(items) which is the first. Newcomers often conclude negatives are inherently safe — they can't overshoot, right? They can. Anything smaller than -len(items) points before the start of the list, and Python raises IndexError exactly as it does for oversized positives. items[-4] on a 3-item list fails because the valid negative span for length 3 is -3 to -1. This bites in offset arithmetic: items[-window] where window grows past the list length, or items[idx - k] where a subtraction drags a small index below -len. The diagnostic is the same print-both-sides trick: show the index and -len(items) together. Fixes depend on intent. When wraparound is genuinely wanted, normalize with idx % len(items) so any integer lands on a real slot. When the offset is user input or a computed window, validate -len(items) <= idx before indexing and handle the short-data branch explicitly. And note the asymmetry that confuses people: -0 is just 0, so there's no negative zero slot — another reason to normalize rather than reason it out by hand. When in doubt, print both sides of the comparison: the index and -len(items) on one log line settle the question instantly, even at 2 AM.

letters = ["x", "y", "z"]
print("last:", letters[-1])
print("first via negative:", letters[-len(letters)])

for bad in [-4, -99]:
    try:
        print(letters[bad])
    except IndexError as exc:
        print(bad, "-> IndexError:", exc)

# Normalize a wild offset so it always lands on a slot
wild = -7
print("normalized:", letters[wild % len(letters)])

Slicing Never Raises: Why [5:9] Returns [] Instead

Here's the asymmetry every Python programmer must internalize: items[9] on a 3-item list raises, but items[9:12] calmly returns []. Slicing never raises IndexError — not for wild starts, wild stops, empty lists, or reversed bounds (those return [] too). Under the hood, slice bounds get clipped to the [0, len] span before anything is fetched, so whatever fits is returned and nothing is an error. This isn't a quirk; it's the feature that makes pagination, chunking, and windowing code clean. batch[i:i + 500] on the final short page returns the remaining rows instead of crashing, and history[-30:] on a 4-item list returns all 4. The practical rule: use slices for speculative reads (positions that might not exist) and brackets for proven positions. When a crash report shows bracket indexing on a computed offset in paging code, the one-line fix is usually converting batch[i + k] into batch[i:i + k + 1] handling. One caution: clipping cuts both ways — a slice silently returning [] can mask a logic bug upstream, so check if chunk: when an empty result should be suspicious rather than normal. One caution: clipping cuts both ways -- a slice that quietly returns [] can mask a logic bug upstream, so check if chunk: when an empty result should look suspicious rather than normal. Pair slices with an explicit empty-branch and you get crash-proof reads without losing visibility into bad data.

nums = [1, 2, 3]
print(nums[5:9])      # [] — start past the end
print(nums[10:])      # [] — entirely past the end
print(nums[:100])     # [1, 2, 3] — stop clipped to len
print(nums[-100:2])   # [1, 2] — start clipped to 0
print([][0:5])        # [] — slicing an empty list is fine

# Practical: safe fixed-size chunks, short last page included
page = nums[2:5]
print("page:", page if page else "no more rows")

Pop Inside the Loop: The Mutation That Skips and Crashes

The ugliest IndexError shape is the self-inflicted one: the loop's bound was valid when computed, then the body shrank the list out from under it. for i in range(len(items)) snapshots the original length up front; every pop() or remove() inside shortens the list while i keeps climbing toward the stale length. Two failures follow. Late passes read past the new end and raise, and earlier passes silently skip elements because everything after a removal shifts one slot left while i advances one right. Logs make this miserable to diagnose: half the items process fine, one vanishes without a trace, then the traceback fires pages away from the real cause. The fix is structural, not a bigger guard — stop mutating the list you're indexing. Draining loops should be while items: items.pop(0) (or pop() from the end), which re-checks emptiness every pass. Filtering should run in two passes: collect targets with a comprehension, then delete, or better, build the survivor list directly. If you must index and delete in one pass, walk backward with range(len(items) - 1, -1, -1) so removals only disturb slots you've already visited. The backward-walk exception proves the rule: range(len(items) - 1, -1, -1) stays valid because deletions only disturb slots you have already visited, never the ones ahead of the cursor.

queue = [10, 20, 30, 40]
processed = []
while queue:
    processed.append(queue.pop(0))
print("drained:", processed)

# Two-pass filter: collect first, delete after
scores = [5, 8, 3, 9, 2]
bad = [s for s in scores if s < 6]
for s in bad:
    scores.remove(s)
print("kept:", scores)

# Or build the survivors directly
scores = [5, 8, 3, 9, 2]
print("filtered:", [s for s in scores if s >= 6])

len() Check vs try/except: Reading the Traceback to the Guilty Line

Two tools guard an indexing read, and picking the right one is a judgment call, not a habit. The len() check (look before you leap) fits indexes your own code computes: if i < len(items): use(items[i]). It's explicit, costs nothing, and documents the invariant for the next reader. The try/except IndexError (easier to ask forgiveness) fits speculative reads — user-supplied positions, plugin data, or lists another thread mutates between your check and your read. Its great virtue is atomicity: no gap between validation and access. Whichever you choose, the traceback is your compass. Python prints the exact file, line number, and source text of the failing expression in the frame above IndexError, so you never have to guess which of five bracket reads fired. Copy that expression, print each index and each len() feeding it, and the culprit confesses. One hard rule: catch IndexError and nothing broader. except Exception around indexing swallows TypeError from a None list and NameError from a typo'd variable, converting loud, fixable bugs into silent wrong behavior that pages you months later. Copy the failing expression from the traceback frame, print each index and each len() feeding it, and the culprit confesses within minutes -- no debugger required.