Credit Card Validator & Test Number Generator
Validate credit card numbers with the Luhn algorithm, check a whole batch at once, and generate synthetic Luhn-valid test cards for 14 brands — all in your browser, with no data sent anywhere.
Card Preview
Click on the card number line above to type — the preview updates live as you enter digits.
Validation Results
Enter a credit card number to validate
Test Card Numbers
Note: These are synthetic test numbers for validation purposes only. Never use real credit card numbers for testing.
About the Luhn Algorithm
The Luhn algorithm (also known as the "modulus 10" algorithm) is a checksum formula used to validate credit card numbers and detect simple errors in typing.
How it works:
- Starting from the rightmost digit, double every second digit
- If doubling results in a number > 9, subtract 9
- Sum all the digits
- If the total is divisible by 10, the number is valid
Brand detection here uses longest-prefix matching over published IIN ranges rather than first-match-wins regexes: a 6-digit range such as Elo's 636297 beats Maestro's broad 56-69 rule, and Discover's 622126-622925 block wins over UnionPay's generic 62.
About Credit Card Validator & Test Number Generator
A privacy-first credit-card workbench with three modes: (1) Validate — run the ISO/IEC 7812 Luhn (mod-10) checksum on a single PAN and see the detected brand, length verdict, security-code rule and a digit-by-digit MII / IIN / account-number / check-digit breakdown; (2) Generate — produce synthetic, Luhn-valid test cards for any of 14 brands (Visa, Mastercard, American Express, Discover, JCB, Diners Club, UnionPay, Maestro, Mir, RuPay, Elo, Verve, Troy, Dankort) at a chosen length, complete with a plausible expiry, security code and cardholder name; (3) Bulk check — paste a batch of numbers and get a masked table plus CSV export. Brand detection uses longest-prefix matching over published IIN ranges rather than first-match-wins regexes. Every mode runs entirely in your browser; no card number is transmitted, logged or persisted.
Why use a Credit Card Validator & Test Number Generator?
Validate to catch typos before a payment ever reaches your gateway, show the right brand logo, and apply the right security-code and length rules client-side. Generate when you need fresh test cards for QA suites, sandbox environments, fraud-screening rules or end-to-end fixtures — without copy-pasting from a stale gist or calling out to a third-party 'card generator' you cannot audit. Bulk check when you inherit a fixture file and need to know which numbers still pass. The combined tool is a complete, client-side payment-card sandbox.
Who is it for?
Built for e-commerce and fintech developers wiring up payment forms, QA engineers writing Cypress / Playwright suites against checkout flows, fraud analysts triaging declined transactions, sandbox / staging-env operators seeding test data, and security and compliance teams who need tools that don't phone home with PANs. Also useful for students learning how the Luhn algorithm and ISO/IEC 7812 issuer identification numbers actually work.
How to use the tool
Pick a mode at the top of the left panel: Validate (check one number), Generate (create synthetic test cards) or Bulk check (validate a pasted batch)
Validate: type or paste a number into the card-preview input — it groups live as you type (4-4-4-4, 4-6-5 for Amex, 4-6-4 for Diners) and a sticky chip under the card shows brand, Luhn pass/fail and digit count
Read the right-hand panel for the full verdict: brand and region, expected lengths, security-code rule, errors and warnings
Open the PAN anatomy block to see which digits are the MII, the IIN (switch between the legacy 6-digit and the current 8-digit view), the individual account number and the Luhn check digit
Generate: choose a brand (or "Any brand" for a mixed batch), pick a PAN length the brand actually issues, set how many cards you want (1–25) and click Generate — each card comes with a synthetic expiry, security code and cardholder name
Copy a single PAN with its Copy button, or use Copy all to take the whole batch as plain numbers, CSV (PAN, brand, expiry, CVC, name) or JSON straight into your fixtures
Bulk check: paste up to 500 numbers (newlines, commas or spaces), click Validate All, then export the masked results table as CSV
All processing is client-side — verify in your DevTools Network tab: typing, generating and bulk checking produce zero requests
Key Features
Validate mode — Luhn (mod-10) check
Runs the same checksum algorithm used by every payment processor — catches every single-digit typo and almost every adjacent transposition before the card is sent to a gateway.
Longest-prefix BIN matching, not first-regex-wins
Every brand declares published IIN ranges, and the longest matching prefix decides: Elo's 636297 beats Maestro's broad 56-69 rule, Discover's 622126-622925 block beats UnionPay's generic 62, and Mastercard is restricted to 51-55 and 2221-2720 rather than the whole 2-series.
Generate mode — full synthetic test cards
Produce Luhn-valid PANs at any length the brand issues (Visa 13/16/19, Amex 15, Diners 14-19 …), each with a plausible MM/YY expiry 1-5 years out, a correctly-sized security code (4 digits for Amex, 3 elsewhere) and an invented cardholder name — everything a test checkout form asks for.
Bulk check mode
Paste up to 500 numbers and get a table of masked PANs with brand, digit count, Luhn result and length verdict, plus a one-click CSV export. Numbers are masked first-6 + last-4 in both the table and the export.
PAN anatomy panel
Highlights the Major Industry Identifier, the Issuer Identification Number (toggle between the legacy 6-digit and the ISO/IEC 7812-1:2017 8-digit view), the individual account identifier and the Luhn check digit, each with a one-line explanation.
14 card brands recognised
Visa, Mastercard, American Express, Discover, JCB, Diners Club, UnionPay, Maestro, Mir, RuPay, Elo, Verve, Troy and Dankort — covering the global networks plus the domestic schemes Western validators usually miss.
Brand-aware live formatting
Grouping follows the brand detected from the digits typed so far, so an Amex number shows 3782 822463 10005 and a Diners number 3056 930902 5904 from the fifth digit onward — not only once the number is complete.
100% client-side
Validation, generation and bulk checking all run in your browser. No card number is ever transmitted, logged or persisted — verifiable in your DevTools Network tab (zero requests in every mode).
Common Use Cases
Seeding QA / E2E test data
Scenario: You're populating a Cypress / Playwright suite with a fresh batch of valid-format cards across multiple brands every test run.
✓ Generate a mixed batch in one click and copy it as CSV or JSON — PAN, brand, expiry, CVC and cardholder all land in your fixture, with no stale gist link to break months later.
Auditing an inherited fixture file
Scenario: A legacy test suite has a list of card numbers and half of them fail in the new checkout — you need to know which and why.
✓ Paste the whole list into Bulk check: the table shows brand, Luhn and length per number, masked, and exports to CSV for the ticket.
E-commerce checkout form validation
Scenario: You're building a checkout flow and need client-side validation before posting the card to your payment processor.
✓ Catch typos early, show the right brand logo from the first digits, and avoid a round-trip-then-decline that costs you the sale.
Negative-path testing
Scenario: You need to confirm your checkout handles bad input gracefully — wrong checksum, wrong length, unassigned BIN, leading zero.
✓ The test-card list includes deliberately invalid samples (including 2721…, which many validators wrongly accept as Mastercard) for negative coverage.
Fraud triage
Scenario: You're investigating a declined or charged-back transaction and want a quick read on the issuer brand and likely region.
✓ Paste the BIN-only portion and immediately see the brand, the matched range and the region cue without exposing the PAN to a third-party BIN service.
Payment-integration learning
Scenario: You're new to PCI / payments and want to understand how Luhn and IIN ranges actually work.
✓ Watch the Luhn status flip when you change one digit, and use the anatomy panel to see exactly which digits identify the network, the issuer, the account and the checksum.
14 card brands, longest-prefix IIN matching, ISO/IEC 7812-1 Luhn
100% client-side — card numbers never leave your device and are never stored
Static site — no backend dependency
Frequently Asked Questions
How do I validate a card number or generate test cards?
Pick a mode in the left panel. Validate takes one number: type or paste it into the card preview and the right panel reports brand, length, Luhn status, security-code rule, errors and warnings, plus a digit-by-digit anatomy breakdown. Generate asks for a brand (or a mixed batch), a PAN length the brand actually issues and a count of 1-25, then returns synthetic Luhn-valid cards with expiry, security code and cardholder name. Bulk check takes a pasted batch — newlines, commas or spaces — and returns a masked table with brand, Luhn and length per row plus CSV export. All three run entirely in your browser.
Are the generated numbers real, usable cards?
No. They are synthetic test PANs: they pass the Luhn checksum and start with a real-world brand prefix, but no bank ever issued them, and the expiry, security code and cardholder name are randomly invented filler for test forms. They will be accepted as 'well-formed' by client-side validation and by sandbox processors that only check format, and declined the moment they reach a real card network. Use them strictly for development, QA and teaching. If you need test data that a specific gateway will approve or decline on cue, use that processor's own published sandbox cards instead.
Does this tool send my card number anywhere?
No. Luhn checking, brand detection, length rules, the anatomy breakdown, generation and bulk validation all run in your browser as plain JavaScript. There are no API calls, no analytics events carrying the number, no logging and no localStorage persistence of anything you type — reload the page and it is gone. You can verify this in your browser's DevTools Network tab: typing, generating and bulk-checking produce zero HTTP requests. Bulk results additionally mask each number to first-6 + last-4 in both the on-screen table and the CSV export, so a shared export never carries a full PAN.
Is a card that passes validation here real, active or funded?
No. Passing means the number is mathematically well-formed: it satisfies the Luhn mod-10 checksum, its prefix falls inside a published IIN range, and its digit count matches that brand's rules. None of that proves the card was ever issued, is currently active, has available funds, or belongs to the person presenting it. Only the issuing bank can confirm that, via an authorisation request through your payment processor. Treat 'valid' here as 'not obviously a typo' — it is a pre-flight check that saves gateway round-trips and per-attempt fees, not a substitute for authorisation.
Can I use real card numbers here?
Please don't. Nothing is transmitted, but typing a live PAN into any tool you did not build yourself is a bad habit — the number ends up in clipboard history, browser autofill, screen recordings and over-the-shoulder views, and PCI-DSS scope follows the data, not the intent. Use the synthetic test PANs from Generate mode, the sample cards below the tool, or your processor's published sandbox numbers. If you must check a customer's card, do it through the merchant's actual payment form, and never log a full PAN in your own application — redact to first-6 + last-4.
What is the Luhn algorithm and what does it actually catch?
Luhn (mod-10), patented by Hans Peter Luhn in 1960 and standardised in ISO/IEC 7812-1, is the checksum every payment network uses. Starting from the rightmost digit, double every second digit, subtract 9 from any result above 9, sum everything, and a well-formed number is divisible by 10. It catches 100% of single-digit errors and almost all transpositions of adjacent digits — the two mistakes humans actually make when typing a card. It does not catch a transposition of 09 ↔ 90, and it cannot detect that a perfectly-formed number was never issued, because roughly one in ten random numbers passes by chance.
How does brand detection handle overlapping BIN ranges?
By longest-prefix matching instead of first-regex-wins. Every brand declares published IIN ranges, and the rule with the longest prefix decides: Elo's 6-digit 636297 beats Maestro's 2-digit 56-69 sweep, Discover's 622126-622925 block beats UnionPay's generic 62, and Verve's 506099-506198 range beats Maestro's 50 — so 5061… resolves to Verve. When two rules of equal length overlap genuinely, a documented precedence decides: a bare 65 goes to Discover rather than RuPay, and Maestro is always evaluated last so it only claims 5x/6x numbers no other brand matched. While you are still typing, the shortest not-yet-settled rule wins, so a lone 4 shows Visa rather than jumping to Elo.
Which brands and lengths are supported?
Visa (4; 13/16/19 digits), Mastercard (51-55 and 2221-2720; 16), American Express (34, 37; 15, 4-digit CID), Discover (6011, 622126-622925, 644-649, 65; 16-19), JCB (3528-3589; 16-19), Diners Club (300-305, 3095, 36, 38-39; 14-19), UnionPay (62; 16-19), Maestro (50, 56-69; 12-19), Mir (2200-2204; 16-19), RuPay (508, 60, 65, 6521-6522, 81, 82; 16), Elo, Verve, Troy (9792) and Dankort (5019; 16). Two frequent bugs are fixed here: the 2-series is 2221-2720 only, so 2205 and 2721 are not Mastercard, and 644-649 really is Discover. Need test bank identifiers rather than cards? Use the IBAN generator.
Technical Specifications
Supported Formats
- ✓Visa — 13, 16 or 19 digits, prefix 4
- ✓Mastercard — 16 digits, prefixes 51-55 and 2221-2720
- ✓American Express — 15 digits, prefixes 34 and 37, 4-digit CID, 4-6-5 grouping
- ✓Discover — 16-19 digits, prefixes 6011, 622126-622925, 644-649, 65
- ✓JCB — 16-19 digits, prefixes 3528-3589
- ✓Diners Club — 14-19 digits, prefixes 300-305, 3095, 36, 38-39, 4-6-4 grouping
- ✓UnionPay — 16-19 digits, prefix 62 (excluding the Discover 622126-622925 block)
- ✓Maestro — 12-19 digits, prefixes 50 and 56-69, evaluated last
- ✓Mir — 16-19 digits, prefixes 2200-2204
- ✓RuPay — 16 digits, prefixes 508, 60, 65, 6521-6522, 81, 82
- ✓Elo — 16 digits, 25 published prefix ranges (401178, 506699-506778, 636297, 650031-650033 …)
- ✓Verve — 16 or 19 digits, prefixes 506099-506198 and 650002-650027
- ✓Troy — 16 digits, prefix 9792; Dankort — 16 digits, prefix 5019
- ✓Luhn (mod-10) checksum per ISO/IEC 7812-1
- ✓Longest-prefix IIN matching with documented tie-break precedence
- ✓PAN anatomy: MII, 6- or 8-digit IIN, individual account identifier, check digit
Limits & Performance
- •File Size: Validate one card at a time; generate up to 25 per request; bulk-check up to 500 numbers per run
- •Validations: Synchronous, in-browser — typically < 1 ms per card
- •Response Time: Instant — no network round-trip in any mode
- •Browsers: All modern browsers; works offline once the page is loaded
Pro Tips
- Strip non-digit characters before validating — the tool does this automatically, but if you're embedding the same logic, remember spaces and dashes are common in pasted card numbers.
- Prefix-matching alone isn't enough at scale — always combine brand detection with the length rule and the Luhn check before treating a brand as confirmed.
- Mir, RuPay, UnionPay, Elo and Verve are commonly missed by Western validators — if you sell internationally, make sure your form recognises them or you'll silently reject valid cards.
- Don't hardcode 16 digits: Visa issues 13 and 19, Diners runs to 19 and Maestro starts at 12. Validate against the brand's allowed lengths, not a single number.
- Treat the region badge as a sanity-check signal, not an authoritative issuer lookup. A Visa card can be issued anywhere; only the domestic networks (UnionPay, RuPay, Mir, Elo, Verve, Troy, Dankort) imply a strong region.
- Never log full PANs in your application or analytics — even validation failures should be redacted to first-6 + last-4, which is what this tool's bulk export does for you.
- If you need true BIN-to-bank-and-country lookup for fraud screening, use a paid commercial BIN API — but ship it as a separate service so your validation stays client-side.
- Generated PANs are random within their brand's prefix range and re-checked against the BIN table, so a generated Visa can never come back as Elo — re-click Generate for a fresh, non-overlapping batch per test run.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.