Credit Card Validator

Most credit card validators give you one box for one number. That is fine until you have a whole column of them. Paste a list into this one, or drop a .txt or .csv onto the box, and it scores every number in one pass: the Luhn checksum, the network behind the opening digits, the digit count, and a plain verdict on each row. Then copy the results as a CSV, download them, or grab only the numbers that passed. All of it runs in your browser, so nothing you paste is uploaded, logged, or saved. That matters more with card data than with almost anything else.

You can still check one number the ordinary way. Flip to Single number, type or paste a card, and the result updates as you go. But bulk is the reason to bookmark this, since grinding through a list one at a time is the exact chore it removes. There is one caveat worth stating plainly. A number that passes here is well-formed, meaning the digits are internally consistent. It says nothing about whether a bank ever issued the card, whether the account is open, or whether there is a cent behind it. Validation and authorization are two different jobs, and only a bank does the second.

1. Pick a mode. Single number for a quick one-off, Bulk list when you have several. The tool opens in Single mode.
2. Single mode: type or paste the card number. Spaces and dashes are fine, or skip them. Green means it passes Luhn and the length fits the network, amber means the checksum passes but the digit count is off, red means the checksum fails.
3. Bulk mode: paste your list, one number per line. You can also drag a .txt or .csv onto the box, paste a file from your clipboard, or use the Choose a list file button. A line pasted straight from a spreadsheet row works too, since the tool keeps only its card-length run of digits.
4. Read the summary, then the table. A running count of valid, checksum-only, and invalid numbers sits above a row-by-row table with each number's network, digit count, Luhn result, and verdict.
5. Export what you need. Copy the whole table as CSV, download it, or copy only the numbers that passed, one per line.
6. Try the samples to watch it move. Single mode has one-click examples, and Bulk mode has a Load sample list button.

This is the part that sets the tool apart. Say you have exported a batch of form submissions, or you are staring at a spreadsheet column of card-shaped strings that need checking. Paste the column in, or drop the file, and every row gets scored at once.

The parser is forgiving. One number per line is the clean way, but a raw CSV row works too, because for each line the tool pulls out the run of digits that is card length, 12 to 19, and leaves names, dates, and status flags alone. So a line like Ada Lovelace,4532015112830366,active validates the card and ignores the rest. From there the summary shows the shape of the batch straight away, and the export buttons do the tedious part: Copy valid only pulls out the numbers that cleared every check, while Copy results and Download CSV hand you the full table.

Watch the amber rows, the checksum-only ones. They pass the Luhn math but their length cannot be confirmed, either because the digit count is wrong for the network their prefix points to or because the prefix matches no network at all. The first case usually means a digit got dropped or doubled. Those are worth a second look rather than a delete, the fix might be one character.

The Luhn algorithm, also called mod-10, is a simple checksum. Its job is catching the mistakes people make typing or reading a number: a single wrong digit, or two adjacent digits swapped. It catches every single-digit slip and almost every transposition. That is all it does, so it flags typos and proves nothing about whether a card is real.

The last digit of a card is not part of the account. It is the check digit, chosen so the whole string satisfies the Luhn formula, and the tool recomputes that math to confirm it still fits. Change any single digit and the sum no longer lands on a multiple of ten, so the check fails. Because Luhn only tests for a multiple of ten though, roughly one in ten random numbers of the right length passes by pure luck, so a pass really only rules out typos.

The opening digits are not random. The first six to eight are the Issuer Identification Number (IIN), still widely called the Bank Identification Number (BIN), assigned under the ISO/IEC 7812 standard. This tool reads them to name the scheme:

• Visa starts with 4 and runs 13, 16, or 19 digits, though 16 is what you will almost always see.
• Mastercard uses the classic 51 to 55 range plus a newer 2221 to 2720 block added in 2017, always 16 digits.
• American Express starts with 34 or 37, always 15 digits, grouped four then six then five.
• Discover covers 6011, 65, the 644 to 649 range, and part of the 622xxx block, at 16 or 19 digits.
• Diners Club and JCB both open with a 3, which is exactly why one leading digit cannot separate them from Amex. The tool reads several digits before it commits, then confirms the length fits.

This is the honest part most validators skip, and it is the most useful thing here. A pass means the number is structurally sound. It does not mean the card is real, since plenty of test-data generators build Luhn-valid strings that never belonged to anyone. It does not mean the card is active, because a well-formed number can point to a card that expired years ago or was closed. And it says nothing about a balance, or whether the CVV and expiry match.

What actually confirms a usable card is an authorization request. At checkout the merchant sends the number, expiry, CVV, and amount to the payment network, which routes it to the issuing bank, and the bank approves or declines in real time. Luhn is only the cheap gate in front of that, so a form can reject an obvious typo without wasting a network call.