What does a credit card number generator do?
It produces card numbers that satisfy the structural rules a payment form checks: the right length for the scheme, the right leading digits, and a final digit computed by the Luhn algorithm. That is precisely what a test suite needs, because a form that validates the format will accept these numbers and a form that does not will reveal itself.
Each scheme is generated in its own shape rather than one shape with a different prefix. A Visa is sixteen digits grouped four at a time with a three-digit code; an American Express is fifteen digits grouped 4-6-5 with a four-digit code; a Diners Club is fourteen digits. A test that only ever uses a Visa will never catch a form that hard-codes sixteen digits, which is the single commonest bug in card inputs.
These numbers are for testing and nothing else. They pass the local format checks and describe no account: no issuer will authorise a transaction against them, and they identify nobody. Using a generated number to represent a real payment, or to persuade a system or a person that a card is genuine, is fraud — and it is the reason this page states the limit before anything else rather than after.
How to generate test card numbers
- Choose the card scheme you need to test. Generating one of each is the quickest way to find a form that only handles sixteen digits.
- Set how many numbers you want, up to a hundred, which is enough to populate a fixture file for a test run.
- Leave the expiry and security-code option on if your test needs them. The expiry is dated in the future and the code is the right length for the scheme.
- Press Generate. A table appears with each number, its digit count and, if you asked for them, an expiry and a security code.
- Copy a single number, copy all the numbers as a plain list, or take the whole table as CSV for a test fixture or a spreadsheet.
- Remember what you are holding: valid in format, worthless as payment. Keep them in test data and out of anything that touches a real system.
Credit Card Generator limits and rules
| Item | Limit |
|---|---|
| Schemes | Visa, Mastercard, American Express, Discover, JCB and Diners Club |
| Lengths | Fourteen digits for Diners, fifteen for American Express, sixteen for the rest |
| Check digit | Computed by the Luhn algorithm, so the numbers pass format validation |
| Security code | Three digits, or four for American Express, which is the one that catches a bad form |
| Expiry | A month within the next four years, so a validator that checks the date does not reject the card first |
| How many | One to a hundred per press, produced by the browser's random number generator |
| Export | Copy a single number, copy the list, copy as CSV, or download a CSV file |
| Not real | No account, no issuer and no authorisation — these are test values only |
When to use it
- Testing that a checkout form accepts every scheme rather than only Visa.
- Checking that the security-code field allows four digits for American Express.
- Populating a fixture file of card numbers for an automated test suite.
- Demonstrating a payment form in a video or a workshop without using a real card.
- Verifying that a form groups digits correctly for fourteen, fifteen and sixteen-digit numbers.
Is it private?
The numbers are produced by your browser's random number generator as you watch. Nothing is sent to a server, nothing is stored, and no list of what was generated exists after the tab is closed — which also means a set you want to keep should be copied or downloaded before you navigate away.
Frequently asked questions
No. They are structurally valid and identify no account. The leading digits indicate a scheme, the middle digits are random, and the last digit is a checksum. The Luhn check is arithmetic performed locally — it proves the digits are internally consistent, not that a card exists, that it has funds or that any transaction would be authorised. Treat them exactly as you would a made-up phone number: useful for testing a form, meaningless as a fact.
It is a check digit formula, invented by Hans Peter Luhn at IBM in the 1950s, that catches a single mistyped digit and almost every swap of two adjacent digits. Starting from the right, every second digit is doubled and the digits of that result are summed with the rest; a valid number has a total divisible by ten. The final digit is chosen so that the sum works out. It is the same scheme behind the check digits on some national ID numbers and on IMEI codes, and it is why a form can reject a typo instantly without asking a server anything.
The card networks publish dedicated test ranges, and for a test that runs against a real payment gateway in sandbox mode you should use those — the gateway recognises them and returns the specific success or decline responses you are testing for. Generated numbers have a different job: checking your own form's validation, formatting and length handling, where all that matters is whether the number is the right shape. Use each for its purpose, and never send a generated number to a live gateway.
Because it is the part of the format that varies and the part a form most often gets wrong. Sixteen digits group as four blocks of four, American Express groups 4-6-5, and Diners groups 4-6-4 — so a form that assumes four blocks of four will display an Amex number with a digit stranded on its own, and a field with a fixed length of sixteen characters will reject a fourteen-digit Diners number outright. Generating one card per scheme is the fastest way to see those bugs on the screen rather than in production.
A form that only validates the format will, and a real payment processor will not. That distinction is exactly why testing with them is useful: if your own checkout accepts a generated number and tries to take payment, you have found a gap between the validation and the authorisation step that should be tested deliberately. If you use them against a live payment page belonging to someone else, or to obtain goods or services, that is card fraud, whether or not any account exists behind the number.
Generating numbers for testing is a normal software practice and the reason the card networks publish sample data themselves. What is illegal is using them to deceive — to obtain goods or services, to misrepresent a payment, or to persuade a person that a card is genuine. The numbers here contain no real account information, are generated randomly on your own device, and are intended for use in test environments. If the use you have in mind involves someone else believing a payment is real, that is the line, and it is a clear one.
Related tools
Written and maintained by Md. Nur Hossain Repon.