How the Luhn Algorithm Catches a Mistyped Card Number

Type a sixteen-digit card number into any checkout form and something quietly checks it before the request ever leaves your browser. That something is almost always the Luhn algorithm, a mod-10 checksum invented by IBM engineer Hans Peter Luhn in 1954 and patented in 1960. It does not know whether a card exists or has money behind it. What it does, cheaply and offline, is catch the everyday slips: a digit fat-fingered into the wrong key, or two adjacent digits accidentally swapped. That single job is why the same formula sits behind credit and debit cards, mobile IMEI serials, some national ID numbers, and a long tail of account identifiers.

What a checksum actually buys you

A checksum is a small amount of extra information baked into a number so the number can vouch for itself. With Luhn, the last digit is not part of the "real" value at all. It is a check digit, computed from the digits in front of it so that the whole string obeys a fixed rule. When you later type the number back in, the rule either holds or it does not. If it does not, you know something was entered wrong, and you know it instantly, with no database lookup and no network call.

That offline property is the whole appeal. A card form running on a flaky mobile connection can reject 4539 1488 0343 6468 the moment the field loses focus, because the digits do not add up, rather than firing off a doomed payment request. The Luhn check is a few additions. It costs nothing and it stops a large share of typos before they waste anyone's time.

The doubling rule, step by step

Here is the exact procedure. The one rule worth memorizing: the Luhn check doubles every second digit counting from the right (subtracting 9 from any result over 9), sums all the digits, and a valid number's total is a multiple of 10.

Walk it slowly:

Write the number out and start from the rightmost digit.
Leave that rightmost digit alone. Double the next one to its left. Leave the one after that. Double the next. Keep alternating all the way to the front.
Every time a doubled digit comes out as two digits (anything from 10 to 18), replace it with the sum of its digits, which is the same as subtracting 9. So 6 doubled is 12, which becomes 3. An 8 doubled is 16, which becomes 7.
Add every resulting number together, including the digits you never touched.
If that grand total divides evenly by 10, the number passes. If it does not, it fails.

The "subtract 9" shortcut trips up nearly everyone writing Luhn by hand the first time. Doubling 8 does not give you 16 in this sum, it gives you 7. Skip that reduction and a perfectly valid number will read as broken.

A number you can check on paper

Take the classic teaching example, 79927398713. From the right, the final 3 stays as is, the 1 is left alone too, and we double every second digit moving leftward.

| Digit | 7 | 9 | 9 | 2 | 7 | 3 | 9 | 8 | 7 | 1 | 3 | |-------|---|---|---|---|---|---|---|---|---|---|---| | Double? | x | | x | | x | | x | | x | | (check) | | After doubling | 14→5 | 9 | 18→9 | 2 | 14→5 | 3 | 18→9 | 8 | 14→5 | 1 | 3 |

Now add the bottom row: 5 + 9 + 9 + 2 + 5 + 3 + 9 + 8 + 5 + 1 + 3 = 70. Seventy divides cleanly by 10, so 79927398713 is valid.

Change only the last digit to make 79927398710 and the sum drops to 67, which is not a multiple of 10, so it fails. That is the check digit doing its job: for the body 7992739871, the one digit that makes the total land on a clean multiple of ten is 3, and nothing else will do. If you would rather not push a pencil, paste either string into the Luhn validator and the trace panel lays out every doubling and the running sum so you can see exactly where 79927398710 goes wrong.

Why one wrong digit, and most swaps, never slip through

The reason Luhn is worth using comes down to two guarantees. First, it catches any single-digit error. Change one digit anywhere in a valid number and the sum shifts by an amount that can never be a multiple of 10, so the total stops dividing evenly and the check fails. There is no way to mistype a single position and still pass.

Second, it catches most adjacent transpositions, the very common slip of swapping two neighboring digits. Because alternate positions are weighted differently (one doubled, one not), swapping two neighbors usually changes the sum, so ...12... typed as ...21... is flagged. The one blind spot is the pair 0 and 9: swapping a neighboring 09 and 90 leaves the weighted sum unchanged, so Luhn cannot catch that specific transposition. It is the famous exception, and it is rare enough that the algorithm still earns its keep.

What Luhn does not do is prove the number is real. A made-up sixteen-digit string has roughly a one-in-ten chance of passing by sheer luck, because only the final digit has to cooperate. A pass means "could have been typed correctly," never "this is a working card." Real validation still belongs to the issuing bank or a payment processor.

Where I reach for it

I keep coming back to Luhn for one unglamorous reason: it turns a vague failure into a yes-or-no. The last time a teammate swore a card "just stopped working" at checkout, I pasted the number into the validator before touching the gateway. It failed Luhn. The card was fine; a transposed digit in the form was not. That ruled out an entire afternoon of poking at the payment integration in about two seconds. The same trick works for an IMEI half-read off a scuffed sticker, where a fail tells you to re-read the smudged digit instead of chasing a phantom bug downstream.

When I need fixtures, I flip the same tool into check-digit mode: give it a body, get the digit that completes a passing number, and drop card-shaped values into the test suite that clear front-end validation without ever touching a live account. If you want a batch of those ready-made, the credit card test number generator hands you Luhn-valid samples by scheme, which pairs neatly with the validator for round-trip testing.

The short version

The Luhn algorithm is a 70-year-old trick that still guards almost every card field you will ever fill in. Double every second digit from the right, knock 9 off anything over 9, sum the lot, and check whether the total is a multiple of 10. A valid number always lands on a clean multiple; one wrong digit never will, and neither will most swapped pairs. Just remember the boundary: it catches typos, not lies. A number that passes is shaped right, nothing more, and the only thing that confirms a real, funded account is the bank on the other end.

Made by Toolora · Updated 2026-06-13