Common questions about generating dummy card numbers, what Luhn validation does and does not prove, and where these numbers belong in a testing workflow. The short version: everything here is synthetic test data for exercising your own code, none of it can complete a payment, and attempting to use it for one is fraud rather than a technical challenge.

If you came here to use the tool rather than read about it, the card number generator is one click away, and the per-network pages — Visa, Mastercard, American Express, Troy — go into each format in detail.

Credit card generator FAQ

What these numbers are

No. Every number produced here is synthetic test data. It is calculated by a formula rather than issued by a bank, it is not linked to a person, an account, or a balance, and it never existed on a piece of plastic. The numbers look correct because they follow the same public structural rules an issued card follows — a network prefix, an account body, and a Luhn check digit. Following the rules of the format is all they do. Nothing on this site is derived from any real cardholder’s data, and no such data is stored here. See the disclaimer for the full statement.
Luhn-valid means the final digit of the number matches the Luhn checksum — the mod-10 formula most payment forms run in the browser to catch typing mistakes. It is a spell-check for digits, nothing more. Crucially, Luhn-valid means correctly formatted, not real. A number can pass the Luhn check and correspond to no account at any bank in the world, which is exactly the situation of every number on this site. Passing Luhn is necessary for a card number to be genuine, but nowhere near sufficient. The guides work through the algorithm step by step.
From an algorithm running in your browser. The generator picks a prefix that belongs to the card network you selected, fills the middle digits with values drawn from crypto.getRandomValues(), then calculates the final digit so the whole number satisfies the Luhn checksum. That is the entire process. The numbers are not taken from a database, a breach, a leak, or a list, because no such source is involved at any point — there is nothing to draw from. You can confirm the generation is local by opening your browser’s Network tab and generating a card: no request is made.
The prefixes follow the published IIN ranges assigned to each card network, so a generated Visa number begins with 4 and a generated Mastercard falls in 51–55 or 2221–2720, exactly as issued cards do. That is what makes them useful for testing brand detection. But the specific six- to eight-digit BIN may or may not correspond to an actual issuing bank, and everything after the prefix is random. The generator knows the network’s rules; it does not know any bank’s assignments, and it is not drawing on an issuer database.
In theory yes, in practice it is very unlikely. A 16-digit number with a six-digit prefix and a check digit leaves nine free digits, so there are on the order of a billion possibilities per prefix, and the digits come from a cryptographically secure random source rather than a seed or a counter. No uniqueness guarantee is offered, though. If your fixtures depend on distinct values — a unique database column, for instance — deduplicate after export rather than assuming. The bulk export makes that easy to check.

What they can and cannot do

No, and please do not try. For a transaction to be approved, the number has to correspond to an active account at an issuing bank, which then authorises the payment. These numbers correspond to nothing, so every payment system will decline them. Beyond that: attempting to obtain goods or services you have not paid for using card data — synthetic or otherwise — is fraud in virtually every jurisdiction, and it remains an offence even when the attempt fails. This tool exists so developers can test their own software. The terms set out prohibited uses explicitly.
No. Trial signups almost always verify the card with a small authorisation hold — often a one-unit charge that is immediately reversed — and these numbers are declined at exactly that step, because there is no issuer to approve them. There is no configuration or workaround that changes this; the number is not registered anywhere. Using card data to obtain a service you have not paid for is fraud regardless of the amount involved. If you are a developer who needs to test your own trial-signup flow, that is what your payment provider’s sandbox cards are for.
No. This is worth stating plainly because the assumption behind the question is itself mistaken: a card number never holds money. It is an identifier that points at an account held by a bank, and the balance lives in that account, not in the digits. These numbers point at no account at all, so there is no balance to speak of — not zero, but nothing. The same is true of any card number written down anywhere; the digits alone are just a reference, which is why possessing them is not the same as possessing funds.
Only up to a point. Stripe’s client-side libraries validate format and checksum, so a generated number may well pass that first layer without complaint. The moment the request reaches the server it is rejected, because the number matches nothing in Stripe’s records. Both Stripe and PayPal publish their own test cards, which are recognised in their sandboxes and return scripted approvals, declines, and 3-D Secure challenges. Use theirs to test the processor; use these to test your own form before the processor is involved.
Because a gateway does far more than run a checksum. It looks the leading digits up in its own BIN tables to identify the issuer, then routes an authorisation request to that issuer, which checks the account, the balance, and its own fraud rules before answering. A synthetic number fails at the first step — there is no issuer record to route to — so no authorisation is possible. This is not a bug or a strictness setting you can relax. It is the difference between validating a number’s shape and verifying that an account exists.
No. A CVV is computed by the issuing bank from the card number, the expiry date, and a pair of secret keys that only the issuer holds. Because those keys never leave the bank, a valid CVV cannot be derived from a card number by us, by you, or by anyone other than the issuer — which is precisely the security property it exists to provide. The three- or four-digit value shown alongside each generated number is simply a random number of the right length for the network, so your form’s length validation has something to work with.

Legality and safety

Generating synthetic numbers and using them to test your own software is a standard engineering practice — payment processors publish their own test cards for the same purpose. It is more than merely permitted: PCI DSS discourages using live cardholder data in development and test environments, which makes synthetic test data the responsible option rather than a shortcut. What is illegal is using card data of any kind — synthetic or genuine — to obtain something you have not paid for, to defeat a verification control, or to deceive someone. The tool is lawful; that use of it is not. The terms list prohibited uses.
For testing software, no. Generating test data, pasting it into your own checkout form, and committing it to your own test fixtures is ordinary development work. For attempting to pay for something, bypass an age or identity check, or get past a verification step: yes. Fraud statutes in most jurisdictions cover the attempt, not only a successful outcome, so a declined transaction is no defence. The distinction is not subtle and it does not depend on where the numbers came from — it depends entirely on what you were trying to accomplish.
No, and you do not have to take our word for it. Generation runs entirely in your browser; the page holds no server-side component that could receive a card number. To verify it yourself, open your browser’s developer tools, switch to the Network tab, and generate a card — you will see no request leave the page. Nothing to store means nothing to leak, nothing to subpoena, and nothing to sell. The privacy policy describes what the site does collect, which is ordinary web analytics and nothing to do with generated values.
Standard server request logs exist, as they do for essentially every website, and they include IP addresses. They are retained for a limited period and used for security and troubleshooting. They cannot be linked to anything you generate, for the simple reason that generated card data never reaches the server in the first place — there is no record on our side associating a request with a card number, because no card number is ever transmitted. The privacy policy covers retention, analytics, and the consent controls in full.

Technical details

It depends on the network. American Express uses 15; Mastercard, Discover, JCB, and Troy use 16; Visa permits 13, 16, and 19; Diners Club is commonly 14; and Maestro ranges from 12 to 19. ISO/IEC 7812 caps a primary account number at 19 digits overall. The practical consequence is that a validation rule of length === 16 is wrong: it rejects every Amex card and every 19-digit Maestro. Derive the expected length from the detected brand instead. The all-network generator carries the full table.
They are the same concept under different brand names. Visa calls it CVV2, Mastercard calls it CVC2, American Express and Discover call it CID, JCB calls it CAV2, and UnionPay calls it CVN2. Only two differences matter in code. Length: American Express uses four digits, everyone else uses three. Location: Amex prints it on the front of the card, to the right of the number, while the others put it on the signature panel on the back — so checkout help text saying “the three digits on the back” is wrong for every Amex customer.
A BIN, or Bank Identification Number, is the leading portion of a card number that identifies the institution that issued it. Its formal name in ISO/IEC 7812 is the IIN, or Issuer Identification Number, and the two terms are used interchangeably. It was historically six digits, but the standard was revised in 2017 to extend it to eight because the six-digit space was running out. Both lengths are in circulation, so lookup code that takes the first six digits and stops will misattribute cards issued on eight-digit IINs. The guides cover the migration.
No, and that is a deliberate design decision rather than a missing feature. Targeting a named issuer’s BIN would mean reproducing that bank’s real prefix assignments, which is a capability legitimate testing does not need and misuse very much does — it is the difference between “a number shaped like a Visa” and “a number that appears to come from this particular bank”. For testing, what you need is conformance to the network’s format, which is what the generator provides. Product tier and issuer are BIN-table facts, not properties recoverable from a generated number.
Yes. Switch the generator to its Bulk cards tab and set a quantity between 2 and 25 per run. Each result carries a card number, an expiry month and year, a security code of the correct length for its network, and a placeholder cardholder name. You can copy the batch, display it as JSON, or export it directly as CSV or JSON for use as fixtures. The limit exists because generation happens in the browser and keeps the page responsive; for a larger set, export several batches and concatenate them. The generator has the full export options.

Using this for testing

Use both, for different jobs. These numbers test your code: input masks, brand detection, length rules, security-code field sizing, checksum rejection, error states, and fixtures. They cannot test the processor, because they are registered nowhere. Your gateway’s sandbox cards test its behaviour: approvals, specific decline codes, refunds, voids, subscriptions, webhook delivery, and 3-D Secure challenges. Their weakness is that there are only a handful of them, so they are poor for exercising variety. The clean rule: unlimited synthetic numbers up to the point the request leaves your server, official test cards after it.
The list that catches the most real bugs: input masking and digit grouping, including Amex’s 4-6-5; brand detection as the user types, not on blur; length validation across 13, 15, 16, and 19 digits; security-code field length switching between three and four; Luhn rejection, by altering a final digit and confirming the form refuses it; error and empty states; PAN masking in logs, error reports, and analytics payloads; and bulk import, by exporting a CSV and running it through your fixture loader. The tool directory covers the generators for each network.

Export a batch as JSON and commit it as a fixture — synthetic numbers are safe to keep in a repository in a way that anything resembling genuine cardholder data is not. Then reference them by network:

import cards from './fixtures/test-cards.json';

test('detects the brand as the user types', async ({ page }) => {
  await page.fill('[data-test=card-number]', cards.visa);
  await expect(page.locator('[data-test=card-brand]')).toHaveText('Visa');
});

Keep one card per network in the fixture so the Amex case — 15 digits, four-digit CID — is always exercised alongside the 16-digit ones.

About this site

ccgenerator.org is built and maintained as a developer testing tool, with the reasoning behind the project — why synthetic card data matters, what the site deliberately will not do, and how it is funded — set out on the about page. The editorial policy explains how the technical content here is researched, sourced, and corrected, including the standing rule that no page on this site publishes invented statistics, ratings, or reviews, and that real cardholder data is never used or referenced.
Please do. Card network rules change, BIN ranges are reassigned, and a page that was accurate two years ago may not be today — a wrong prefix range or a broken Luhn example undermines the whole point of the site. The contact page lists the right address for technical corrections, bug reports, and everything else. The editorial policy describes how corrections are handled once received, including when a page is updated in place and when the change is noted.

Still stuck? The testing guides go deeper on card number structure and gateway sandboxes, the tool directory lists every generator on the site, and the contact page has the right address for technical questions and corrections — all three are in the footer.