Form Field Validation Rules & Regex Patterns

Proper form validation improves user experience and data quality. This reference provides regex patterns, minimum/maximum lengths, and best practices for common form fields including email addresses, passwords, phone numbers, credit cards, URLs, and postal codes. Use these patterns in HTML5 validation, JavaScript, or server-side validation — but remember that client-side validation is for UX, while server-side validation is for security.

When You Need This Table

Building forms with proper input validation
Setting up validation libraries like Zod, Yup, or Joi
Writing regex patterns for specific input formats
Deciding on appropriate character limits for fields
Ensuring accessibility with helpful error messages

Common Field Validation Patterns

Field	Regex Pattern	Min	Max	Notes
Email	^[^\s@]+@[^\s@]+\.[^\s@]+$	5	254	RFC 5321 max; simpler regex for UX
Password	(?=.[a-z])(?=.[A-Z])(?=.*\d).+	8	128	At least 1 upper, lower, number
Username	^[a-zA-Z0-9_-]+$	3	30	Alphanumeric, underscore, hyphen
Phone (US)	^\+?1?[-.\s]?$?\d{3}$?[-.\s]?\d{3}[-.\s]?\d{4}$	10	15	Flexible formatting
Phone (Intl)	^\+[1-9]\d{1,14}$	8	15	E.164 format
ZIP Code (US)	^\d{5}(-\d{4})?$	5	10	5-digit or ZIP+4
Postal Code (CA)	^[A-Za-z]\d[A-Za-z][ -]?\d[A-Za-z]\d$	6	7	A1A 1A1 format
Credit Card	^\d{13,19}$	13	19	Luhn algorithm for validation
CVV/CVC	^\d{3,4}$	3	4	3 digits (Visa/MC) or 4 (Amex)
URL	^https?://[^\s]+$	10	2048	Browser limit varies
Date (ISO)	^\d{4}-\d{2}-\d{2}$	10	10	YYYY-MM-DD format
Name	^[\p{L}\s'-]+$	1	100	Unicode letters, spaces, hyphens, apostrophes

HTML5 Input Types with Built-in Validation

Input Type	Built-in Validation	Notes
<input type="email">	Built-in email format	Browser validates @ and domain
<input type="url">	Built-in URL format	Requires http:// or https://
<input type="tel">	None (just keyboard)	Use pattern for validation
<input type="number">	Numeric only	Use min/max/step attributes
<input type="date">	Date picker	Use min/max for date range
<input type="password">	None (just masks)	Use pattern or JS validation

Validation Best Practices

Validate on blur, not on every keystroke
Show errors inline near the field
Use clear, actionable error messages
Mark required fields with asterisk (*) or "required"

Security Considerations

Never trust client-side validation alone
Always validate and sanitize on the server
Use parameterized queries to prevent SQL injection
Encode output to prevent XSS attacks

Balancing Strictness and Usability

Overly strict validation frustrates users. The classic example is email validation — the RFC-compliant regex is absurdly complex, and even "simple" patterns reject valid emails. Use a basic pattern (check for @ and a dot) plus email verification for signup flows. The same applies to phone numbers — international formats vary wildly, so be flexible.

For passwords, modern guidance (NIST 2023) recommends focusing on length over complexity rules. A 16-character passphrase is more secure than "P@ssw0rd!" and easier to remember. Consider showing a password strength meter instead of rigid requirements.

Real-time validation should feel helpful, not punitive. Validate on blur (when the user leaves a field) rather than on every keystroke. Show a green checkmark when fields are valid, and keep error messages specific: "Password must be at least 8 characters" is better than "Invalid password."

Related Resources

Character Counter Password Requirements

Best Practices for Form Validation Implementation

When implementing form validation, always combine client-side validation with server-side checks to ensure data integrity. Client-side validation improves user experience by providing immediate feedback, while server-side validation prevents malicious inputs. Use HTML5 attributes like required and minlength for basic validation, but supplement with JavaScript for complex rules. For regex patterns, test edge cases like international characters and special symbols. Avoid overcomplicating validation rules—simpler patterns reduce user frustration. For sensitive data like credit card numbers, follow PCI-DSS guidelines and consider using tokenization instead of raw field validation. Always display clear error messages that guide users to fix issues, rather than generic 'invalid input' notifications.

Common Validation Pitfalls and Solutions

Many developers mistakenly rely solely on regex for form validation, which can create accessibility issues and false rejections. For example, strict email regex patterns might block valid addresses with special characters. Instead, use a two-step approach: basic format validation followed by server-side confirmation. Another common issue is inconsistent phone number validation—consider allowing flexible formats like +44 20 7946 0012 or 0207 946 0012 for UK numbers. Date validation can also be tricky; avoid relying on specific formats and use JavaScript's Date.parse() to handle various user inputs. For password fields, focus on length requirements rather than complex character rules, as recent studies show length is more critical for security than character diversity.

International Considerations in Form Validation

When building forms for global audiences, adapt validation rules to local requirements. For instance, UK postal codes follow the A9 9AA pattern, while Canadian postal codes use A1A 1A1. Phone number validation should accommodate international formats using E.164 standards (+44 for the UK, +1 for North America). Date formats also vary—while the US prefers MM/DD/YYYY, most countries use DD/MM/YYYY. For names, avoid ASCII-only restrictions to accommodate accented characters and non-Latin scripts. When validating URLs, remember that internationalized domain names (IDNs) use Punycode encoding. Always test validation rules with real-world examples from target regions to ensure compatibility and reduce user errors.