KEY TAKEAWAYS
- Format ≠ status: passing Luhn, length, expiry and CVV rules does not mean the account is active.
- Runs locally: no server calls, no storage, no charge.
- Brand-aware: number length and CVV digits follow the detected network.
- Live answers require a real checker run with an account — never simulated.
This CC checker validates a card number the way a payment form does: it verifies the Luhn checksum, detects the card brand, extracts the BIN/IIN, and checks the expiry and CVV format. Everything runs in your browser — nothing is sent to a server, stored, or charged. It tells you whether a card entry is well-formed; it does not tell you whether an account is active.
What a CC checker actually does
A CC checker (card checker or credit card validator) applies local rules to a card entry before it is used: the checksum catches typos, the prefix identifies the network, the length and CVV rules depend on the brand, and the expiry must be plausible. Payment forms run exactly these checks because rejecting a mistyped number locally is faster and cheaper than sending it to an issuer.
What this page does not do is contact a gateway or an issuer. There is no network request behind the form. That makes it safe, instant and free — and it also means the result is strictly about format, never about whether an account is open, funded or chargeable.
Well-formed vs live: the distinction that matters
These are two different questions:
- Is this card entry well-formed? — Luhn, brand, length, expiry, CVV. This page answers that, offline.
- Is this account live? — only an issuer response can answer that. On C4CHECK this requires a real checker run through a gateway with an account; it is never simulated here.
A number can pass every format check and still be closed, blocked or non-existent. Conversely, a valid number can fail a local rule if a brand uses an unusual length or the CVV is entered for the wrong brand. If you need the live/dead answer, use the live checkers — new accounts can start with the current free checks promotion.
How card validation works
1. The Luhn checksum
The final digit of a card number is a check digit computed with the Luhn (mod-10) algorithm:
- Starting from the rightmost digit, double every second digit. If doubling gives more than 9, subtract 9.
- Add all resulting digits together.
- If the total is divisible by 10, the number is well-formed.
This catches single-digit typos and most adjacent swaps. 4307 4106 7729 3014 passes; changing any single digit almost always makes it fail. The same algorithm is documented in our Luhn implementation guide and available as a focused Luhn validator.
2. BIN / IIN prefixes
The first six to eight digits identify the issuer range: network (Visa, Mastercard, …), and often the issuing bank and country. This page shows the first six digits and the detected network. For a deeper lookup, use the BIN lookup or IIN lookup tools. BIN metadata describes the issuer range — it says nothing about an individual account.
3. Length and CVV rules by brand
| Brand | Typical number length | CVV digits | Common prefixes |
|---|---|---|---|
| Visa | 13, 16 or 19 | 3 | 4 |
| Mastercard | 16 | 3 | 51–55, 2221–2720 |
| American Express | 15 | 4 | 34, 37 |
| Discover | 16 or 19 | 3 | 6011, 65, 644–649, 622126–622925 |
| JCB | 16–19 | 3 | 3528–3589 |
| Diners Club | 14–19 | 3 | 300–305, 36, 38 |
| UnionPay | 16–19 | 3 | 62 |
| Maestro | 12–19 | 3 | 5018, 5020, 5038, 5893, 6304, 6759, 6761–6763 |
4. Expiry
A card is valid through the end of its expiry month. 09/29 means September 2029, not September 1st. This validator rejects months outside 01–12, dates already in the past, and implausibly distant dates.
Why a card number fails validation
- A typo in any digit — the Luhn checksum fails (the most common cause by far).
- Wrong CVV length — American Express uses 4 digits; most other brands use 3.
- Expired date — the month has already passed.
- Separator or whitespace problems — spaces, dashes and slashes are fine here, but some forms reject them.
- Test numbers mixed with real entries — sandbox numbers are well-formed but not live; keep them separate.
- Brand rules differ — a 15-digit Visa or a 16-digit Amex will fail length expectations.
CC checker vs CVV checker vs BIN checker
The names overlap, but the questions are different:
- CC checker / card validator — is the whole entry well-formed? (this page)
- CVV checker — does the security code match the brand's expected format? (part of this page; see also CC vs CVV vs CCN terms)
- BIN checker — which issuer and country does this prefix belong to? (BIN lookup)
- Live checker — does the issuer consider the account active right now? (real gateway checks, account required)
Using test numbers the right way
For form testing, use published sandbox numbers and clearly labelled fixtures — never real card data. Our test card numbers page lists well-known values, and the generator produces Luhn-valid test numbers for development. Keep production data out of test environments, and test data out of production.
A worked Luhn example
Take the test number 4307 4106 7729 3014. Reading from the right and doubling every second digit gives 8, 3 (4×2−9=…, adjusted), 1, 8, 8, 4, 6, 2, 3, 4, 1, 4, 8, 6, 1, 8. Summing the adjusted digits yields 86, which is not a multiple of 10 — but the number is only valid when the check digit is included correctly. Our validator performs this in one pass and reports the checksum alongside the brand and length rules, so you see which rule failed instead of a generic “invalid card” message. If you are implementing the same check in code, the JavaScript and Python guides reproduce the algorithm line by line.
Where validation sits in a payment flow
A payment form validates locally first, then asks the issuer through an acquirer. Local rules — checksum, brand length, expiry, CVV format — reject obvious mistakes before any network call. The authorization request then asks a different question: does the issuer allow this transaction now? The issuer can approve, decline, challenge or fail to answer; a timeout is not a decline. That is why “validator passed” and “checker says live” are not interchangeable statements, and why a live/dead result always needs a timestamp.
For batch work, the same order applies: clean and validate the list, deduplicate it, then run the paid checks. The CSV cleaner normalises separators and removes duplicates; the bulk checking guide covers throughput and retry budgeting once the list is clean.
When the validator disagrees with a gateway
Occasionally a number passes this page but a gateway rejects the input as malformed. Almost always the cause is a brand nuance: an unusual length accepted by one system, a CVV that belongs to a different brand, or separators that a third-party form strips incorrectly. Re-enter the number without spaces, confirm the expiry month and the CVV length, and retry once. If the same entry fails consistently, treat it as a data-quality problem rather than a checker problem — do not loop a malformed entry through paid requests.
Privacy and data handling
This validator is deliberately client-side: there is no endpoint, no log and no analytics event containing what you type. The page cannot store a card number even if it wanted to. For live checks, the platform's normal account, billing and retention rules apply — see the privacy policy.
Related tools and guides
- Luhn validator — checksum-only validation for one number or a list
- Card expiry checker — focused MM/YY validation
- BIN lookup — issuer and country behind a prefix
- Credit card validator guide — the three validation layers explained
- CC vs CVV vs CCN vs CCV — the acronyms, decoded
- Bulk checking throughput — planning larger runs