CC Generator — Luhn-Valid Credit Card Generator

CC Generator is a credit card generator — a CC generator, in the shorthand most developers use — and it builds each number the way a genuine one is structured: a network prefix, a randomised account body, and a Luhn check digit calculated over both. That is enough to satisfy the validation layer in your own checkout. It is deliberately not enough to satisfy anyone’s payment network, and the sections below set out exactly where that line falls.

Supported card networks

Every payment network owns specific Issuer Identification Number (IIN) ranges, allocated under ISO/IEC 7812, the standard that defines how identification card numbers are structured. Those ranges are what lets a checkout form display a Visa logo the moment you type a 4.

The picker above covers eight of these nine networks; UnionPay is documented here for reference but is not yet one of the generator’s options. Dedicated pages give you one network at a time: Visa, Mastercard, American Express, and Troy. The all-network credit card generator mixes them in a single run, and the tool directory lists everything else on the site.

Note the two Mastercard ranges. The 2221–2720 block was added in 2017 when the original 51–55 space ran short, and brand-detection code written before then still misclassifies it. If your card-type detection has a bug, that range is the first place to look.

How this credit card generator works

Choosing a network prefix

The generator selects a prefix that genuinely belongs to the network you picked, drawn from the ranges in the table above. This is what makes the output useful: brand detection in your form keys off exactly these digits, so a number with a plausible prefix exercises the same code path a genuine one would.

Filling the account number

The digits between the prefix and the final position are filled using crypto.getRandomValues(), the browser’s cryptographically secure random source, rather than Math.random(). Nothing about the account body is derived from anything you type, and no request leaves the page.

Calculating the Luhn check digit

The last digit is not random — it is computed so the number as a whole satisfies the Luhn checksum. Here is the calculation in full for a 15-digit Visa payload:

Partial number: 4539 1488 0343 657_

Step 1 — Double every second digit, starting from the rightmost payload digit:
4  5  3  9  1  4  8  8  0  3  4  3  6  5  7
×2    ×2    ×2    ×2    ×2    ×2    ×2    ×2
8  5  6  9  2  4 16  8  0  3  8  3 12  5 14

Step 2 — Subtract 9 from any result over 9:
8  5  6  9  2  4  7  8  0  3  8  3  3  5  5

Step 3 — Sum every digit: 8+5+6+9+2+4+7+8+0+3+8+3+3+5+5 = 76

Step 4 — Check digit = (10 − (76 mod 10)) mod 10 = (10 − 6) mod 10 = 4

Result: 4539 1488 0343 6574

Run 4539148803436574 through any Luhn implementation and it passes. That same arithmetic is what your checkout form performs before it ever contacts a gateway — which is precisely why a generated number gets past it. For the algorithm on its own, including the off-by-one that catches most people implementing it from scratch, see the guide to the Luhn algorithm in the guides section.

What these numbers can and cannot do

This is the distinction that matters most, and it is the one most tools in this category never state.

These numbers will:

• Pass client-side Luhn validation in your checkout form
• Trigger the correct brand detection — Visa logo, Mastercard logo, and so on
• Match the length and format rules your input mask expects
• Serve as fixtures in automated test suites
• Let you exercise error states, digit grouping, and field validation

These numbers will not:

• Complete a payment on any live or sandbox payment system
• Return an authorisation, approval, or decline code from an issuer
• Work for a trial signup, a subscription, or any purchase
• Carry a balance — they are attached to no account whatsoever
• Pass a gateway’s own validation, which checks the prefix against genuine BIN tables

If you came here looking for a number that will actually pay for something, this tool cannot help you and neither can any other. The arithmetic that makes a number well-formed is public; the issuer records that make an account exist are not, and no formula bridges that gap. We set this out in full in our guide on whether "credit card numbers that work" exist.

Common use cases

Payment form validation testing. Confirm that your input mask groups digits correctly, that paste handling survives spaces and dashes, and that the brand indicator updates as the user types rather than on blur.

Checkout UI development. Switch between networks to check that the card artwork changes and that the CVV field resizes from three digits to four when an Amex number is entered — a case that is easy to miss and obvious to users when it breaks.

Automated test fixtures. Cypress, Playwright, and Jest suites need stable card data that is safe to commit to a repository. Synthetic numbers are safe to commit; anything resembling genuine cardholder data is not.

BIN routing logic. If you route different networks to different processors, you need numbers across each range to prove the routing table behaves.

Data masking and PCI scope testing. Verify that your logs, error reports, and analytics payloads mask the primary account number before it is written anywhere.

Teaching and demos. Show how a card number decomposes without putting a genuine one on a screen.

A fixture file for the first case looks like this:

// Cypress test fixture — checkout form validation
const testCards = {
  visa:       '4539148803436467',
  mastercard: '5425233430109903',
  amex:       '374245455400126',
};

it('detects the card brand as the user types', () => {
  cy.get('[data-cy=card-number]').type(testCards.visa);
  cy.get('[data-cy=card-brand]').should('have.text', 'Visa');
});

it('expects a four-digit CVV for American Express', () => {
  cy.get('[data-cy=card-number]').type(testCards.amex);
  cy.get('[data-cy=cvv]').should('have.attr', 'maxlength', '4');
});

Every number in that fixture is Luhn-valid and issued by nobody.

When to use your gateway’s sandbox cards instead

Our numbers test your code. They cannot test the payment processor’s behaviour, because they are not registered in any processor’s system. The moment a test crosses that boundary, you need the official sandbox cards your provider publishes — recognised numbers wired to scripted responses.

Reach for the gateway’s own test cards when you need to:

• Test approval and decline flows end to end
• Trigger specific decline codes such as insufficient funds, expired card, or a card reported stolen
• Exercise 3-D Secure and SCA challenge flows
• Test refunds, partial refunds, and voids
• Test subscriptions and recurring billing
• Verify webhook delivery and idempotency handling

Stripe’s testing documentation and PayPal’s sandbox guide both publish full tables of these. We collect the equivalents for the major providers on the test card numbers reference, and the FAQ covers what a Luhn-valid number does and does not prove.