The Luhn algorithm calculator above applies the mod 10 checksum that sits at the end of card numbers, IMEI numbers, some national identifiers and a good many internal account schemes. It will tell you whether a number is internally consistent and, in the other mode, which final digit would make it so.
Arb Digital wants one point understood before anything else on this page: Luhn is a typo check, not validation. It was designed to catch a mistyped or misread digit at the point of entry, and it does that job well. A number that passes the Luhn test is not thereby a real account, is not active, is not in credit and is not authorised for anything. Those facts live with the issuer and can only be established by asking the issuer. This tool performs arithmetic in your browser, and arithmetic cannot know whether an account exists.
What This Luhn Calculator Does
The algorithm was devised by Hans Peter Luhn at IBM and covered by United States Patent 2,950,048, "Computer for verifying numbers", filed in January 1954 and granted in August 1960. The patent describes a hand-operated mechanical device that computes and verifies a check digit for a multi-digit number using alternating original and substitute digits with cross-addition, which is exactly the procedure a computer performs today.
In test mode the tool takes your number as complete, applies the weighting, sums, and reports whether the total is divisible by ten. In generate mode it takes the number as incomplete, computes what the final digit would have to be, and shows you the completed number. Both modes report the weighted sum and its remainder so you can follow the arithmetic rather than take the verdict on faith.
Where the number is a payment card, the check digit is the last digit of the primary account number defined in ISO/IEC 7812-1, Identification cards — Identification of issuers — Part 1: Numbering system, which is the standard that also governs the issuer identification number at the front. That standard is published by ISO and is not free to read; the check digit computation itself is the Luhn procedure described here.
How to Use It
- Pick the mode that matches your input. Testing a number that is missing its check digit will fail, and generating a check digit for a number that already has one appends a second.
- Paste the number with or without grouping. Spaces and hyphens are stripped. Letters and other characters are refused with a message naming the problem.
- Leave the working switched on the first time. Seeing each doubled digit after casting out nines is the fastest way to understand why a hand calculation disagrees.
- Read the weighted sum, not just the verdict. The remainder tells you how far the number is from consistent, which is occasionally useful when reconciling a transcription.
- Stop there. A pass means the digits are self-consistent. It is the beginning of validation, not the end of it.
The Formula: How the Checksum Works
Start from the rightmost digit and work left. Double every second digit, counting the rightmost as position one and doubling positions two, four, six and so on. If a doubled value exceeds nine, subtract nine, which is the same as adding its two digits together. Add all the resulting values, including the undoubled ones. The number passes if that total is divisible by ten.
To generate a check digit instead, run the same weighting over the number as if a zero had been appended, then take ten minus the remainder, modulo ten.
Work the default. The number 79927398713 is the standard textbook example. Removing the final 3 leaves 7992739871 as the payload. Starting from that payload's rightmost digit and doubling alternate digits gives 2, 7, 7, 9, 6, 7, 4, 9, 9, 7, where the 1 doubled to 2, the 8 doubled to 16 and became 7, the 3 doubled to 6, the 2 doubled to 4 and the leading 9 doubled to 18 and became 9. Those ten values sum to 67. Ten minus seven is three, so the check digit is 3 and the complete number is 79927398713, which the test mode confirms.
What Luhn Catches and What It Misses
It catches every single-digit error. Change any one digit of a passing number and the total shifts by an amount that is never a multiple of ten, so the check fails. That is the property it was designed for and the reason it is worth the one extra digit.
It catches almost every transposition of two adjacent digits, and there is exactly one exception: swapping 0 and 9 next to each other leaves the total unchanged. Doubling 0 gives 0 and doubling 9 gives 18 which reduces to 9, so the pair contributes 9 either way round. A number containing an adjacent 09 mistyped as 90, or the reverse, passes the check while being wrong. This is a known, published limitation rather than an obscure edge case, and it is the honest answer to "does Luhn catch everything".
It catches nothing at all about whether an account is real. It also provides no security whatsoever: the algorithm is public, computing a valid number takes microseconds, and any number of passing values can be produced at will. That is why a Luhn check belongs in a form's client-side hint, to save a user a round trip after a fat-fingered digit, and never anywhere a security decision is made.
Where Luhn Is Used Beyond Payment Cards
IMEI numbers, the fifteen-digit identifiers on mobile handsets, end in a Luhn check digit, which is why typing one wrongly into a network's lookup form is usually rejected instantly. Some national identification and health numbering schemes use it, as do many internal customer and account numbering systems where a company simply wanted a cheap guard against transcription errors in a call centre.
The reason it spread so widely is economy. It needs no lookup table, no division beyond a remainder, and it can be computed by hand in a few seconds or in a handful of machine instructions. In an era of paper forms and telephone orders that mattered enormously, and the installed base has kept it in place long after the constraint disappeared.
Other identifier families use different check digit schemes for the same reason with different trade-offs. Retail barcodes use a weighted mod 10 scheme with weights of one and three rather than Luhn's doubling, which the GTIN check digit calculator handles. ISBNs use a mod 11 scheme that catches every transposition at the cost of sometimes needing an X as a check character. The general lesson is that a check digit is a deliberate trade between the errors you want caught and the arithmetic you are prepared to do. RFC 1071, Computing the Internet Checksum, makes the same trade at the other end of the scale: it protects whole packets rather than one identifier, and it is built around properties such as being byte-order independent and incrementally updatable, because for network hardware those mattered more than catching every conceivable error.
Building It Into a Form Without Making Things Worse
The useful pattern is to run the check as the user finishes typing and, on failure, say something like "that number does not look right, please check it" rather than "invalid card". The first is accurate and helpful. The second is a claim you cannot support, because a Luhn failure means the digits are inconsistent, not that a card is invalid, and users who mistyped one digit read a hard rejection as a refusal.
Equally, never let a Luhn pass short-circuit anything downstream. It must not skip the authorisation call, must not mark an account as verified, and must not gate access to anything. The check has done its whole job the moment it has saved a user from submitting an obvious typo.
Two more practical points. Strip formatting before checking, because users paste numbers with spaces and hyphens and a naive implementation rejects perfectly good input. And do not log the number you are checking; a checksum needs the digits for a few microseconds and nothing afterwards, so anything written to a log is a liability with no compensating benefit.
Arb Digital builds free tools like this one because useful pages earn attention. If you want tools, calculators or content built for your own audience, we can help.
Browse All Free Tools Talk to Arb DigitalCommon Mistakes to Avoid
- Treating a Luhn pass as validation — it says the digits are self-consistent and nothing whatever about whether an account exists or is usable.
- Doubling from the wrong end — the weighting starts at the second digit from the right, so counting from the left gives the wrong answer on odd-length numbers.
- Forgetting to cast out nines — a doubled digit over nine must have nine subtracted, and skipping that step inflates the sum.
- Rejecting numbers containing spaces or hyphens — strip formatting first, because that is how people paste numbers.
- Assuming it catches every transposition — an adjacent 09 swapped to 90 passes unchanged, which is a documented blind spot.
Related Free Tools From Arb Digital
For the retail barcode equivalent, use the GTIN check digit calculator. The modulo calculator handles the remainder arithmetic directly, and the checksum comparator covers cryptographic digests, which detect far more and correct nothing. For error detection that can also repair, see the Hamming code calculator and the parity bit calculator, and for the distance measure underneath them the Hamming distance calculator. The number base converter is there when identifiers arrive in another radix. Browse everything else in the free online tools hub.
Frequently Asked Questions
No. It means the digits are internally consistent with their own check digit. It says nothing about whether the account exists, is open, has funds or is authorised for a transaction. Only the issuer can answer those questions, and only through the payment network.
Every single-digit error, and almost every transposition of two adjacent digits. It was designed for exactly the mistakes people make when reading a number aloud or typing it from a card, which is why it has survived so long in so many numbering schemes.
Yes, one well-known case. Swapping an adjacent 0 and 9 leaves the total unchanged, because a doubled 0 contributes nothing and a doubled 9 reduces back to 9. A number with 09 mistyped as 90 passes the check while being wrong.
Because giving alternate positions different weights is what makes the checksum sensitive to order. If every digit were weighted equally, swapping two digits would leave the sum identical and the check would catch no transpositions at all.
None. The algorithm is public and computing a passing number takes microseconds, so a Luhn check stops honest typos and no adversary at all. It belongs in form validation as a convenience and never anywhere a security decision is made.
IMEI numbers on mobile handsets, several national identification and health numbering schemes, and a large number of internal account and customer numbering systems that wanted a cheap guard against transcription errors.
Almost always one of two things. Either the doubling started from the wrong end, since the weighting begins at the second digit from the right, or a doubled value over nine was added as-is instead of having nine subtracted from it.
A checksum needs the digits only for the moment of the calculation. Nothing about running a Luhn check creates a reason to log or retain the number, and anything written to a log becomes a liability with no compensating benefit.
This tool performs a checksum calculation only. It is not payment, financial or compliance advice, it does not verify that any account exists or is authorised, and it must not be used to assess the legitimacy of a payment instrument. Handling of payment card data is governed by your acquirer, the card schemes and applicable law, and those obligations sit with you.
