Query guide: JavaScript credit card regex

JavaScript regex credit card validator for regex.test checks

Use this page when a JavaScript expression needs to accept or reject card-number text before checkout code, form validation, or tokenization runs. Test digit counts, spaces, dashes, anchors, and failing samples online before copying the expression into regex.test().

Searches for javascript card number regex, credit card regex javascript, and check regex javascript usually point to a first-pass format problem. A regex can answer whether the value looks like a possible card number. It should not decide whether the card is valid for payment.

The common bug is a partial match. A loose digit expression can return true for card 4111111111111111 even when the field should contain only the number. For validator code, anchor the expression and test malformed examples beside accepted ones.

This workflow is JavaScript-first. It uses regular expressions as a browser-friendly format screen, then leaves Luhn checks, tokenization, authorization, and provider-specific rules to application and payment code.

How to validate a credit card regex

Decide whether the field accepts spaces, dashes, raw digits, or pasted card text before writing the expression.
Use an anchored regex when `regex.test(value)` must approve the whole card-number field.
Normalize display separators before checking the digit count if production code stores a cleaned value.
Keep pass and fail examples together: raw digits, grouped digits, trailing separators, short values, and text around a number.
Run a Luhn check and payment-provider validation after the regex passes, because regex only checks text shape.

Credit card expressions to test

Raw 13 to 19 digits

^\d{13,19}$

Pass: 4111111111111111, 378282246310005

Fail: 4111 1111 1111 1111, 12345, card 4111111111111111

Use after stripping spaces and dashes. This is the simplest format gate before a Luhn check.

Digits with optional spaces or dashes

^(?:\d[ -]?){12,18}\d$

Pass: 4111111111111111, 4111 1111 1111 1111, 4111-1111-1111-1111

Fail: 4111-1111-1111-, 4111 1111 1111, card 4111111111111111

Good for pasted checkout input when you still want full-field boundaries and no trailing separator.

Sixteen digits in four groups

^\d{4}(?:[ -]?\d{4}){3}$

Pass: 5555555555554444, 5555 5555 5555 4444, 5555-5555-5555-4444

Fail: 55555 5555 5555 4444, 5555 5555 5555, 5555-5555-5555-

Useful for forms that only accept a 16-digit display shape. It is too narrow for every card brand.

American Express display shape

^3[47]\d{2}[ -]?\d{6}[ -]?\d{5}$

Pass: 378282246310005, 3782 822463 10005

Fail: 3782 8224 6310 005, 37828224631000, 478282246310005

Shows why brand-specific validators need separate fixtures instead of one generic grouping rule.

Pass and fail samples for card-number validators

Should pass format

4111111111111111, 4111 1111 1111 1111, 3782 822463 10005

Should fail format

4111-1111-1111-, 4111 1111 1111, card 4111111111111111

Needs a second check

Any 13-19 digit value that passes regex but fails Luhn or provider rules

Copy-ready JavaScript regex.test examples

Normalize before regex.test

const normalized = value.replace(/[ -]/g, '');
const hasCardShape = /^\d{13,19}$/.test(normalized);

This keeps the regex small and makes the boolean result about digit count after display separators are removed.

Pair regex with a Luhn check

function luhnCheck(value) {
  let sum = 0;
  let shouldDouble = false;
  for (let i = value.length - 1; i >= 0; i -= 1) {
    let digit = Number(value[i]);
    if (shouldDouble) {
      digit *= 2;
      if (digit > 9) digit -= 9;
    }
    sum += digit;
    shouldDouble = !shouldDouble;
  }
  return sum % 10 === 0;
}

const normalized = value.replace(/[ -]/g, '');
const isPotentialCard = /^\d{13,19}$/.test(normalized) && luhnCheck(normalized);

Regex confirms a possible card-number shape. Luhn catches many mistyped numbers before provider validation.

Avoid loose partial matches

const loose = /\d{13,19}/;
loose.test('card 4111111111111111'); // true, but the full field is not clean

A loose pattern is useful for extraction, but it is too permissive for a field validator.

Test a credit card regex now

Open the live tester with a card-number expression and mixed samples already loaded. The failing rows are included to expose partial matches, trailing separators, short values, and pasted text around the number.

Test Credit Card Regex

Related Pages on Regex Tester

Open the live credit card regex tester

Load a JavaScript card-number pattern, flags, and pass/fail samples in the browser tester.

JavaScript regex validator

Build full-field validation expressions with anchors, examples, and JavaScript flag checks.

JavaScript regex.test validator

Check boolean validator behavior before using RegExp.test() in form code.

JavaScript regex flags tester

Confirm why card-number validators usually avoid global and sticky flags.

JavaScript regex.test generator

Turn plain-language validation rules into a small expression and sample bank.

JavaScript named groups tester

Inspect captured sections when a parser splits grouped card-like values.

JavaScript regex examples

Review copy-ready JavaScript expressions after validating behavior online.

Regex cheat sheet

Reference anchors, quantifiers, groups, character classes, and escaping rules.

JavaScript Credit Card Regex FAQ

Can regex validate a credit card number completely?

No. Regex can validate the text shape, such as digit count and separators. It cannot prove that a card is active, funded, authorized, or owned by the person entering it.

Should a JavaScript credit card regex use regex.test?

Yes for a first-pass format check. Use an anchored, non-global regex with `regex.test(value)`, then run Luhn and payment-provider validation after the format passes.

Should spaces and dashes be allowed in card-number input?

Usually yes for user entry, because pasted numbers often include grouping. Normalize spaces and dashes before checking digit count or sending the value to a payment provider.

Should card numbers be saved after regex validation?

Avoid storing card numbers unless your system is specifically designed and approved for that responsibility. Format validation should usually happen before handing the value to a payment provider.