Regular expressions are one of the most powerful tools in a developer's toolkit, and they are especially essential for US developers who need to validate American data formats. Phone numbers, ZIP codes, Social Security numbers and email addresses all have specific patterns that regex can verify. In this guide, we cover the most common US data validation patterns and show you how to test them with free browser-based tools.
Regex Basics for US Developers
A regular expression (regex) is a pattern that describes a set of strings. Regex uses special characters to represent repetition, alternatives, character classes and anchors. For US data validation, the most commonly used regex features are:
\d matches any digit (0-9). {n} matches exactly n repetitions. {n,m} matches between n and m repetitions. ? means optional (0 or 1). [abc] matches any one of the characters listed. ^ and $ anchor the pattern to the start and end of the string.
For US developers, the key is to write patterns that are strict enough to catch invalid data but flexible enough to accept valid variations. American phone numbers, for example, can be written as 5551234567, 555-123-4567, (555) 123-4567 or +1 555 123 4567. A good regex accepts all valid formats while rejecting obviously invalid ones.
Validating US Phone Numbers
US phone numbers consist of a 3-digit area code, a 3-digit exchange code and a 4-digit subscriber number, for a total of 10 digits. An optional country code (+1) may precede the number. The components may be separated by spaces, hyphens, periods or parentheses, or not separated at all.
A regex that accepts the most common US phone number formats:
^+1?\s?\(?\d3\)?[\s.-]?\d3[\s.-]?\d4$
This pattern matches: 5551234567, 555-123-4567, (555) 123-4567, +1 555 123 4567, 555.123.4567 and other common variations. However, for production use, a more robust approach is to strip all non-digit characters first, then validate that the result is exactly 10 digits (or 11 digits starting with 1 for the country code). This avoids the complexity of handling every possible formatting variation in a single regex.
You can test this pattern using the Regex Tester, which lets you enter a pattern and test it against sample phone numbers to see which match and which do not.
Validating US ZIP Codes
US ZIP codes come in two formats: the basic 5-digit format (12345) and the ZIP+4 format (12345-6789), which adds a hyphen and 4 more digits for more precise geographic routing. Both formats are valid, and your validation should accept both.
For 5-digit ZIP codes only:
^\d{5}$
For both 5-digit and ZIP+4:
^\d{5}(-\d{4})?$
The ? after the group makes the ZIP+4 extension optional, so both 12345 and 12345-6789 are accepted. This is the recommended pattern for most US applications.
Note that this regex validates the format only — it does not verify that the ZIP code actually exists. For address verification, use the USPS address validation API or a third-party address validation service. Format validation is the first line of defense; address verification is the second.
Validating Social Security Numbers
Social Security numbers follow the format XXX-XX-XXXX (9 digits with hyphens). The SSA has specific rules about which numbers are valid: the area number (first 3 digits) cannot be 000, 666 or 900-999; the group number (middle 2 digits) cannot be 00; and the serial number (last 4 digits) cannot be 0000.
A basic format-checking regex:
^\d{3}-\d{2}-\d{4}$
A more thorough regex that enforces SSA rules:
^(?!000|666|9\d2)\d3-(?!00)\d2-(?!0000)\d4$
Security warning: Never store SSNs in client-side code, JavaScript variables or logs. If you are validating SSN format, do it server-side and encrypt the SSN before storing it. Client-side validation is acceptable for format checking (before sending to the server), but the actual SSN should never be persisted in the browser. The Regex Tester processes data in your browser, so test patterns with dummy data, not real SSNs.
Validating Email Addresses
Email validation with regex is a famously contentious topic. The official email format specification (RFC 5322) is complex enough that a fully compliant regex is thousands of characters long. In practice, most developers use a simplified pattern that catches the vast majority of valid emails while rejecting obviously invalid ones.
A commonly used practical pattern:
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$
This matches the basic structure of an email address: local-part@domain.tld. It rejects addresses without @, without a domain or without a top-level domain. However, it does not validate every RFC rule — for example, it does not allow quoted local parts or IP address domains, which are technically valid but extremely rare.
The best practice for email validation is: use a simple regex for format checking, then send a verification email with a confirmation link. This is the only reliable way to verify that an email address is not just well-formed but actually exists and is accessible by the user. You can test email format patterns with the Email Validator, which checks format and optionally verifies the domain's MX records.
Testing Regex Online
Testing regex patterns is essential before deploying them to production. A pattern that works on your test data might fail on edge cases you did not consider. The Regex Tester lets you enter a pattern and test it against multiple sample strings, showing which match and which do not. The tool runs entirely in your browser, so you can safely test patterns with sensitive data formats without sending anything to a server.
For developers who need to generate regex patterns from examples, the Regex Generator helps create patterns for common use cases. Describe what you want to match, and the tool suggests a regex pattern you can refine and test.
Regex Best Practices
Keep patterns readable. Complex regex is hard to maintain. If a pattern is more than 50 characters, consider breaking it into named groups or using a multi-step validation approach. Add comments explaining what each part of the pattern matches.
Test edge cases. Test your pattern against both valid and invalid examples. For phone numbers, test 10-digit, 11-digit, 7-digit, letters, empty string and international formats. Make sure your pattern accepts all valid formats and rejects all invalid ones.
Do not over-validate. A regex that is too strict will reject valid data. For example, a phone number regex that requires parentheses around the area code will reject 555-123-4567, which is a perfectly valid format. When in doubt, be permissive with formatting and strict with content.
Sanitize before validating. For formats like phone numbers, strip non-digit characters first, then validate the digit sequence. This is more reliable than trying to match every possible formatting variation in a single regex. The Data Sanitizer can help strip unwanted characters from input.
Never rely on client-side validation alone. Client-side regex validation improves user experience by catching errors before form submission, but it can be bypassed. Always re-validate on the server side. Client-side validation is for convenience; server-side validation is for security.
For US developers, mastering regex for data validation is a fundamental skill. Bookmark the Regex Tester and Regex Generator for instant pattern testing and generation — both free, both browser-based, both secure.