Python: ValueError: invalid literal for int() with base 10

The exact error string

Traceback (most recent call last):
  File "app.py", line 2, in <module>
    qty = int(row["qty"])
ValueError: invalid literal for int() with base 10: ''

# the same error, different inputs — the value after the colon is always the real input:
ValueError: invalid literal for int() with base 10: 'abc'
ValueError: invalid literal for int() with base 10: '196.41'
ValueError: invalid literal for int() with base 10: '1,234'
ValueError: invalid literal for int() with base 10: '42​'

Python raises this when int() is handed a string it cannot read as a whole number in the requested base. The type was fine — a string is a perfectly acceptable argument — but the contents could not be parsed.

Everything below was verified on CPython 3.14.6.

Anatomy of the message

invalid literal for int() with base 10: '196.41'
                             ^^^^^^^^   ^^^^^^^^
                             |          |
                             |          +-- repr() of the exact string received
                             +------------- the base argument, which defaults to 10

Two things are easy to skim past, and both save time:

• "base 10" is not boilerplate. It is the second parameter of int(). Seeing it confirms nobody passed a different base, and it hints at the fix when your text really is hexadecimal or binary — see Fix 5.
• The value is a repr, not the raw text. That is a gift: a trailing newline shows as '42\n', a zero-width space as '42​', and an empty string as ''. Python is already showing you the invisible characters — most readers just don't realise the quotes and backslashes are meaningful.

Fix 1: the empty string

This form dominates real-world reports — the Stack Overflow question for invalid literal for int() with base 10: '' has over four million views, more than every other variant of this error combined. When the message ends in : '' there is nothing wrong with your conversion; you were handed a blank. It almost never comes from a literal in your code, so chase the source:

# consecutive delimiters produce an empty field
'1,2,,4'.split(',')        # ['1', '2', '', '4']   <- index 2 is ''

# a trailing newline produces an empty final line
'a\n\n'.splitlines()       # ['a', '']

# splitting an empty string does NOT give an empty list
''.split(',')              # ['']  <- one empty string, so the loop still runs once

The usual culprits are a blank CSV cell, a header row being parsed as data, an unfilled form field, a missing environment variable that defaulted to '', or a file ending with a newline. Handle it explicitly at the boundary:

raw = row.get("qty", "")
qty = int(raw) if raw.strip() else 0      # decide what a blank MEANS

# reading a file — skip blanks rather than letting them reach int()
for line in f:
    line = line.strip()
    if not line:
        continue
    process(int(line))

Decide deliberately whether a blank means zero, means "unknown", or means the row should be rejected. Silently defaulting to 0 is a common way to turn a data problem into a wrong number.

Fix 2: you don't need .strip()

Most guides on this error show .strip() as a required step. It isn't, and believing otherwise sends you looking in the wrong place:

int(' 42 ')        # 42   — surrounding spaces are ignored
int('42\n')        # 42   — trailing newline is ignored
int('\t42\r\n')    # 42   — tabs and CRLF too

int('4 2')         # ❌ ValueError — the space is INSIDE the number

So if your value only has whitespace around the edges, it already works and something else is wrong. Reach for .strip() only when you want to detect a blank (as in Fix 1), not to make a conversion succeed.

Fix 3: decimals, separators and exponents

int() parses integers, and will not round or reinterpret for you. Before reaching for a conversion, decide whether the value is genuinely an integer. If '196.41' is a price, a measurement or a rate, the right type is float (or Decimal for money) — forcing it through int() discards the fractional part permanently:

price = float('196.41')        # ✅ 196.41 — keep the precision you were given

# only if your application genuinely requires a whole number:
int(float('196.41'))           # 196  — truncates toward zero, .41 is GONE
round(float('196.41'))         # 196  — nearest integer, different rule

from decimal import Decimal
Decimal('196.41')              # ✅ exact, for money

The underscore row surprises people: int('1_000') returns 1000, though '_100' and '100_' both fail because an underscore may only sit between digits. For thousands separators, strip them explicitly — and if the data is locale-formatted (a comma as the decimal point, as in much of Europe) do the locale conversion deliberately rather than deleting characters and hoping.

Fix 4: it looks like a number but isn't

When the value in the message looks perfectly valid, compare its length against what you expect. The error's repr already reveals the culprit if you read the escapes:

print(repr(value), len(value))
# '42​' 3     <- three characters, not two

Which invisible characters are fatal is not what most people assume, so this is worth knowing precisely:

The BOM case is the one to watch in data pipelines, because a UTF-8 file may begin with  and only the very first field of the very first row will fail — every other row converts cleanly, which makes it look like a data problem rather than an encoding one. Read such files with encoding='utf-8-sig', which consumes the mark for you. Our CSV to JSON converter strips it automatically for the same reason.

Fix 5: when the text isn't base 10

If your string is hexadecimal, binary or octal, the fix is to tell int() the base rather than to clean the string:

int('ff')           # ❌ ValueError — 'f' is not a base-10 digit
int('ff', 16)       # 255
int('0xff', 16)     # 255  — the 0x prefix is allowed when the base matches
int('1010', 2)      # 10

int('0xff', 0)      # 255  — base 0 means "infer from the prefix"

Base 0 is the useful one for config files and user input that may arrive in any notation: it reads 0x, 0o and 0b prefixes and falls back to decimal.

Don't validate with isdigit()

This is the most commonly recommended pre-check, and it is wrong in both directions — it rejects valid input and accepts invalid input:

The only reliable test is the conversion itself:

def to_int(s, default=None):
    try:
        return int(s)
    except (ValueError, TypeError):     # TypeError catches None and non-strings
        return default

That last row is worth a thought for anything user-facing: int('٣') returns 3 because Python accepts any Unicode decimal digit, not just ASCII. If you need ASCII-only input, check explicitly rather than relying on the conversion to reject it.

ValueError or TypeError?

ValueError means the type was acceptable but the contents weren't; TypeError means the argument was never parseable to begin with. A bare except ValueError around a conversion will let a None straight through, which is why the helper above catches both. A None arriving here usually has the same origin as unsupported operand type(s) — a function that returned nothing.

Debugging checklist

• ✓ Read the quoted value as a repr — escapes in it are real characters
• ✓ Ends in : ''? Find the blank field, don't patch the conversion
• ✓ Compare len(value) against the digits you can see
• ✓ Don't add .strip() hoping it helps — int() already ignores outer whitespace
• ✓ Decimal or exponent? Go through float() first
• ✓ CSV from Excel failing on row 1 only? Read it with encoding='utf-8-sig'
• ✓ Hex or binary? Pass the base — int(s, 16) or int(s, 0)
• ✓ Never gate the conversion on isdigit(); use try/except

References

• int() (Python Standard Library)
• str.isdigit (Python Standard Library)
• PEP 515 — Underscores in Numeric Literals (Python 3.6)