Credit Card Number Validator
Check payment-card numbers with Luhn, issuer-length review, batch cleanup, rule traces, charts, and clear cautions for handling full PANs.Validation Snapshot
Validation status
| # | Number | Verdict | Issuer | Checksum | Len | Rule trace | Copy |
|---|---|---|---|---|---|---|---|
| {{ record.index }} | {{ record.formatted }} | {{ record.verdict }} | {{ record.issuer }} | {{ record.luhnValid ? 'Pass' : 'Fail' }} | {{ record.length }} | {{ record.primaryNote }} |
| Section | Rule or field | Status | Detail | Copy |
|---|---|---|---|---|
| Focused record | Number | {{ focusRecord.verdict }} | {{ focusRecord.formatted }} | |
| Focused record | {{ row[0] }} | Metadata | {{ row[1] }} | |
| Rule trace | {{ trace.rule }} | {{ trace.status }} | {{ trace.detail }} |
Introduction
Payment card numbers are structured identifiers, not random strings of digits. The full value is called a Primary Account Number, or PAN. Its leading digits identify an issuer range or payment family, the middle digits identify the account within that range, and the final digit supports a Luhn checksum that catches many common typing and copying mistakes.
That structure is useful well outside a checkout form. Developers test card-entry fields with approved sandbox numbers. QA teams clean lists of fixtures copied from spreadsheets or issue trackers. Support and operations teams sometimes need to tell the difference between a full card-like value, a masked value, and a short fragment. In each case, the first safe question is structural: do the visible digits have the shape of a payment-card number?
The answer has limits. A number can pass Luhn and still be a test value, an inactive account, an expired card, a tokenized substitute, or a real card that would be declined during authorization. A prefix can look familiar and still be too broad for routing or issuer decisions. A batch can look clean while still exposing sensitive PANs in copied reports, screenshots, or downloaded files.
| PAN part | What it can tell you | What it cannot prove |
|---|---|---|
| First digit | Broad Major Industry Identifier, such as banking, travel, petroleum, healthcare, or national assignment. | A live issuer or acceptance rule. |
| IIN or BIN prefix | A leading issuer-identification slice, often discussed as six or eight digits depending on the workflow. | Current routing data without a trusted processor or brand source. |
| Account digits | The account-specific portion of the PAN. | Safe sharing permission or compliance clearance. |
| Check digit | A Luhn mod-10 check for common digit errors. | Authorization, account status, cardholder identity, or fraud risk. |
Issuer terminology is changing in many payment systems. BIN is still common shorthand for the leading bank or issuer digits, while ISO terminology uses IIN, and newer work often needs eight leading digits rather than six. A local prefix match can help test fixtures and spot obvious mismatches, but issuer routing, product type, and acceptance rules should come from the payment brand, acquirer, processor, or another trusted data source.
Full PANs deserve sensitive-data handling even when the work is only a validation check. For most testing and documentation, approved test numbers, masked values, or last-four examples are safer than live cardholder data. Structural validation should stay separate from authorization, PCI DSS scope decisions, fraud screening, and production issuer routing.
How to Use This Tool:
Start with the smallest input that answers the question. A single value is best for a suspected typo, while batch mode is better for fixture lists, exported rows, or copied notes.
- Paste a card-like value into Card number, or use Browse TXT/CSV for a text list. Spaces, dashes, and other non-digit separators are stripped before validation.
- Leave Batch mode off for one spot check. If the pasted text contains additional parsed values, the warning tells you they were ignored. Turn Batch mode on before checking newline, comma, or semicolon-separated lists.
- Keep Issuer-aware length check on for common payment-card families. Turn it off only for private-label, legacy, or synthetic ranges where a valid test value may not match the built-in issuer profiles.
- Open Advanced for list cleanup. Remove duplicates collapses repeated batch entries, and Minimum digits filters short fragments before Luhn and issuer checks run.
- Read Validation Snapshot first, then inspect Validation Log. The focused row moves to the first Review or Fail result when the batch has one.
- Use Rule Trace for the selected row's length, issuer, IIN-6, IIN-8, MII, checksum, and verdict notes. Use Decision Mix, Issuer Mix, and Length Profile after the row-level issues are understood.
- Copy or download reports only when the output can be stored safely. CSV, DOCX, JSON, and chart exports can preserve full numbers or detailed summaries, so treat them like the original input.
Interpreting Results:
The verdict separates hard structural failures from values that need human context. A clean result is useful for test data and typo hunting, but it does not prove that a card exists, belongs to a person, or can be charged.
| Verdict | What happened | What to do next |
|---|---|---|
| Pass | The value has 12 to 19 digits, passes Luhn, and has no enabled issuer-length concern. | Use it only as structurally valid test or review data unless another trusted system confirms account status. |
| Review | Luhn passes, but the issuer prefix is unknown, or the detected issuer length looks unusual while issuer-aware review is on. | Check Rule Trace and the original source before treating the row as a normal card-family match. |
| Fail | The digit count is outside the broad range, or the Luhn checksum fails. | Look for a missing digit, extra digit, pasted fragment, merged values, or transcription error. |
Checksum is the row-level Luhn result. It can fail even when the prefix looks familiar, and it can pass when the issuer is unknown. Read it alongside Len, Issuer, and Rule Trace instead of treating one field as the whole answer.
IIN-6 and IIN-8 appear together because payment environments can still contain six-digit BIN assumptions while newer issuer-identification work may require eight leading digits. If a workflow depends on routing, fraud rules, product type, reporting, or truncation policy, confirm the required prefix length with the payment brand, acquirer, processor, or issuer data source.
The main false-confidence risk is a batch full of Pass rows. That only says the visible digits survived local structure checks. Privacy handling, masking, authorization, expiration, issuer routing, fraud screening, and live account status remain separate questions.
Technical Details:
Payment-card numbering is governed by ISO/IEC 7812. The standard defines the numbering system for identifying card issuers, including the issuer identification number and the Primary Account Number. Payment brands and issuers then define the active ranges, product rules, and acceptance decisions used by processing systems.
A local structural check uses only evidence present in the digits: broad length, issuer prefix pattern, Major Industry Identifier, and Luhn checksum. It does not query an issuer registry, card network, processor, authorization host, account database, or token vault.
PAN Structure
| Field | Position | Meaning in this validator |
|---|---|---|
| MII | First digit | Maps to a broad industry category such as banking, travel, merchandising, petroleum, healthcare, telecom, or national assignment. |
| IIN-6 | First six digits | Shows the traditional issuer slice still often called BIN in payment workflows. |
| IIN-8 | First eight digits | Shows the longer issuer slice needed for newer eight-digit BIN or IIN review. |
| Account digits | Middle digits | Remain part of the full PAN and should not be exposed unless the review truly requires them. |
| Check digit | Final digit | Participates in the Luhn mod-10 check. |
Formula Core
The Luhn rule reads digits from right to left. The check digit is added as-is, every second digit to its left is doubled, doubled values over 9 are reduced by 9, and the transformed sum must be divisible by 10.
| Right-to-left position | Value used in the sum | Reason |
|---|---|---|
i = 0, the check digit |
gi = di |
The check digit is already the balancing digit. |
| Even positions from the right | gi = di |
These digits are added without transformation. |
| Odd positions from the right | Double the digit; subtract 9 when the doubled value is above 9. | This is equivalent to adding the digits of the doubled value. |
| Final sum | S mod 10 = 0 |
The number passes the Luhn checksum. |
For 4111 1111 1111 1111, formatting is removed to produce 4111111111111111. From the right, eight positions are added unchanged, seven 1 digits become 2, and the leftmost 4 becomes 8. The transformed sum is 30, so 30 mod 10 = 0 and the checksum passes.
Issuer and Verdict Rules
Issuer labels come from built-in prefix families. They are useful for common test data and broad family checks, but they are not a live issuer lookup.
| Issuer label | Prefix rule | Expected lengths |
|---|---|---|
| Visa | Starts with 4 |
13, 16, 19 |
| Mastercard | 51 to 55, or 2221 to 2720 |
16 |
| American Express | 34 or 37 |
15 |
| Diner's Club | 300 to 305, 36, 38, or 39 |
14 |
| Discover | 6011, 65, 644 to 649, or 622126 to 622925 |
16, 19 |
| JCB | 3528 to 3589 |
16, 17, 18, 19 |
| UnionPay | Starts with 62 |
16, 17, 18, 19 |
| Maestro | Starts with 50, 56, 57, 58, 63, or 67 |
12 to 19 |
| Decision step | Rule | Outcome |
|---|---|---|
| Broad length | Fewer than 12 or more than 19 digits. | Fail |
| Luhn checksum | Transformed sum is not divisible by 10. | Fail |
| Unknown issuer | Luhn passes, but no supported prefix family matches. | Review |
| Issuer-aware length | Luhn passes, issuer is known, and length does not fit the detected issuer profile while the check is enabled. | Review |
| All enabled checks align | Length range, Luhn, prefix, and enabled issuer-length rules raise no concern. | Pass |
Privacy Notes:
The validation checks run in the browser after the page loads, and imported TXT or CSV content is read into the local page session. Luhn, length, prefix, duplicate removal, and batch summaries do not require an issuer or card-network lookup.
Local processing does not make full PAN handling low risk. Full numbers may appear in the input, tables, copied rows, JSON, CSV, DOCX, chart summaries, browser screenshots, downloads, or shared notes. A copied report can create the same exposure problem as the original list.
PCI DSS requires displayed PANs to be masked unless the viewer has a specific business need to see the full number. For ordinary testing, use payment-brand sandbox numbers, generated test data, or masked samples instead of live cardholder data.
Worked Examples:
Approved Visa-style test number
Entering 4111 1111 1111 1111 with Batch mode off produces one Validation Log row with Pass, issuer Visa, checksum Pass, and length 16. That is enough for a form-validation fixture, but not proof of a live account.
One mistyped digit in a list
A batch containing 4111111111111111 and 4111111111111112 places the second row in Fail. Validation Snapshot focuses that failing record, and Rule Trace identifies Luhn checksum as the failing rule. Correct the digit or replace the sample before using the list in tests.
Checksum passes but issuer needs review
A value can pass Luhn while the prefix is not recognized by the built-in issuer profiles. The row lands in Review with issuer Unknown. That may be expected for private-label or synthetic data, but it should not be presented as a standard card-family match without source context.
Short fragments copied with full numbers
A support note may include a four-digit ending beside a full test number. With Minimum digits set to 12, the short ending is dropped before validation and the summary badge reports the dropped entry. Lower the minimum only when you are deliberately checking digit extraction behavior.
FAQ:
Does Pass mean the card can be charged?
No. Pass means the digits satisfy local structure checks. Authorization, expiration, account status, fraud screening, and issuer approval are outside this result.
Why can a Luhn-valid number show Review?
Review appears when the checksum passes but the issuer prefix is unknown, or when issuer-aware length checking is enabled and the length does not fit the detected issuer profile.
Why did some pasted entries disappear?
Entries shorter than Minimum digits are dropped before validation. In single-number mode, additional parsed entries are ignored until Batch mode is turned on.
Why show both IIN-6 and IIN-8?
Six-digit BIN wording is still common, while eight-digit IIN review is important for newer issuer-identification work. Showing both slices helps compare old and new prefix expectations.
Should live card numbers be pasted here?
Use approved test numbers or masked samples whenever possible. Full PAN review should happen only when there is a documented need and suitable handling controls for the input and any exported output.
Glossary:
- PAN
- Primary Account Number, the full payment-card number being checked.
- IIN
- Issuer Identification Number, the leading issuer-identification digits in ISO/IEC 7812 terminology.
- BIN
- Bank Identification Number, an older payment-industry term still often used for issuer prefixes.
- MII
- Major Industry Identifier, the first digit of the PAN and a broad industry category clue.
- Luhn checksum
- The mod-10 check-digit method used to catch many common digit-entry errors.
- Issuer-aware length check
- The optional comparison between a detected card family and its expected digit counts.
References:
- ISO/IEC 7812-1:2017 Identification cards - Identification of issuers - Part 1: Numbering system, ISO.
- 8-digit BIN Industry Change, Visa.
- Can the full payment card number be displayed within a browser window?, PCI Security Standards Council.
- Computer for verifying numbers, Google Patents.