Credit Card Number Generator for Testing

This credit card number generator produces Luhn-valid dummy numbers across every card network the site supports, in one place. If you need a single brand, the network pages linked below are narrower; this page is the full reference — every prefix range, every length rule, and what each part of a card number actually encodes.

How to generate test card numbers

1. Choose single or bulk mode. The Single card tab returns one number at a time. The Bulk cards tab produces a batch in one run.
2. Pick a card network. Visa, Mastercard, Amex, Troy, Discover, JCB, Diners Club, or Maestro. In bulk mode, All draws from every network and Mixed uses the four most commonly tested — Visa, Mastercard, Amex, and Troy.
3. Set how many numbers you need. Bulk mode accepts a quantity between 2 and 25.
4. Generate. Each result carries a card number, an expiry month and year, a CVV or CVC of the correct length for that network, and a placeholder cardholder name.
5. Copy or export. Copy one number, use Copy all for the batch, or take the whole set out with Export CSV or Export JSON.

Card number formats by network

This table is the published specification for each network, not a description of what this page emits — see the note underneath.

* UnionPay is the exception worth knowing about. Cards issued on some UnionPay BIN ranges do not carry a Luhn-valid check digit, so a validator that rejects every non-Luhn number will refuse legitimate UnionPay cards. If you accept UnionPay, treat the Luhn test as advisory for 62 and 81 rather than as a hard gate.

What this generator emits. Where a network permits several lengths, the tool picks the one in general circulation: 16 digits for Visa, Mastercard, Discover, JCB, and Troy, 15 for American Express, 14 for Diners Club, and 16 or 19 for Maestro. UnionPay is documented here for reference but is not one of the picker’s options. If you need to exercise the rarer lengths — 13-digit Visa, 19-digit Discover — construct those by hand; the checksum calculation is the same.

Each network also has its own page, which is the faster route when a test needs one brand: Visa, Mastercard, American Express, and Troy. Discover, JCB, Diners Club, Maestro and UnionPay have their own pages too, each covering the quirk that makes that network break code — the tool directory lists all nine.

What each part of a card number means

A card number is not an opaque blob of digits. It decomposes into four fields, and knowing which is which is what lets you write BIN routing that behaves:

4  5  3  9  1  4    8  8  0  3  4  3  6  5  7    4
└──────┬────────┘   └───────────┬────────────┘   └┬┘
       │                        │                 │
       │                        │                 └── Check digit (Luhn)
       │                        └──────────────────── Individual Account Identifier
       └───────────────────────────────────────────── IIN / BIN (first 6–8 digits)
 ↑
 └─ MII (Major Industry Identifier), the first digit

MII — Major Industry Identifier. The first digit alone tells you the issuing industry: 3 is travel and entertainment (Amex, Diners, JCB), 4 and 5 are banking and finance (Visa, Mastercard), 6 is merchandising and banking (Discover, Maestro, UnionPay). It is the coarsest possible classification and never sufficient on its own.

IIN / BIN — Issuer Identification Number. Historically the first six digits, identifying the institution that issued the card. Under ISO/IEC 7812-1:2017 the IIN was extended to eight digits, because the six-digit space ran out. Both lengths are in circulation. Lookup code that slices number.substring(0, 6) and stops there will misattribute cards issued on eight-digit IINs — a live source of routing bugs.

Individual Account Identifier. Everything between the IIN and the final digit, identifying the specific account at that issuer. Its length is whatever the total length leaves over, which is why it varies from card to card.

Check digit. The last digit, computed with the Luhn algorithm over everything before it.

For the field-by-field detail see the guide to card number structure and the BIN and IIN reference.

The Luhn algorithm

The Luhn checksum, standardised in ISO/IEC 7812-1 annex B, catches single-digit typos and most adjacent transpositions. Working right to left, double every second digit, subtract 9 from any result above 9, sum everything, and a valid number sums to a multiple of 10.

For 4539 1488 0343 6574 the digits sum to 80, which is divisible by 10, so the number passes. Here is the check as code:

function isLuhnValid(number) {
  const digits = number.replace(/\D/g, '').split('').reverse().map(Number);
  const sum = digits.reduce((acc, d, i) => {
    if (i % 2 === 0) return acc + d;
    const doubled = d * 2;
    return acc + (doubled > 9 ? doubled - 9 : doubled);
  }, 0);
  return sum % 10 === 0;
}

isLuhnValid('4539 1488 0343 6574'); // true  — spaces are stripped
isLuhnValid('4539 1488 0343 6575'); // false — check digit tampered
isLuhnValid('3056 930902 5904');    // true  — 14-digit Diners Club

The i % 2 === 0 test is where most hand-rolled implementations go wrong: after reversing, index 0 is the check digit itself and must not be doubled. Double the wrong alternating set and half of all valid numbers will fail. The full walkthrough, including the check-digit calculation lives in the guides.

Testing scenarios this tool covers

Input formatting. American Express groups as 4-6-5 over 15 digits; almost everything else is 4-4-4-4 over 16. Generate one of each and confirm your mask switches rather than forcing four-digit groups onto a 15-digit number.

Brand detection. The logo should change off the first one to four digits, as the user types. Mastercard’s 2221–2720 range is the usual failure: detection written before 2017 only recognises 51–55.

CVV field length. Four digits on Amex, three everywhere else. This is among the most frequently missed cases, and it is immediately visible to users when wrong.

Length validation. Accept the full 12–19 range rather than hard-coding 16. A 19-digit Maestro number such as 5018 1234 5678 9012 344 is valid and will be rejected by a length === 16 check.

Luhn rejection. Take any generated number, change the last digit, and confirm the form rejects it. A form that accepts both is not running the checksum at all.

Bulk data. Export 25 rows as CSV and run them through a database import or a fixture loader to check column mapping, encoding, and how leading zeros in the expiry month survive the round trip.

PAN masking. Confirm that logs, error reports, and analytics payloads show only the last four digits. PCI DSS Requirement 3.3 covers masking of the primary account number when displayed; testing it with synthetic data keeps genuine card data out of the exercise entirely.

Bulk generation and export

Bulk mode returns between 2 and 25 cards per run. Export CSV writes one row per card with these columns:

Card type, Card number, Expiration month, Expiration year, CVV/CVC, Cardholder name, Status

Export JSON writes the same records as an array of objects, which is usually the more convenient shape to drop straight into a fixtures file. Show JSON displays the payload in the page first if you just want to copy a fragment.

Cardholder names are obvious placeholders — Alex Tester, Jordan Example, Taylor Sandbox and similar — chosen so that a name from this tool can never be mistaken for a real person’s in a bug report or a screenshot. For larger fixture sets, the bulk generator produces up to ten thousand records at a time, with reproducible seeds and a configurable share of deliberately invalid rows.

Limitations — what this tool does not do

Being precise about this matters more than the feature list:

• It does not validate against real BIN tables. A generated prefix obeys its network’s published rules, but the specific BIN may belong to no issuer at all.
• It does not simulate payment processor behaviour. No authorisation, no approval code, no decline reason. Nothing is submitted anywhere.
• It does not produce 3-D Secure or SCA flows. Those require a gateway that recognises the number and a directory server that will respond to it.
• It cannot tell you whether a card exists. No offline tool can. Existence is a fact held in an issuer’s database, not a property recoverable from the digits.

When your test needs the processor’s behaviour rather than your own code’s, switch to your gateway’s published sandbox cards — Stripe and PayPal both document theirs in full, and we collect the equivalents on the test card numbers reference. The FAQ covers what a Luhn-valid number does and does not prove.