Skip to main content

Credit Card Generator

Luhn-valid test card numbers built from real IIN prefixes and lengths for Visa, Mastercard, American Express, Discover, JCB, Diners Club, and UnionPay. The last digit is computed as the Luhn check digit over the random digits before it, and Amex numbers get 15 digits and a 4-digit CVV. None belongs to an account, so any real processor declines them.

Runs entirely in your browser

This tool sends nothing over the network. Everything you enter is processed on your device and never reaches our servers.

Testing
Payments
Finance
Loading the tool
Reference

Documentation

A test credit card number generator produces numbers that look and validate like real card numbers without belonging to any account. A card number has three parts: the issuer identification number (IIN, often called the BIN) at the front, which identifies the network and issuer; an account identifier in the middle; and a final check digit computed with the Luhn algorithm. Checkout validation code tests the prefix, the length, and the check digit, and those three properties are exactly what each generated number satisfies.

Each network has its own prefixes and length. Visa numbers start with 4 and are generated at 16 digits, the common length, although 13 and 19 digit Visa numbers also exist. Mastercard uses 51 through 55 and 2221 through 2720, at 16 digits. American Express uses 34 and 37 at 15 digits, with a 4-digit security code where the other networks use 3. Discover uses 6011, 644 through 649, and 65; JCB uses 3528 through 3589; UnionPay uses 62; all three are generated at 16 digits. Diners Club numbers start with 300 through 305, 36, or 38 and are 14 digits long. A prefix is drawn at random from the network's list, the digits after it are random, and only the last digit is calculated.

The Luhn algorithm, devised by IBM engineer Hans Peter Luhn and specified for card numbers in ISO/IEC 7812, works from the right. Every second digit, starting with the one immediately left of the check digit, is doubled; 9 is subtracted from any doubled value above 9; and all the digits are summed. The check digit is whatever brings that total to a multiple of 10, which is (10 - sum mod 10) mod 10. The check catches every single mistyped digit and most swaps of two neighboring digits, which is why checkout forms run it before contacting a payment processor.

Security codes are random digits and expiry dates are random months in a later calendar year, up to the number of years set under Settings, which also holds digit grouping with spaces or dashes after every four digits. Plain text, JSON, and CSV carry the same data for pasting into fixtures or test runners. Nothing beyond format rules can verify the code or the date, because an issuer checks both against an account and these numbers have none. Payment gateway test environments are a separate matter: Stripe test mode and the Braintree sandbox accept only the specific test numbers their own documentation lists, so generated numbers suit client-side validation, input masks, and database fixtures rather than sandbox charges.

Take the 15-digit Visa partial number 4111 1111 1111 111. Reading from the right, the doubled positions hold seven 1s and the leading 4, giving 7 x 2 + 8 = 22; the other seven positions are 1s, giving 7. The sum is 29, so the check digit is (10 - 9) mod 10 = 1, and the full number is 4111 1111 1111 1111, which passes the check.

Test credit card numbers serve development, quality assurance, and teaching wherever realistic but non-functional payment data is required.

  • Payment Form Validation: Client-side checks for prefix, length, and Luhn digit can be exercised with structurally valid numbers before any gateway is involved. The gateway's own sandbox still needs the test numbers it publishes.
  • E-commerce Checkout Testing: Run through a purchase flow on a staging site with generated Visa and Mastercard numbers to confirm that the checkout form validates input formatting and displays appropriate error messages for cards the processor rejects.
  • Form Validation Development: Feed generated numbers from all seven networks into a front-end validation function to confirm that Luhn checks and network detection logic handle every supported prefix and card length.
  • Automated Test Suites: A CSV batch of 100 card entries loads into a Selenium, Cypress, or Playwright test runner as parameterized input for regression testing across multiple networks.
  • Database Seeding: JSON output piped into a seed script populates a development database with realistic payment records that exercise encryption and tokenization layers without holding real card data.
  • Mobile App Development: Card entry screens usually detect the network from the first digits to show a logo and switch the input mask, and Amex numbers need a 15-digit field and a 4-digit code. Numbers from every network exercise that detection.
  • Security Training: Demonstrate Luhn algorithm mechanics in a cybersecurity or fintech training session by generating numbers and walking through the check digit calculation.
  • Documentation: Embed generated card numbers in API documentation and developer guides as realistic sample data without exposing actual account information.
Inputs, outputs, and what the Credit Card Generator computes

What the Credit Card Generator asks for and what it returns, as a plain list. Defaults, units, and ranges are the ones the form loads with.

Inputs

  • Card Network · default: Visa
  • Number of Cards (numeric input) · default: 5 · range: 1 to 100
  • Include CVV · default: on
  • Include Expiry Date · default: on
  • Output Format · default: Plain Text
  • Digit Grouping · default: None
  • Maximum Expiry Years from Now (numeric input) · default: 5 · range: 1 to 10
  • Generated Cards

Controls

Generate · Reset · Copy to Clipboard

Example

Take the 15-digit Visa partial number 4111 1111 1111 111.