Credit Card Validator
Free credit card validator for developers and QA. Runs the Luhn (Mod-10) check, detects the brand and reads the issuer, country and card type from the BIN.
What is Credit Card Validator?
A credit card validator checks whether a card number is well-formed. It runs the Luhn (Mod-10) checksum, verifies the length and prefix against the rules each network publishes, and reads the first six digits (the BIN) to identify the issuing bank, brand, country and card type.
This is a developer and analyst utility, not a payment tool. It runs entirely outside any payment gateway, so you can sanity-check a number that came from a form, a log line or a test fixture without sending it anywhere it does not need to go.
The validator confirms format and mathematical structure only. It runs the Luhn algorithm and a static BIN database lookup. It does not talk to the issuer, the network or any payment gateway.
It does not verify that the account exists, that the card is active, that there are funds, that the CVV or expiry are correct, or that the cardholder is who they say they are. A VALID result means the number is well-formed. Nothing more.
How to Use Credit Card Validator?
Three steps.
-
Step 1. Paste a card number into the input field. Length can be anything from 12 to 19 digits. Spaces and dashes are stripped automatically, and the detected brand badge appears as you type.
-
Step 2. Solve the CAPTCHA. It is there to keep automated abuse out, not to get in your way.
- Step 3. Click VALIDATE. The number runs through the length check, the Luhn checksum, BIN extraction and the database lookup in a single round trip.
You get back the Luhn status (VALID or INVALID), the brand, the issuing bank, the card type (credit, debit, prepaid) and the country, plus the raw BIN. Expand the modals for the full record, copy any field, or export the whole result as JSON, CSV or TXT.
How Credit Card Validator Works?
The validator runs a short pipeline. Sanitise the input, check the length, run Luhn, extract the BIN, look it up in the database and return the result. Some of that happens in your browser for instant feedback, the rest happens on the server. The card number is not stored in our application database after the response is returned.
1. Input Sanitization & Length Validation
The tool first sanitizes the input by removing all non-digit characters (spaces, dashes, dots, etc.), ensuring only numeric digits remain. It then validates that the card number length falls within the acceptable range of 12-19 digits, which covers all major card brands from Maestro (12 digits) to standard cards (16 digits) and extended formats (19 digits).
Validates that a card number has been entered before processing, preventing submission of empty fields.
Automatically strips spaces, dashes, and formatting characters to extract pure numeric digits.
Verifies card number length is between 12-19 digits, rejecting numbers outside this range.
As you type, the tool analyzes the first digits to detect the card brand and displays it instantly.
2. BIN (Bank Identification Number) Extraction
The first 6 digits of any card number form the BIN (Bank Identification Number), also known as IIN (Issuer Identification Number). This unique identifier reveals the card's issuing institution, brand, type, and country of origin. The Credit Card Validator extracts this BIN code and uses it for database lookups and brand detection.
Automatically extracts the first 6 digits from the sanitized card number as the BIN code, which serves as the primary identifier for database queries.
The first digit (Major Industry Identifier) indicates the card's industry category, such as banking/financial (4, 5), travel/entertainment (3), or other industries (1, 2, 6, 7, 8, 9).
The complete 6-digit BIN uniquely identifies the specific financial institution, payment network, card type, and geographic region where the card was issued.
The extracted BIN becomes the lookup key. One query against the BIN database returns the issuer, card type, country and contact metadata in one response.
3. Luhn Algorithm (Modulus 10) Validation
The Luhn algorithm, also known as the Modulus 10 or Mod-10 algorithm, is a mathematical checksum formula used to validate identification numbers, including credit card numbers. Developed by IBM scientist Hans Peter Luhn in 1954, this algorithm detects single-digit errors and most transpositions of adjacent digits.
Let's walk through the process step-by-step using the example credit card number 4417 1234 5678 9113.
Step 1: Reverse the Number
The first step is to take the card number and read it in reverse, from right to left. This is a crucial preparatory step for the algorithm. For example, the card number 4417 1234 5678 9113 becomes 3119 8765 4321 7144 when read from right to left.
Step 2: Sum the Even-Positioned Digits
Using the reversed number, we now sum all the digits in the even positions. In this example, we add 3 + 1 + 8 + 6 + 4 + 2 + 7 + 4 to get a sum of 35.
Step 3: Double and Sum the Odd-Positioned Digits
Next, we process the odd-positioned digits. We double each one, and if the result is a two-digit number, we sum its digits. The final sum of all these processed values is 35.
Step 4: Final Modulo 10 Validation
Finally, we add the two sums together: 35 + 35 = 70. We then perform the modulo 10 operation: 70 MOD 10 = 0. Since the result is 0, the credit card number is valid.
This mathematical validation ensures that the card number follows the correct format structure used by all major card issuers. A card number that fails the Luhn check cannot be a valid card number, regardless of whether an account exists.
4. Card Brand Detection
The tool identifies the card brand by analyzing the Issuer Identification Number (IIN) ranges. Each major card brand has specific IIN ranges assigned by the payment card industry standards:
Starts with digit 4. Standard length: 16 digits (can be 13 or 19 for some variants).
Starts with 51-55 or 2221-2720. Standard length: 16 digits.
Starts with 34 or 37. Standard length: 15 digits.
Starts with 6011, 622126-622925, 644-649, or 65. Length: 16-19 digits.
Starts with 3528-3589. Length: 16-19 digits.
Starts with 62. Length: 16-19 digits.
The tool supports detection of 30+ card brands including Diners Club, Maestro, RuPay, Mir, Troy, and many regional card schemes. Brand detection occurs both client-side (for instant feedback) and server-side (for accurate validation).
5. BIN Database Lookup
With the BIN in hand, the tool queries the BIN database. One lookup returns the full issuer record for that range:
The 6-digit Bank Identification Number extracted from the card number, used to identify the issuing institution.
The specific financial institution or credit union that issued the card.
The payment network brand (Visa, Mastercard, American Express, etc.).
Whether the card is Credit, Debit, Prepaid, or Virtual.
The country name where the card was issued, indicating the geographic location of the issuing financial institution.
The ISO 3166-1 alpha-2 country code (two-letter code) for the country where the card was issued (e.g., "US", "GB", "CA").
The ISO 3166-1 alpha-3 country code (three-letter code) for the country where the card was issued (e.g., "USA", "GBR", "CAN").
Official website URL of the issuing bank or financial institution (if available).
Contact phone number for the issuing bank or financial institution (if available).
If a BIN is not found in our database, the tool falls back to brand detection using IIN range analysis and displays available information. The database is regularly updated with new BIN ranges and issuer information.
6. Result Compilation & Display
The results come back as a single response and render into a layout you can scan in a second. You get:
A color-coded status card showing VALID (green) or INVALID (red) with visual icons, card number confirmation, and validation description.
Card brand, card type and country of issue side by side, each with its own icon so you can scan the result in a second.
Dedicated badges showing both Luhn Algorithm validation and Checksum validation results (VALID/INVALID).
The full card record: number, issuer (brand), Luhn status, checksum status and the card format (length in digits).
Complete BIN information including BIN Code, Issuing Bank, Card Type, ISO Country (name), ISO Country A2 (two-letter code), ISO Country A3 (three-letter code), Issuer Website, and Issuer Contact phone number.
Export complete validation results in multiple formats: JSON (structured data), CSV (spreadsheet-compatible), or TXT (plain text) with all BIN details, validation status, and timestamps included.
Credit Card Number Breakdown
A credit card number is composed of several distinct parts, each serving a specific purpose in identifying and validating the card:
-
First Digit (MII): Identifies the payment network (e.g., 4 for Visa, 5 for Mastercard, 3 for Amex/Diners Club).
-
Issuer Identification Number (IIN/BIN): The first 6 digits (or more) identify the specific bank or financial institution that issued the card.
-
Account Identifier: The next 9-12 digits are unique to your personal account, linking the card to your financial details.
- Check Digit: The final digit, calculated by the Luhn Algorithm, validates the entire number to prevent errors and fraud.
The Issuer Identification Number (IIN) and Bank Identification Number (BIN) reference table below lists every card brand the validator recognises, with its prefix ranges, expected lengths, active status and validation method. Use it to identify a card by hand or to confirm the expected format for a given brand.
| NETWORK | IIN/BIN RANGES | STATUS | LENGTH | VALIDATION | REGION |
|---|---|---|---|---|---|
| American Express | 34, 37 | Active | 15 | LUHN | Global |
| Bankcard | 5610, 560221–560225 | Inactive | 16 | LUHN | Australia (defunct) |
| BORICA | 2205 | Active | 16 | LUHN | Bulgaria |
| China T-Union | 31 | Active | 19 | LUHN | China |
| China UnionPay | 62, 81 (8100–8171, Discover-routed) | Active | 16, 19 | LUHN | China (Global acceptance) |
| Dankort | 5019 | Active | 16 | LUHN | Denmark |
| Dankort (Visa co-brand) | 4571 | Active | 16 | LUHN | Denmark |
| Diners Club enRoute | 2014, 2149 | Inactive | 15 | NONE | North America (defunct) |
| Diners Club International | 30, 36, 38, 39 | Active | 14, 16, 19 | LUHN | Global |
| Diners Club US & Canada | 55 | Active | 16 | LUHN | United States, Canada |
| Discover Card | 6011, 644–649, 65 | Active | 16, 19 | LUHN | Global |
| GPN (Gerbang Pembayaran Nasional) | 1946 (BNI cards), 50, 56, 58, 60–63 | Active | 16, 18, 19 | LUHN | Indonesia |
| Humo | 9860 | Active | 16 | LUHN | Uzbekistan |
| InstaPayment | 637–639 | Active | 16 | LUHN | Global |
| InterPayment | 636 | Active | 16, 19 | LUHN | Global |
| JCB | 3088–3094, 3096–3102, 3112–3120, 3158–3159, 3337–3349, 3528–3589 | Active | 16, 19 | LUHN | Global (Japan-based) |
| LankaPay | 357111 (JCB co-branded) | Active | 16 | LUHN | Sri Lanka |
| Laser | 6304, 6706, 6771, 6709 | Inactive | 16, 19 | LUHN | Ireland (defunct) |
| Maestro | 5018, 5020, 5038, 5893, 6304, 6759, 6761, 6762, 6763 | Sunset | 12, 19 | LUHN | Global (EU sunset) |
| Maestro (UK) | 6759, 676770, 676774 | Active | 12, 19 | LUHN | United Kingdom |
| Mastercard | 2221–2720, 51–55 | Active | 16 | LUHN | Global |
| Mir | 2200–2204 | Active | 16, 19 | LUHN | Russia |
| Napas | 9704 | Active | 16, 19 | LUHN | Vietnam |
| NPS Pridnestrovie | 6054740–6054744 | Inactive | 16 | LUHN | Pridnestrovian Moldavian Republic |
| RuPay | 60, 65, 81, 82, 508 | Active | 16 | LUHN | India |
| RuPay (JCB co-brand) | 353, 356 | Active | 16 | LUHN | India |
| Solo | 6334, 6767 | Inactive | 16, 18, 19 | LUHN | United Kingdom (defunct) |
| Switch | 4903, 4905, 4911, 4936, 564182, 633110, 6333, 6759 | Inactive | 16, 18, 19 | LUHN | United Kingdom (defunct) |
| Troy | 65 (Discover co-branded), 9792 | Active | 16 | LUHN | Turkey |
| UATP | 1 | Active | 15 | LUHN | Global (Airline travel) |
| UkrCard | 60400100–60420099 | Active | 16, 19 | LUHN | Ukraine |
| UzCard | 8600, 5614 | Active | 16 | LUHN | Uzbekistan |
| Verve | 506099–506198, 650002–650027, 507865–507964 | Active | 16, 18, 19 | LUHN | Nigeria |
| Visa | 4 | Active | 13, 16, 19 | LUHN | Global |
| Visa Electron | 4026, 417500, 4508, 4844, 4913, 4917 | Inactive | 16 | LUHN | Global |
Swipe sideways to view all columns.
Source: Wikipedia
Why card validation matters
Format validation is the cheapest gate you can put in front of a payment gateway. It catches typos, garbage paste-ins and broken integrations before they cost you a network round-trip, a processor fee or a frustrated customer. It is not a fraud control on its own, but it is the first useful check in any checkout pipeline.
A number that fails Luhn is going to fail at the gateway every time. Catching it in the form gives the user a clean error message instead of a generic "transaction declined" two seconds later.
Numbers that fail the Luhn check are not real card numbers. Filtering them at the edge keeps your fraud team focused on attempts that could actually authorise.
Inline format feedback (as you type, before you submit) is the cheapest UX win in a checkout flow. The user fixes the typo in place instead of bouncing.
Every authorisation attempt at a gateway has a cost, even when it fails. Pre-validating cuts the number of pointless calls and the fees that come with them.
If you are building payment code, the validator is a handy way to confirm your form, your tokeniser and your BIN routing all agree on what a given number means.
Validating input is a baseline data-quality habit for payment forms. It does not prove a card is live or authorized, but it does mean less garbage in your card-data flow.
Who uses it
A short, honest list. If your job involves looking at a card number on a screen, this tool is for you.
Reach for it when you are wiring up a checkout form, debugging a tokeniser or sanity-checking why a specific number is failing in your gateway. Faster than spinning up a sandbox.
Confirm that your form accepts the brands you support and rejects the ones you do not, and validate fixtures before a regression run. Pair it with the test card generator on the homepage to generate simulated validation sequences.
Quickly check a number that came in through a flagged transaction or a manual review. The BIN modal shows the issuer, country and card type without you logging in to anything.
When a customer says their card is being rejected, a 10-second Luhn and BIN check tells you whether it is a typo, a wrong brand or something the gateway needs to answer.
Walk through the Luhn algorithm step by step in class, or use the BIN reference table as a worked example for how payment networks structure their numbering.
Frequently Asked Questions (FAQ)
No. The number you paste is processed in memory for the length of the request and then thrown away. We do not store it in our application database. Our handling of card data is described in the Privacy Policy.
The Luhn algorithm (also called Mod-10) is a simple checksum that Hans Peter Luhn designed at IBM in 1954. Every major card network requires its numbers to pass it. The check catches single-digit typos and most swaps of adjacent digits, which makes it the cheapest sanity check you can put in front of a checkout form.
A number that fails Luhn is not a real card number, full stop. A number that passes Luhn might still be inactive, cancelled or fake, so do not treat a green tick as proof the card works.
No. A green VALID badge means the number is well-formed and passes the Luhn check. It does not tell you any of the following:
- That an account behind it exists
- That the card is active and not cancelled
- That there are funds on it
- That it has not been reported lost or stolen
- That the CVV or expiry are correct
- That the cardholder authorised anything
Anything in that list needs a real payment processor or the issuing bank. Treat this tool as a first-line check, not as proof that a card will authorise.
Pretty much all of them. The validator recognises:
- Major networks. Visa, Mastercard, American Express, Discover
- Regional brands. JCB (Japan), China UnionPay, RuPay (India), Mir (Russia), Troy (Turkey)
- Debit networks. Maestro, Visa Electron, Interac
- Other brands. Diners Club, Diners Club International, Diners Club enRoute
- Prepaid and virtual. The common prepaid ranges and virtual card numbers
Length can be anything from 12 digits (some Maestro cards) to 19 (extended formats). If the brand is not in the table, you still get the Luhn result and whatever the BIN database has on the issuer.
On the number itself: Luhn (Mod-10) checksum, length, card brand and the 6-digit BIN.
From the BIN lookup: issuing bank, card type (credit, debit, prepaid, virtual), country of issue, and the issuer’s website if we have it on file.
What it does not check: CVV or CVC, expiry date, account balance, activation status, cardholder name, billing address, or anything else that depends on a live account.
Yes, with one caveat. It is great for testing the parts of your stack that do not need a live gateway: form validation, brand detection, BIN routing, error messaging and input sanitisation.
For anything that has to authorise or simulate a decline, use the test cards your processor publishes (see Stripe's testing guide, PayPal sandbox cards, and similar processor docs). Those numbers trigger specific simulated responses inside that processor’s sandbox.
Honest answer: usually right, never perfect. We refresh the dataset regularly, but BIN ranges move around. Issuers add new ranges, retire old ones, merge with other banks, or hand off a portfolio to a different bin sponsor.
If a BIN does not match a database entry, the validator still runs the Luhn check and falls back to brand detection from the prefix. For anything you are about to act on commercially, confirm with the issuer or with the card network’s own BIN data.
Safe enough for the job it does. The number is processed in memory and discarded, requests run over HTTPS, reCAPTCHA filters automation, CSRF tokens protect every form post, and we never call a payment gateway.
As a general rule, prefer pasting test card numbers or numbers you are happy to share. If you are validating your own production cards, the safest place to run that logic is inside your own environment, with the same Luhn and BIN rules.