This Luhn algorithm calculator validates any number against the mod-10 checksum used by credit cards, IMEI numbers and many ID schemes — and tells you the check digit that would make an incomplete number valid.

–

The Checksum Guarding Every Card Swipe

Hans Peter Luhn, an IBM scientist, patented this algorithm in 1954 (US Patent 2,950,048, granted 1960) to catch transcription errors mechanically — and it now rides on nearly every payment card number on Earth. The procedure is deliberately tiny: moving left from the check digit (the last digit), double every second digit, subtract 9 from any result over 9 (equivalently, sum its digits), add everything, and require the total to be a multiple of 10. The default here, 49927398716 — the classic textbook example — sums to 70: valid. Change its final digit to 7 and the sum is 71: invalid. The design goals were error-detection, not security: Luhn catches ALL single-digit errors and nearly all adjacent transpositions (the famous exception is 09 ↔ 90, which the doubling map sends to the same contribution). The check digit itself is computed by running the same machinery on the payload with the doubling phase flipped, choosing the digit that brings the total to a multiple of 10 — which this calculator also reports, so you can both validate complete numbers and complete partial ones.

Knowing what Luhn does NOT do is as important as the algorithm: it authenticates nothing. It cannot tell a real card from a fabricated one (anyone can mint Luhn-valid numbers by the billion), says nothing about whether an account exists or has funds, and is no relation to encryption. Its true habitat is the typo: fat-fingered digits at checkout, OCR misreads, a digit dropped from an IMEI (phones carry Luhn in their 15th digit), Canadian Social Insurance Numbers, and various national ID schemes. Issuer identification lives in the number's prefix (the IIN/BIN: 4 = Visa, 51–55/2221–2720 = Mastercard, 34/37 = Amex, 6 = Discover) and length (13–19 digits) — orthogonal facts a validator checks separately. The professional habit this page models: run the checksum locally, instantly, to spare a human the embarrassment of submitting a number that was never possibly right — then let the real systems do the real verifying.

Worked Examples (Verified)

  • Classic example: 49927398716 → Luhn sum 70 → VALID (check digit 6 completes payload 4992739871).
  • One digit off: 49927398717 → sum 71 → INVALID.
  • Test card pattern: 4242424242424242 → sum 80 → VALID (a form-valid, account-fictional test number).
  • Transposition catch: mistyping …8716 as …8176 changes the sum by a non-multiple of 10 → caught.

Luhn Discipline

  • Valid ≠ real: Luhn verifies internal consistency only. Never treat a pass as evidence an account exists.
  • The one blind spot: transposing 09 to 90 (or reverse) survives the check — the algorithm's only undetected adjacent swap.
  • Start doubling from the digit immediately LEFT of the check digit; beginning on the wrong parity is the classic implementation bug (it validates a complementary set of numbers).
  • Strip spaces and dashes before checking — humans group digits for readability; the algorithm counts raw digits.
  • Check digits are computed on the payload WITHOUT the check position counted — flip the doubling phase relative to validation, as the calculator's two paths show.

Related Tools

Frequently Asked Questions

How does the Luhn algorithm work?

From the rightmost digit (the check digit) moving left: leave the check digit as-is, double every second digit (subtracting 9 if the doubling exceeds 9), and sum all the digits. If the total is a multiple of 10, the number passes. For 49927398716 the total is 70 — valid. This calculator performs the check live and also computes the check digit for any payload, showing the exact digit that would complete it.

What is a check digit?

A digit appended to a number purely as an error-detection code, computed from the other digits by a fixed rule — here, chosen so the Luhn sum lands on a multiple of 10. Check digits are everywhere quiet work gets done: card numbers, IMEIs, ISBNs (a mod-11 cousin), barcodes (mod-10 variants), bank account identifiers. Their philosophy is humility: humans and scanners mistype ~1 digit in a few hundred, so numbers carry their own proofreading. The last digit of your card is not part of your account number proper — it is the account number's bodyguard.

Does a valid Luhn result mean a credit card is real?

No — emphatically. Luhn-valid means arithmetically self-consistent, a property ~10% of random digit strings have and 100% of competently faked numbers are given on purpose. It does not establish that the card exists, is active, belongs to the presenter, or has credit. Real authorization involves issuer networks, cryptographic tokens, CVV, expiry and risk systems layered far above this 1954 checksum. Use Luhn to catch typos at form-entry time — its actual job — and never as a fraud screen.

Which errors does Luhn catch and miss?

It catches every single-digit substitution (any one digit mistyped anywhere) and most adjacent transpositions (two neighboring digits swapped) — statistically the overwhelming majority of human entry errors. Its documented blind spot is the 09 ↔ 90 swap, which the doubling table maps identically; it also cannot catch two independent errors that coincidentally compensate, or jump transpositions (digits two apart) in some positions. Sibling checksums (Verhoeff, Damm) were invented to close exactly these gaps and are used where the stakes justify the complexity.

Why subtract 9 after doubling?

Because doubling a digit d (5–9) yields a two-digit number whose DIGITS sum to 2d − 9 (e.g., 7 → 14 → 1 + 4 = 5 = 14 − 9). Luhn's algorithm is digit-sum arithmetic: the "subtract 9" shortcut folds the doubled value back to a single digit identical to summing its digits. This folding is what makes the scheme sensitive to digit ORDER (transpositions change the sum) rather than merely to the multiset of digits — the property that elevates it from a simple checksum to a transposition catcher.

Where besides credit cards is Luhn used?

IMEI numbers on mobile phones (the 15th digit is a Luhn check), Canadian Social Insurance Numbers, US National Provider Identifiers for healthcare, various national identity numbers, and loyalty/account numbers in more internal systems than anyone can census. Test payment numbers published by gateways (4242…) are Luhn-valid by construction so that form validation passes during development. Anywhere a long number is typed by humans and a cheap pre-check saves a round-trip, Luhn or a near relative tends to be on duty.

How do I generate a Luhn-valid number for testing?

Take any payload (your test BIN + filler digits, one short of the target length), and append the check digit this calculator computes for it: run the payload through the "check digit" result. That yields a number that passes form validation — suitable for testing checkout flows, parsers and UI logic. Use published gateway test numbers for anything touching real payment processors, and never point generated numbers at production systems expecting them to behave like accounts: they will pass the checksum and fail everything real.

Is this Luhn algorithm calculator free?

Yes — free, instant, no sign-up. Paste any digit string for its Luhn verdict, the sum, and the check digit that completes its payload.