Credit Card Number (Generic)
Match generic credit card numbers in grouped or continuous 16-digit format.
What Is This?
This regex pattern matches standard 16-digit credit card numbers in both continuous (1234567890123456) and grouped (1234 5678 9012 3456 or 1234-5678-9012-3456) formats. It validates the format but does not check the Luhn algorithm — that requires additional code.
How to Use This Pattern
Pattern
^(?:\d{4}[ -]?){3}\d{4}$
^(?:\d{4}[ -]?){3}\d{4}$Usage
Use this pattern for basic format validation of credit card numbers in payment forms. Always combine with Luhn algorithm check for full validation. Never store full credit card numbers — use PCI-compliant tokenization services. This pattern accepts spaces or hyphens as digit group separators.
Examples
Matches: 4111111111111111, 4111 1111 1111 1111, 4111-1111-1111-1111. Non-matches: 1234-5678-9012, not a card, 1111 2222 3333 4444 5555
Matches: 5500000000000004, 340000000000009, 3000000000000004. Non-matches: 1234 5678 9012 345, abcd efgh ijkl mnop, 1234-5678-9012-3456-7890
Related Entries
More from this reference:
Email Address Validation
Validate email addresses with a standard pattern covering most common formats.
URL Pattern
Match HTTP and HTTPS URLs with optional port, path, query string, and fragment.
Phone Number (US/International)
Match US and international phone numbers with optional country code and separators.
Date (YYYY-MM-DD)
Match dates in ISO 8601 YYYY-MM-DD format with basic month and day validation.
Frequently Asked Questions
Does this pattern validate the Luhn algorithm?
No. Regex cannot perform the Luhn checksum validation. After matching the format, implement the Luhn algorithm in code to verify the check digit. Most payment libraries include both format and Luhn validation.
Should I validate card numbers client-side?
Yes, for immediate user feedback. But always validate server-side as well for security. Never trust client-side validation alone for payment processing.