The Luhn test answers one narrow question: did a string of digits survive a typo? It is a checksum, not an authorization, not proof of validity, and not a security control. If you are comparing validation tools, treat the Luhn check as the first filter in a longer chain, and never as evidence that a number is issued, active, or tied to the person typing it.
How the Luhn algorithm works
The routine is also called the mod 10 check. Start at the rightmost digit and move left. Double the value of every second digit. When a doubled value reaches 10 or more, subtract 9 from it, which is the same as adding the two digits of the result. Add all the digits together. If the total divides by 10 with no remainder, the number passes.
Take 79927398713. Doubling every second digit from the right and reducing the large results gives a total of 70. That divides by 10, so the number passes. Change any single digit and the total lands off a multiple of ten, which is the property that catches most typed and transcribed mistakes.
What a passing result does and does not prove
- Catches: every single-digit error, and most swaps of two adjacent digits.
- Misses: transpositions where the swapped digits sit nine apart, such as 09 and 90, because the doubled values still sum to the same total.
- Does not prove: that an issuer exists, that an account is open, that funds are available, or that the number belongs to the person submitting it.
- Does not replace: expiry checks, card verification value checks, address verification, or an authorization request to the issuer.
Where Luhn checks appear
Payment card numbers carry a check digit computed this way under ISO/IEC 7812. IMEI numbers on mobile devices use the same formula. Several national identifier schemes, along with many gift card and loyalty programs, use mod 10 for the same purpose.
What to look for when you pick a validator
- Input handling: strip spaces, hyphens, and stray whitespace before the arithmetic, and keep the original string for display.
- Length bands: payment card numbers run 12 to 19 digits under ISO/IEC 7812, and an IMEI is 15 digits. Reject lengths outside the supported band before you run the checksum.
- Distinct results: return a reason code that separates a failed checksum from an unsupported length or a character set error.
- Prefix range check: pair the checksum with an issuer identification number range test so a random passing string does not slip through.
- Local execution: the check needs no network call, so a validator that contacts a server or logs a full number adds risk with no benefit.
- Data handling: keep full card numbers out of logs, and follow PCI DSS rules on storage if you touch card data.
Common pitfalls
- Treating a pass as authorization. A check digit is simple arithmetic, so Luhn-valid lists are easy to fabricate.
- Assuming the check catches all typos. It does not catch transpositions of digits nine apart, and it misses many two-digit errors that offset each other.
- Running the check on alphanumeric identifiers. The formula works on digits, so letters must be mapped or excluded first.
- Skipping normalization. A trailing newline or a stray space fails a naive check and marks a good number invalid.
- Using the checksum as a fraud signal. It carries no information about ownership, behavior, or account status.
FAQ
Is a Luhn-valid number a real card number?
No. The check digit confirms arithmetic consistency only. Test suites are full of numbers that pass and belong to no one.
Can the Luhn check run offline?
Yes. It is a short arithmetic routine with no dependency on an issuer or a network.
Does Luhn replace a card verification value check?
No. A CVV check happens at the issuer during authorization. Luhn is a local format test and cannot confirm anything about the account behind the number.
How many digits should a validator accept?
Accept 12 to 19 for payment cards, and match the length band to the identifier type you handle. A fixed 16-digit rule rejects valid 19-digit numbers and newer ranges.