ValueError: Invalid Literal for int() in Python — Causes and Fixes

You ask the user for a number, they type something perfectly reasonable, and Python crashes with ValueError: invalid literal for int() with base 10. This error appears in nearly every beginner program that reads input, because int() is much stricter than people expect. It accepts whole numbers written plainly, and nothing else: no decimal points, no commas, no words, no empty text. This guide shows exactly which inputs break int(), and the robust patterns for converting user input safely.

Quick Answer

The error means the string you passed to int() is not a plain whole number. Inputs like "3.5", "12a", "1,000", or an empty string all trigger it. Fix it by using float() when decimals are possible (then convert with int(float(text)) if you truly need a whole number), stripping spaces with .strip(), and wrapping the conversion in a try/except ValueError block so bad input gets a friendly message instead of a crash.

What int() Will and Will Not Accept

int() converts a string to an integer only if the string is an optional sign followed by digits. int("42") works, int("-7") works, and surrounding spaces are tolerated, so int(" 42 ") works too. Everything else fails:

• int("3.5") fails — the decimal point is not allowed, even though 3.5 is obviously numeric.
• int("") fails — the user pressed Enter without typing anything.
• int("ten") fails — number words are not digits.
• int("1,000") fails — thousands separators are not allowed.
• int("42 years") fails — extra text after the digits breaks it.

The message with base 10 simply means Python interpreted the string as a base-10 number, which is the ordinary decimal system. It is a clue about how the conversion was attempted, not a second problem. You can read the exact conversion rules in the official documentation for the int() built-in.

The Most Common Scenario: Converting input()

input() always returns a string, so a conversion is unavoidable, and user input is never as tidy as developers hope. Here is the fragile beginner version:

age = int(input("Enter your age: "))

Type 25 and it works. Type 25.5, twenty-five, or just press Enter, and the program dies. Real users do all three within the first minute. Our guide on reading user input as a number instead of a string builds this up into a reusable pattern you can paste into any project.

The Robust Fix: try/except With a Retry Loop

1. Wrap the conversion: put int(...) inside a try block and catch ValueError specifically.
2. Ask again instead of crashing: place the whole thing in a while True loop that only exits with break after a successful conversion.
3. Give a helpful message: tell the user what went wrong and what format you expect.

while True:
    text = input("Enter your age: ")
    try:
        age = int(text)
        break
    except ValueError:
        print("Please type a whole number, like 25.")

This pattern never crashes on bad typing, and it is the standard shape of input handling in real Python programs.

When Decimals Are Legitimate Input

If the value can naturally be fractional, such as a price, weight, or measurement, use float() as the primary conversion. float("3.5") works, and float("42") also works, returning 42.0. If you later need a whole number, int(float("3.9")) gives 3 by discarding the fraction. Be aware that this truncates rather than rounds; use round(float("3.9")) if you want 4. Choosing deliberately between truncation and rounding saves subtle bugs in money and scoring code.

Checking the String Before Converting

Another approach is to test the text first. text.isdigit() confirms a string of digits, but it rejects negative numbers and decimals, so it suits only simple cases like ages or menu choices. For anything richer, the try/except approach is more honest: attempt the conversion and handle failure. Python’s own philosophy, often called EAFP (easier to ask forgiveness than permission), favours exactly this try-first style.

Common Mistakes to Avoid

• Assuming users type exactly what the prompt shows. They add spaces, units, currency symbols, and words. Design for messy input from the start.
• Catching every exception with a bare except. Catch ValueError specifically, so genuine bugs elsewhere in the block are not silently hidden.
• Using int() on the result of a calculation that produced a float string. Values formatted with str() from floats carry decimal points. Convert the float itself, not its text.
• Forgetting that int() also fails on None. If the value came from a function that sometimes returns None, check for that before converting, or you will meet a TypeError instead. This pairs with the NoneType AttributeError family of beginner bugs.

The Same Error Inside Files and Data

Interactive input is only the first place this error lives. The identical ValueError appears when your code converts strings that came from a file: a CSV column of quantities, a configuration value, a score saved by another program. File data is even less trustworthy than typing, because nobody watches it being written. A stray header row, an empty cell, or a value saved as 1,200 will crash a naive conversion halfway through a thousand-row file, leaving you unsure which rows were processed.

The robust approach for data is to convert defensively and collect the failures rather than die on the first one. Loop over the values, attempt each conversion inside try/except ValueError, and append bad entries — with their row number or position — to a problems list you can print at the end. The program then processes everything valid and reports exactly which lines need human attention. This pattern also gives you a natural place to apply the small clean-ups real data needs: stripping spaces, removing thousands separators, and treating empty strings as zero or skipping them, according to rules you choose deliberately rather than by accident. When you later load the same data with a library like pandas, you will find the same philosophy built in: conversion tools there offer an “errors” option precisely because messy numeric text is the normal state of real-world files.

Conclusion

ValueError: invalid literal for int() means the text you handed to int() was not a plain whole number. Decide whether your data allows decimals, use float() when it does, and always wrap interactive conversions in try/except ValueError with a friendly retry. Your program will then survive anything a user can type.

Frequently Asked Questions

Why does int(“3.0”) fail if 3.0 is basically 3?

Because int() parses the characters, not the mathematical value. The string "3.0" contains a decimal point, which is not a digit or a sign, so parsing fails. Convert in two steps: int(float("3.0")) works and gives 3.

How do I accept numbers with commas like 1,000?

Remove the separators before converting: int("1,000".replace(",", "")) gives 1000. Do this only when you are sure commas are grouping separators; in some locales a comma is the decimal mark, and stripping it would change the value.

What is the difference between ValueError and TypeError here?

ValueError means the type was right (a string) but the content was wrong (not a number). TypeError means the type itself was wrong, for example passing None or a list to int(). The distinction tells you whether to fix the data or fix where the data came from.

Can int() convert strings like “0x1F”?

Not with the default base 10. That string is hexadecimal. int("0x1F", 16) or int("0x1F", 0) handles it by telling Python which base to use. This is also where the “base 10” part of the error message becomes meaningful.

Why does int() accept ” 42 ” but not “42 ” with other text?

Python deliberately tolerates leading and trailing whitespace, including spaces, tabs, and newlines, because values copied from files and forms so often carry them. That courtesy extends only to whitespace. A trailing unit, letter, or punctuation mark is treated as part of the would-be number and fails. If your data routinely carries such extras, clean them deliberately with .strip() plus targeted replacements before converting, rather than hoping the parser will be lenient.

How do I stop the program from crashing while I test?

During development, the try/except pattern is the real fix. If you are debugging someone else’s script, read the traceback: it shows the exact line and, combined with printing the variable just before conversion, reveals the offending string immediately.