Credit card number generator

These numbers exist so that a checkout form, a payment screen or a seeded test database has something card-shaped to work with. Each one has the right length for its network, starts inside a range that network publishes, and ends with the Luhn check digit that makes it pass the first validation any payment form performs. That is the whole of what they are. None of them is attached to an account, a balance, a bank or a person; none carries an expiry date or security code that was ever issued with it; and none of them can pay for anything, because no issuer has ever heard of it and every processor declines it at authorization.

What a credit card number generator actually produces

A card number is three parts stuck together. The leading digits are the issuer identification number, or IIN, which says which network and which issuer the account belongs to. The middle is the account identifier the issuer assigned. The final digit is a checksum computed with the Luhn algorithm: double every second digit counting from the right, subtract nine from any result above nine, add everything up, and a correct number is divisible by ten.

That is arithmetic, not authorization. It catches typing mistakes before a request is worth sending — every single wrong digit, and every swap of two neighboring digits except a nine moving past a zero, which is the algorithm's one blind spot. It says nothing about whether the account exists, whether it has money on it, or whether the person typing it is allowed to. A generator can therefore produce a number that satisfies the check without any of the facts a real payment needs.

The published ranges these numbers come from

No card network reserves an IIN range for testing. What networks and their acceptance partners publish is the ranges they actually issue in, so that is what this page uses, and every row below names the document it came from and the day it was read. The generator draws from this exact table, weighted by how wide each range is, so a narrow series does not show up as often as a wide one.

Two of those rows deserve a footnote. Visa's source states a maximum length and no minimum, so the tool generates the common sixteen digits while the checker accepts anything up to nineteen. Diners Club is listed at fourteen digits by the acceptance documentation cited above, while Discover Global Network — which routes Diners Club — lists the same ranges at sixteen to nineteen digits today. Both are true of cards in circulation, and a page that quietly picked one would be hiding a real ambiguity.

When a generated number is the wrong tool

If your request actually reaches a payment gateway, stop generating and open that gateway's documentation. Stripe, PayPal, Adyen, Authorize.net and Visa Acceptance each publish a short list of numbers their sandbox recognizes, and those numbers are not interchangeable: a particular value is what triggers an approval, a decline, an expired card or a 3-D Secure challenge. A generated number is not on any of those lists, so a sandbox rejects it before your code under test is even reached, and the test result you get back is about the wrong thing.

Generated numbers are the right tool one step earlier: filling a form to check field masks, spacing, and paste handling; confirming that your card-type detection labels a 2-series Mastercard correctly; producing a thousand rows of fixture data whose shape is realistic and whose contents belong to nobody. Because the ranges above are real issuing ranges, a value could in principle collide with an account somebody holds. It carries nothing that would let anyone use it — but that is one more reason never to point a generated number at a live endpoint.

Checking a number you already have

The second half of the tool runs the same arithmetic backwards. Paste anything, with or without spaces and hyphens, and it reports whether the Luhn digit is correct, how many digits there are, and which published range the number begins in. That combination is what makes a verdict useful: a number can pass Luhn and still be nonsense for its network, and a number that begins in a genuine Visa range can still have a typo in the middle.

This is also how to read a support ticket that says a card was “declined for an invalid number”. If the digits fail Luhn, the customer mistyped and no gateway was ever involved. If they pass, the problem is somewhere the arithmetic cannot see, and the next place to look is the authorization response rather than the form.

Nothing you type here leaves the tab

Generation and checking both run in your browser. There is no upload, no request carrying the number, no analytics, and no server log — and nothing is ever put in the address bar, so a number you check cannot end up in your history, in a bookmark or in a link you paste to a colleague. Reloading the page clears everything. That is not a promise about intentions; it is a consequence of there being no code here that could send a digit anywhere.

The same check digit idea shows up across the identifiers on this site, computed differently each time. The UPC generator closes a GTIN-12 with a weighted mod-10 sum that triples every second digit instead of doubling it, which is why a UPC check digit and a Luhn check digit disagree about the same string of numbers. When those identifiers need to become scannable artwork, the barcode generator draws one symbol and the bulk barcode generator turns a whole column of them into separate files. And when a test fixture needs identifiers with no checksum at all, the UUID generator produces values whose only job is to be unique.