Credit Card Number Generator

Network	Number	CVV	Expiry	Luhn	Copy
{{ item.label }}	{{ item.display }}	{{ item.cvv \|\| '—' }}	{{ item.expiry \|\| '—' }}	{{ item.luhnValid ? 'Valid' : 'Invalid' }}

Credit card numbers are structured identifiers that follow network starting patterns and a final check digit. Synthetic numbers shaped the same way let teams test payment paths without touching live accounts.

They support format checks, data flow rehearsal, and checksum verification so bugs surface early and safely. When you need test credit card numbers with checksum, this generator produces results that match network lengths and prefixes while keeping control over display and masking.

You choose a network or provide a starting prefix, set how many results you want, and decide whether to add a security code or an expiry. The view can show plain digits, groups, or dashes, and you may hide trailing digits on screen while copies always include the full number.

Outputs are for testing only and cannot complete transactions. Treat them as disposable, and keep real account numbers out of your process.

Technical Details:

The generator models card numbering as a prefix that identifies a network followed by variable account digits and a final check digit computed by the Luhn modulus ten method. The tool also provides optional security codes and expiry values for scenario coverage.

From the observed quantities of network prefix and target length, the computation draws random body digits, calculates the Luhn check digit, and assembles a complete number. Results are labeled with a pass or fail status for the checksum.

Validity here means the digits satisfy the Luhn rule and match the chosen network’s starting patterns and typical lengths. It does not imply an active account or issuer authorization.

Comparisons across runs are reproducible when a seed is supplied; the same seed and settings yield the same sequence. Without a seed, a non‑deterministic source is used.

\begin{array}{l} Given p = (d_{n} \dots d_{2}, d_{1}) \\ s = \sum i_{=1} \dots n {\begin{matrix} (2 \times d_{i}) - 9 & if (i \mod 2) = 0 and (2 \times d_{i}) > 9 \\ 2 \times d_{i} & if (i \mod 2) = 0 and (2 \times d_{i}) \leq 9 \\ d_{i} & if (i \mod 2) = 1 \end{matrix}} \\ c = (10 - (s \mod 10)) \mod 10 \end{array}

Symbols and units
Symbol	Meaning	Unit/Datatype	Source
p	Partial number without the check digit	digits	Input/derived
d_i	Digit at position i from the right	0–9	Derived
s	Adjusted sum after doubling every second digit	integer	Derived
c	Luhn check digit	0–9	Derived
n	Total length of the number	digits	Input/derived

Worked example. Using partial 7992739871, compute the sum by doubling every second digit from the right and subtracting nine when the double exceeds nine. The resulting check digit is 3; the full number 79927398713 passes the Luhn test. Near the edge of validity, changing any single digit breaks the checksum.

Networks, lengths, and starting patterns
Network	Allowed Lengths	Default Length	Grouping (display)	Prefix Patterns
Visa	13, 16, 19	16	4‑4‑4‑4	4
American Express	15	15	4‑6‑5	34, 37
Mastercard	16	16	4‑4‑4‑4	51–55, 2221–2720
Discover	16, 19	16	4‑4‑4‑4	6011, 622126–622925, 644–649, 65
Diners Club	14, 16	14	4‑6‑4	300–305, 36, 38–39
JCB	16, 17, 18, 19	16	4‑4‑4‑4	3528–3589
Maestro	12–19	16	4‑4‑4‑4	50, 56–69
UnionPay	16–19	16	4‑4‑4‑4	62

Validation and bounds enforced by the tool
Field	Type	Min	Max	Step/Pattern	Notes
Card type	enum	—	—	visa, amex, mastercard, discover, diners, jcb, maestro, unionpay	Controls prefixes, typical lengths, and display grouping.
Quantity	integer	1	100	1	Rows generated per run.
Custom BIN / IIN	digits	0	target length − 1	`\d*`	Non‑digits stripped; may be ignored if prefix enforcement is on and it mismatches the network.
Length override	integer	0	24	1	Zero picks the network default; positive values clamp to 12–24.
Display format	enum	—	—	plain, spaces, dashes	Presentation only; copies always use digits.
Mask last	integer	0	target length	1	Replaces trailing digits with bullets on screen.
Include CVV/CVC	boolean	—	—	—	Adds a synthetic security code.
CVV mode	enum	—	—	auto, 3, 4	Auto uses 4 for American Express and 3 otherwise.
Include expiry	boolean	—	—	—	Adds a future MM/YY picked from the window below.
Expiry window	integer months	1	120	1	Defaults to 1–60; random month chosen within [min, max].
Enforce network prefix	boolean	—	—	—	If on and BIN mismatches, a valid network prefix is used instead.
Seed	string	—	—	text	Identical seed and inputs reproduce outputs.

Randomness & reproducibility. A 32‑bit state is derived from the seed string using integer xor and multiplication constants, then transformed into uniform values in [0, 1). With the same seed and settings, the sequence is deterministic; without a seed, results vary by run.

Time & calendrics. Expiry dates are computed in local time by adding a random number of months within the configured window and formatting the result as MM/YY.

I/O formats. Outputs can be viewed as a table, a newline list, or a JSON payload. CSV and JSON can be copied or downloaded. Display grouping and masking do not change copied digits.

Networking & storage behavior. All processing is browser‑based; there are no server requests. Clipboard writes and file downloads are initiated by the user.

Performance & complexity. Generating Q records of length n is O(Q·n) time and O(1) additional memory per record.

Diagnostics & determinism. The JSON view includes both inputs and results to aid reproducibility. The Luhn status in the table reflects exactly the digits shown without formatting characters.

Security considerations. The security code is independent of the number and is not validated against issuer rules. Masking protects only the on‑screen view; the copied value always contains all digits. Generated numbers should never be used for fraud or attempted authorization.

Assumptions & limitations.
Length overrides can pick values not typical for a network.
Prefix enforcement only checks starting ranges, not issuer‑specific allocations.
The checksum is Luhn only; no extra issuer rules are applied.
The security code is random and not issuer‑derived.
Expiry selection uses months ahead within the stated bounds.
Masking affects display only, not copied or exported content.
Randomness is not suitable for cryptography.
Heads‑up Non‑digit characters in the BIN are removed before use.

Edge cases & error sources.
BIN longer than target length is truncated.
Mask value above the length is clamped to the length.
Length below 12 is clamped upward when overriding.
Odd formatting with groups may add a short trailing group.
Copy operations can fail if clipboard permissions are denied.
Very large quantities are capped and may not reflect the requested count.
Seed differences by case or whitespace produce different sequences.
System date shifts change generated expiry months.
Export failures can occur if downloads are blocked by the environment.
JSON copying is disabled when there are no results.

Privacy & compliance. No data is transmitted or stored server‑side. Outputs are educational and not financial advice. Use only test data in development and QA environments.

Step‑by‑Step Guide:

The generator creates Luhn‑valid, network‑shaped test numbers and optional scenario fields.

Choose a network or provide a starting prefix Card type.
Set how many numbers to produce Quantity.
Optionally enter a starting BIN/IIN and a custom length.
Select display grouping and how many trailing digits to hide.
Optionally add a security code and an expiry window.
Turn on prefix enforcement to ignore mismatched BINs.
Provide a seed to reproduce outputs exactly.
Generate, then copy, download CSV, or export JSON.

Example. Network: Visa; quantity: 3; BIN: 411111; length: 16; seed: demo. You will get three 16‑digit numbers that begin with 411111 and show Valid in the Luhn column.

Tip: Use a seed while debugging to reproduce an exact failing case.

You are ready to verify checksum handling, input masks, and downstream formatting.

FAQ:

Is my data stored?

No. Generation and exports happen locally, and nothing is sent to a server.

How accurate is the “Valid” label?

It reflects the Luhn checksum only and the chosen network’s starting ranges. It does not test issuer‑specific rules or account status.

Which units and formats are used?

Numbers are plain digits; grouping and dashes are visual only. Expiry is MM/YY, and security codes are 3 or 4 digits.

Can I work offline?

Yes. Once loaded, generation and validation do not require a network connection.

How do I target a specific BIN?

Enter the starting digits in the BIN/IIN field. Enable prefix enforcement to ignore entries that do not match the chosen network.

What does a “Valid” result guarantee?

Only that the digits satisfy Luhn and match network starts. It does not guarantee a usable or open account.

How are CVV/CVC lengths chosen?

Auto mode uses 4 for American Express and 3 for other networks. You can force 3 or 4 explicitly when needed.

Is there any cost or license restriction?

No licensing terms are displayed here. Generated numbers are intended for development and QA scenarios.

Troubleshooting:

Copy buttons do nothing: check clipboard permissions and try again after interaction.
CSV or JSON is empty: generate at least one number first.
Masked digits appear in copies: reduce the mask; copies always use raw digits.
BIN ignored: enable prefix enforcement or verify it matches the selected network.
Unexpected lengths: clear the length override to use the network default.
Expiry looks past: confirm the min and max months ahead are set correctly.
Different results between runs: set a seed to make outputs reproducible.

If nothing generates at all, lower the mask, clear the BIN, reset the length override, and try a default network with quantity set to 1.

Advanced Tips:

Tip Keep one seed per test case to recreate exact records across environments.
Tip Use BIN partials to probe prefix‑based routing without exposing real allocations.
Tip Switch display formats to exercise parsers that accept spaces or dashes.
Tip Mask more digits when demonstrating UI security states during reviews.
Tip Export both CSV and JSON to feed batch and API tests with the same data.
Tip Nudge the expiry window to cover near‑term and far‑future validation branches.

Glossary:

IIN/BIN: Issuer Identification Number or Bank Identification Number starting the card.
Luhn checksum: Modulus ten rule that detects single‑digit errors and most transpositions.
Security code: Three or four digits used in card‑not‑present checks.
Masking: Replacing visible trailing digits with bullets for display privacy.
Seed: Text that fixes the random sequence for reproducible outputs.
Grouping: Visual splitting of digits to improve readability.