ตัวตรวจสอบบัตรเครดิต

Validate any card number in your browser

This credit card validator checks whether a card number is correctly formed using the Luhn algorithm, the card brand and the expected length — all live as you type. Paste or type a number and you instantly see the detected brand and its logo, a pass/fail result for the Luhn checksum and the length, and an optional CVV and expiry format check beside it.

It is built for developers wiring up checkout forms and for anyone who wants to catch a typo before submitting a payment. Everything runs locally in your browser with no server involved, so it doubles as a private card number validator and Luhn check calculator you can use even on a corporate network with strict outbound traffic policies.

How the Luhn algorithm works

The Luhn algorithm, also called the mod-10 check, is the checksum formula almost every card network has used since Hans Peter Luhn patented it in 1954. Starting from the right, every second digit is doubled; if the result exceeds 9 you subtract 9, then all the digits are added together. When the total is divisible by 10 the number is valid. For example, 4242 4242 4242 4242 sums to 80 — divisible by 10 — so it is Luhn-valid.

The step-by-step Luhn breakdown on this page visualises that calculation for whatever you enter: it highlights the doubled digits, shows each digit's contribution to the running total, and prints the final sum and its remainder. It is the fastest way to understand how a Luhn check actually works, which is useful when you need to implement it yourself in code.

Detect the card brand from the IIN/BIN

The first six to eight digits of a card are its Issuer Identification Number (IIN) — historically called the Bank Identification Number (BIN) — and they identify the network. This card brand detector recognises Visa (starts with 4), Mastercard (51–55 and 2221–2720), American Express (34/37), Discover (6011, 644–649, 65), Diners Club (300–305, 36, 38, 39), JCB (3528–3589), UnionPay (62, 81) and Maestro, and shows the accepted lengths and CVV digit count for each in the card-brand rules table.

Brand detection fires as you type, so you can see within the first four digits whether the number you are entering is routing to Visa, Mastercard or Amex. This is the same check that payment forms on e-commerce sites perform to show the correct card logo in the input field.

How this compares to cardguru.io and creditcardvalidator.org

The most-searched free card validators are cardguru.io and creditcardvalidator.org. Both check the Luhn algorithm and detect the brand. Cardguru.io adds BIN lookup (issuing bank, country) but does this via a server-side API call, meaning your card number leaves the browser. Creditcardvalidator.org is purely client-side but shows display ads alongside the validator and does not offer test card generation or batch checking.

namso-gen.com and similar sites focus on test card generation, sometimes in bulk, but their generated numbers are used for fraud testing — the sites themselves acknowledge this — and the tools are mixed in with legitimate developer utilities in a confusing way. This validator separates concerns clearly: validate a number, generate a test card, or run batch validation, all offline and without any association with misuse.

Test card numbers, a generator and batch mode

The built-in test credit card numbers library lists Luhn-valid sandbox numbers (Stripe, Adyen and PayPal style) per brand, each clearly marked test-only, with copy and 'use' buttons. Need a fresh one? The generator builds a random, Luhn-valid number for any brand so you can fill a payment form in seconds without reaching for Stripe's documentation.

Batch mode lets you paste a column of numbers — from a spreadsheet export or a test fixture file — and get back a table with the brand, length, Luhn result and a valid/invalid verdict for each row. This is useful during QA when you have a list of numbers from a third-party data source and need to know quickly which ones are well-formed.

Validate credit card numbers in code — and what not to skip server-side

To validate credit card numbers in code, implement Luhn directly: reverse the digit string, double every second character (subtracting 9 when it exceeds 9), sum all values, and return valid when the total mod 10 equals 0 — roughly six lines in JavaScript or Python. Add a brand-prefix regex and a length check against the detected brand for full client-side format validation.

Use this check on the client for instant user feedback — it catches the most common typos before the network request fires. But never trust it alone: always run the real authorization server-side through a certified payment processor (Stripe, Adyen, Braintree, Square or similar). A Luhn pass is a format check, not a financial guarantee. There is no sign-up, no cost and no server here — every check happens in your browser, and the number you enter never leaves your device.

The Luhn algorithm in depth: history, mechanics and limits

Hans Peter Luhn patented the mod-10 checksum algorithm in 1954 while working at IBM. His original purpose was not credit cards — it was a general error-detection scheme for strings of digits entered by humans. Card networks adopted it because it is cheap to compute in hardware and catches the transcription mistakes that occur most often in practice. The mechanics: starting from the rightmost digit (the check digit itself) and moving left, you double every second digit. If doubling produces a value greater than 9 — meaning the original digit was 5 or more — you subtract 9, which is mathematically equivalent to summing the two digits of the doubled value. You then add every digit in the resulting sequence. If the grand total is divisible by 10, the number is Luhn-valid.

A worked example clarifies the steps. Take 4532015112830366. Starting from the right, the digits at even positions (second-from-right, fourth-from-right, and so on) are doubled: 6→12→3, 3→6, 0→0, 2→4, 1→2, 5→10→1, 3→6, 5→10→1. The remaining digits stay unchanged: 6, 8, 1, 1, 0, 2, 4. Summing the full sequence gives 70, which is divisible by 10, confirming the number is valid. You can verify any number through the step-by-step panel on this page.

The algorithm's real strength is its error-detection coverage. It catches every single-digit transcription error — changing any one digit to any other value will always break the checksum. It also catches approximately 90 percent of adjacent transpositions (swapping two neighboring digits), which are the second most common human entry error. What it does not catch: transpositions involving 0 and 9 in certain positions, and deliberate fraud where an attacker generates a syntactically valid number from scratch. No checksum algorithm can defend against a purposeful counterfeiter — that is the job of live bank authorization.

Card number structures by network: prefixes, lengths and the IIN standard

Every payment card number follows ISO/IEC 7812, which divides the Primary Account Number (PAN) into three parts: the Issuer Identification Number (IIN) at the front (historically six digits, extended to eight digits in the 2017 revision of the standard), the individual account identifier in the middle, and a single Luhn check digit at the end. The IIN uniquely identifies the card network and the issuing bank, which is why you can determine the brand from just the first few digits. Visa numbers start with 4 and are 16 digits long (a small number of legacy cards issued before 1995 are 13 digits). Mastercard uses the 51–55 prefix range and the 2221–2720 range, both producing 16-digit numbers — the 2xxx range was introduced in 2017 to expand capacity as the 5xxx range approached exhaustion.

American Express is distinctive in two ways: it uses 34 and 37 as its only prefixes, and its cards are 15 digits rather than 16, making it the only major global network with that length. Discover uses 6011, the range 622126–622925 (shared with UnionPay), the 644–649 range and 65, producing 16-digit numbers. Diners Club uses 300–305, 36 and 38, with a traditional length of 14 digits, though co-branded products issued through Mastercard's network are 16 digits. JCB (Japan Credit Bureau) numbers fall in the 3528–3589 prefix range and are 16 digits.

UnionPay deserves special attention because it is the world's largest card network by transaction volume, dominant in China and increasingly accepted globally. Its numbers start with 62 and range from 16 to 19 digits depending on the product. The 622126–622925 sub-range overlaps with Discover because the two networks have a reciprocal acceptance agreement in the United States. When validating, the overlap means you must check length and secondary prefix rules to correctly distinguish UnionPay from Discover for numbers in that range. The IIN extension to eight digits (ISO/IEC 7812:2017) was necessary because the global card market grew large enough that six-digit IINs were no longer sufficient to uniquely identify every issuing institution.

Magnetic stripe, EMV chip and contactless payments: how card security evolved

The magnetic stripe that appeared on cards in the 1960s encodes two data tracks in plaintext: Track 1 contains the cardholder name, card number and expiry; Track 2 contains the card number, expiry and a service code. Crucially, the stripe also stores a CVV (Card Verification Value) calculated by the issuing bank using a secret key — but this stripe CVV is deliberately different from the CVV2 printed on the back of the card. The reason for two values is that a thief who reads the stripe with a $20 skimmer device and clones it onto a blank card gets the stripe CVV automatically, but does not get the printed CVV2, which is needed for card-not-present (online) transactions. Cloning a magnetic stripe is trivially easy, which drove the global migration to chip cards.

The EMV chip standard (named for Europay, Mastercard and Visa, who co-developed it in 1994) fundamentally changed the security model. Instead of storing static data, the chip holds a private key that never leaves the silicon. When a terminal requests payment, the chip generates a unique cryptographic transaction certificate using that private key and transaction-specific data — amount, merchant, timestamp. The terminal sends this certificate to the issuing bank, which validates it with the corresponding public key. Because every transaction produces a different, mathematically unforgeable certificate, cloning the chip is computationally impossible. The United States was late to adopt EMV: the liability shift — where the party that had not adopted chip technology bore fraud losses — only took effect in October 2015, after which US chip adoption accelerated sharply.

Contactless payments (ISO/IEC 14443, operating at 13.56 MHz) use the same EMV cryptographic mechanism but over a radio link with a tap range of 1–4 cm. Apple Pay, Google Pay and Samsung Pay go a step further: they replace the real card number with a Device Account Number (DAN), also called a token or virtual card number, that is stored in the device's Secure Element or Trusted Execution Environment. The DAN is different from the real PAN and is specific to the device and merchant. Even if a merchant's systems are breached and the DAN is stolen, it cannot be used elsewhere because the token is cryptographically bound to the device. This tokenization means the real card number is never transmitted to the merchant at all during an Apple Pay or Google Pay transaction.

PCI DSS compliance, card data security and the role of CVV2

The Payment Card Industry Data Security Standard (PCI DSS) is a security framework maintained by the PCI Security Standards Council, founded in 2004 by Visa, Mastercard, American Express, Discover and JCB. It applies to any business that stores, processes or transmits cardholder data. The standard's 12 top-level requirements cover building and maintaining a secure network (firewall configuration, avoiding vendor-supplied defaults), protecting stored cardholder data (encryption of PANs, prohibition on storing the full magnetic stripe or CVV), controlling access to cardholder data, monitoring and testing networks, and maintaining an information security policy. Compliance is validated at four merchant tiers: Tier 1 processes more than six million card transactions per year and must undergo an annual on-site audit by a Qualified Security Assessor; Tier 4 processes fewer than 20,000 e-commerce transactions per year and typically self-assesses using a simplified questionnaire.

The most dangerous piece of data in this framework is the full card number, also called the Primary Account Number (PAN). Storing the PAN unencrypted triggers the highest-level PCI DSS compliance requirements. Most businesses avoid this entirely by tokenizing: instead of storing the PAN, they store a token issued by their payment processor — an opaque reference that can be used to initiate future charges but cannot be decoded into the real PAN by anyone except the processor. The merchant's database also stores only the last four digits of the card, which is enough for customer service identification and is considered non-sensitive under PCI DSS.

The CVV2 (also called CVC2 by Mastercard and CID by American Express) is the 3- or 4-digit code printed on the card but deliberately absent from the magnetic stripe data and prohibited from being stored after authorization under PCI DSS. This separation is intentional: a thief who steals a database of card numbers and expiry dates still cannot complete online transactions without the CVV2, because the card-not-present authorization flow requires it. American Express prints its 4-digit CID on the front of the card; Visa, Mastercard and Discover print a 3-digit code on the signature panel on the back. When this validator checks the CVV field, it confirms only the expected digit count for the detected brand — the actual value can only be verified by the issuing bank during a live transaction.