Skip to content

Credit Card Validator

Validate credit card number format using the Luhn algorithm and detect card type

The Math Behind Every Card Swipe

Every credit card number has a hidden checksum baked into it. It’s called the Luhn algorithm (or “mod 10”), and it was invented by Hans Peter Luhn at IBM in 1954. The idea is simple: double every second digit from the right, subtract 9 from anything over 9, add everything up. If the total is divisible by 10, the number’s structurally valid.

This catches the most common data entry mistakes — a mistyped digit, two adjacent numbers swapped. It won’t catch every possible error, but it catches the ones that happen 90%+ of the time.

This tool runs the Luhn check and also identifies the card network based on the prefix. Visa starts with 4. Mastercard uses 51-55 or 2221-2720. Amex is 34 or 37. Everything runs in your browser — no card numbers go anywhere.

How Card Prefixes Work

Card networks claimed their number ranges decades ago, and they’re standardized across the industry:

  • Visa: starts with 4, 16 digits (sometimes 13 or 19)
  • Mastercard: starts with 51-55 or 2221-2720, 16 digits
  • American Express: starts with 34 or 37, 15 digits
  • Discover: starts with 6011, 622126-622925, 644-649, or 65, 16 digits
  • JCB: starts with 3528-3589, 16 digits

When a payment form shows the card logo as you type, it’s reading these prefixes in real time. This tool does the same thing.

Why Developers Need This

You’re building a checkout form and you need to test your client-side validation. Use the standard test numbers:

  • Visa: 4111 1111 1111 1111
  • Mastercard: 5500 0000 0000 0004
  • Amex: 3400 000000 00009

These pass Luhn validation and match their network prefixes, but they’re not connected to real accounts. Stripe, PayPal, and every other payment processor publishes similar test numbers in their docs.

Change one digit in any test number and watch the Luhn check fail. That’s the whole point — catching typos before they hit your payment API and waste a request.

Beyond Payment Forms

Data cleanup. You’ve got a spreadsheet of card numbers from a legacy system migration. Some look suspicious. Run them through the Luhn check to flag mathematically invalid entries without touching a live payment system.

Compliance checks. PCI DSS audits sometimes involve verifying that card numbers stored in test databases aren’t real. Luhn validation is the first filter — but remember, passing Luhn doesn’t mean the card is real. It just means the format’s correct.

Learning the algorithm. It’s only about 10 lines of code in most languages, but seeing it work interactively clicks faster than reading pseudocode. Try a valid number, flip one digit, see it fail.

What This Doesn’t Do

A Luhn-valid number might not be attached to any real account. Payment processors check the CVV, expiration date, billing address, and run the number against their internal databases. This tool checks the math, not the bank.

Card numbers never leave your browser. But if you’re cautious (and you should be), stick to published test numbers rather than real ones. The Password Strength Meter on Toolsvu offers similar in-browser-only validation for passwords.

credit-card validator luhn security format

Related Tools

More in Security Tools