Free Luhn Checker for Test Card Numbers - Brand Guess, No Storage

A credit card validator on this site is a Luhn checksum checker plus a coarse IIN/BIN brand guess. Payment-card numbers include a check digit defined by ISO/IEC 7812, commonly called the Luhn algorithm. Double every second digit from the right, subtract 9 when the product exceeds 9, and require the sum to be divisible by 10. The default 4111111111111111 is a widely published Visa test PAN. It passes Luhn. Prefix 4 and length 16 classify it as Visa. That is the worked check.

The number is not stored, not logged, and not sent to a processor. This site cannot take payment. Brand detection uses IIN prefixes: Visa 4; Mastercard 51–55 and 2221–2720; American Express 34/37; Discover 6011/65/644–649. Co-branded and regional ranges can be wrong. Length is checked against common brand lengths. None of that proves the account exists, has funds, or is authorized.

This page will not generate card numbers, enumerate BINs, or help anyone test stolen cards. If that is the job you had in mind, stop. Use only published test PANs from your payment provider's documentation.

Format checking a published test number takes under a minute:

1. Keep or paste a published test PAN - The default is the well-known Visa test number 4111111111111111. Use only test numbers from your payment provider documentation.
2. Read Luhn and brand - That number passes Luhn and is classified as Visa by prefix 4 and length 16. Length outside 12–19 digits is rejected as a format check.
3. Copy the masked report - Copy if you need a note. The result shows a masked PAN. The full number is never written to localStorage.
4. Do not charge or generate - This page cannot take payment and will not generate card numbers. A passing checksum is not proof an account exists.

The default field is the published Visa test number used across payment-provider docs. Spaces are stripped; only digits are checked.

4111111111111111

Masked: ••••••••••••1111
Length: 16
Luhn checksum: pass
Brand guess: Visa
Format check only. Not a payment, not stored, not proof the account exists.

From the right: digits 1,1,1,1,1,1,1,1. Alternating double starts on the second-from-right digit. After the Luhn fold, the sum is divisible by 10, so the check digit is consistent. Prefix 4 with length 16 is the Visa guess. Changing the last digit to 0 typically fails Luhn - that is a typo catch, not a bank decline.

Search results mix three products. Only the first column is this page:

The general rule: checksum for typos, gateway for money, never generate PANs on this origin.

After digits are isolated, the page runs a Luhn checksum and a small brand-prefix table. Visa expects a leading 4 and length 13, 16, or 19. Mastercard expects 16 digits in 51–55 or 2221–2720. American Express expects 15 digits starting 34 or 37. Discover expects 16 digits in 6011, 65, or 644–649. Anything else is Unknown. That list is intentionally small. It is not a complete BIN table and will not be expanded into a generator.

Length outside 12–19 is rejected before Luhn. Spaces and punctuation are stripped so a typed 4111 1111 1111 1111 still matches the default digits. Copy always writes the masked report, never the raw field, so a clipboard dump is less likely to look like a live PAN.

Start at the rightmost digit (the check digit) and move left. Do not double the check digit; double every other digit after that. For the published Visa test PAN the digits are sixteen ones after the leading 4. After doubling, any value above 9 is reduced by 9 (equivalently, add the two digits of the product). Sum everything. If the total modulo 10 is 0, Luhn passes. That is the entire algorithm this page runs. It is public, old, and intentionally weak: it was built for transcription errors, not for cryptography and not for proving an issuer will honor a charge.

A failing last digit is the usual classroom demo: keep the documented prefix and length, change only the check digit, and watch the report switch from pass to fail. That still does not mint a new card. It shows why a checkout form can reject a typo before a network call. Test suites at Stripe, Braintree, Adyen, and similar processors publish their own PANs for decline codes, 3-D Secure, and brand mix. Copy those from the vendor doc. Do not ask this page to invent a passing number for a BIN you typed. The code path from input to luhnValid is one-way.

IIN (issuer identification number), still often called BIN, is the leading six or eight digits that used to map to an issuer. This tool does not query a BIN list. It only pattern-matches a handful of brand prefixes plus length. Visa's leading 4 is the reason the default is classified Visa. Mastercard's 2221–2720 range exists because ISO expanded the brand beyond 51–55. American Express 34/37 with 15 digits is the other common classroom case. Discover's 6011/65/644–649 set is incomplete compared with a commercial BIN database. Unknown means "not in this small table," not "invalid card."

CVV, expiry, name, AVS, 3-D Secure, and network tokens are out of scope. Entering them here would be a mistake even for test data. The input is a single numeric field. The output is masked digits, a boolean checksum, a brand string, and a length. If your job needs an authorization, you need a gateway and a sandbox key you control - not a static HTML page.

PCI DSS is a program for people who store, process, or transmit cardholder data. This origin is a static developer utility. It does not tokenize, vault, or charge. Treating a Luhn pass as "the card is good" is how toy checkouts leak. Your integration tests should use the processor's published PANs and their test keys, then assert on the processor's response codes. This page only answers: are these digits the right length, does Luhn hold, and which of four brand prefixes matches. That is useful the day you write a onBlur formatter. It is useless the day you try to cash out.

Masking shows bullets plus the last four so a screenshot can be discussed in a ticket without dumping the full test PAN. Copy writes that masked report, not the input. Clear restores 4111111111111111 instead of emptying the field so the worked check stays one click away. Width of the split is the only localStorage write, under credit-card-validator-panel-width. If you paste a number and refresh, the field returns to the Visa test default - by design, not a bug.

Other tools on this site remember drafts for 30 days in localStorage. Card numbers are excluded. The PAN is never written to disk. Clearing the field drops the digits from memory. Do not paste live customer cards into a browser origin you do not control - including this one. PCI-ish hygiene still applies to test tools.

Panel width may be stored under credit-card-validator-panel-width. That is a layout preference, not a card number. The split track class credit-card-validator-split-track is unique so resize does not collide with other workbenches.