Credit Card Validator (Luhn + Brand)

Card numbers (PAN) embed a brand-specific Issuer Identification Number, an account number, and a final Luhn check digit. This tool: (1) detects brand from leading digits (Visa, Mastercard, Amex, Discover, JCB, Diners, UnionPay, Maestro), (2) checks the length matches that brand's spec, (3) runs the Luhn mod-10 checksum. Useful for client-side form validation — catches typos and obvious fakes before the payment processor sees them.

Luhn catches the mistakes people actually make, which is what it was designed for in the 1950s. Every single-digit error fails the check, and so does almost every transposition of two adjacent digits, the two commonest ways a number gets typed wrong. The exception is worth knowing: swapping 09 for 90 passes, because the doubling step maps both to the same value. That is the one transposition Luhn cannot see.

What the check cannot tell you is whether the card exists. Roughly one in ten random numbers of the right length passes Luhn by chance, so a number can be brand-correct, length-correct and checksum-valid while belonging to no account anywhere. Only an authorisation against the issuer answers that, and nothing running in a browser can. Treat a pass as evidence of no typo and nothing more.

The brand prefixes move. Issuer Identification Numbers are allocated and reallocated, ranges get added, and a table baked into client code drifts out of date rather than failing loudly: the symptom is a legitimate new card reported as an unknown brand. Refusing a payment on that basis turns a stale table into lost revenue, which is why brand detection belongs in the interface and never in the decision.

A card number is regulated data. PCI DSS governs storing or transmitting a PAN, which is why this runs entirely in the page and sends nothing, and it is also why a real form should hand the number to a processor's hosted field rather than to your own server.