Luhn Algorithm Test: Mod-10 Check Digit Guide

The Luhn algorithm test is a mod-10 checksum that runs across a string of digits and returns one of two answers: pass or fail. It was built to catch typing errors in long identification numbers, and it is still the check applied to payment card numbers, IMEI numbers on phones, and several national provider and account identifiers. A number that passes is well formed as a digit string. A number that fails has almost certainly been mistyped. A pass says nothing about whether an account exists, is open, or may be charged.

What the checksum actually verifies

The test answers a narrow question: does this digit sequence satisfy a simple arithmetic relation between all of its digits and the final digit. That final digit is called the check digit. It is calculated from the digits that precede it, so a single wrong digit, a dropped digit, or two digits swapped out of order will break the relation in nearly every case. The method is named for Hans Peter Luhn, who described it in a patent filed in the 1950s while working on number verification systems.

Two limits follow from that definition. First, the check is positional, so it catches most transpositions and single-digit mistakes but not all of them. Second, the relation is public and trivial to compute, which means anyone can generate a digit string that passes. The test is an error detector, not a security control.

How to run the test, step by step

1. Write the number out as individual digits, including the check digit at the end.
2. Start at the rightmost digit, which is the check digit, and count left.
3. Double the value of every second digit, meaning the digits in positions 2, 4, 6 and so on counting from the right.
4. If any doubled value is greater than 9, subtract 9 from it. This is the same as adding the two digits of the result together.
5. Add every digit, both the unchanged ones and the adjusted doubled ones, into a single total.
6. Divide the total by 10. A remainder of 0 means the number passes. Any other remainder means it fails.

A worked example

Take the sequence 79927398713. Reading from the right, the digits in the doubling positions are 1, 8, 3, 2 and 9. Doubling gives 2, 16, 6, 4 and 18. Two of those exceed 9, so subtract 9 to get 7 and 9. The adjusted doubled values are 2, 7, 6, 4 and 9, which sum to 28. The digits that were left alone are 3, 7, 9, 7, 9 and 7, which sum to 42. The grand total is 70, and 70 divided by 10 leaves no remainder, so the sequence passes.

Change any one digit and the total shifts away from a multiple of 10. That is the whole mechanism.

What a pass does not prove

A passing number can be invented in seconds by anyone who knows the rule. Because the check digit is derived from the preceding digits, a made-up body of digits can be completed with a correct check digit on the first attempt. The test therefore cannot distinguish a real issued number from a plausible fake. It cannot confirm that an account is active, that a line of credit exists, or that a transaction will be approved. Anyone using the test as a filter should treat it strictly as a typo screen applied before more meaningful validation.

Where the check digit appears

• Payment card numbers, where the check digit is the final digit of the primary account number described by the ISO/IEC 7812 numbering standard.
• IMEI and IMEISV identifiers on mobile devices, where the last digit of the 15-digit form is a Luhn check digit.
• National Provider Identifiers used in United States healthcare administration.
• Canadian social insurance numbers and several other national identity formats.
• Internal inventory, ticket, and account numbers in systems that need cheap typo detection.

Client-side check compared with server-side check

Running the test in the browser

• Pros: immediate feedback while the user types, fewer pointless round trips, less server load on long forms.
• Cons: trivially bypassed, easy to disable, and it cannot be trusted as a record of what the server received.

Running the test on the server

• Pros: the authoritative result, catches anything that skipped the client, and gives one place to log and handle rejects.
• Cons: adds a round trip, needs clear error messaging, and a failed check usually arrives after the user has already submitted.

Use both. Run the check in the browser to keep the form responsive, then run the same check on the server as the gate that actually decides. Keep one shared implementation so the two sides cannot drift apart.

Implementation mistakes that cause false failures

• Doubling from the left instead of from the right. The parity of every position flips, and valid numbers fail.
• Forgetting to strip spaces, hyphens, or other separators before the digits are counted.
• Doubling the check digit itself instead of starting the doubling at the second digit from the right.
• Using the raw doubled value of 16 instead of the adjusted 7, which inflates the total.
• Assuming a shorter or longer digit string is automatically invalid. Length rules come from the numbering standard, not from the checksum.

Test your implementation against a set of known-good and known-bad numbers, including one where two adjacent digits are swapped, since that is the error class the algorithm handles best.