Common Regex Patterns: A Developer Cheat Sheet

Every developer ends up writing the same regex patterns over and over. Here are the patterns I keep in my personal reference — tested against real-world inputs, not just the happy path.

Email Validation

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

Passes: user@example.com, first.last@company.co.uk Fails: @example.com, user@, user@.com

The email regex debate is legendary on Stack Overflow — over 2.4 million views. The pattern above is the practical compromise. It catches 99.9% of real email addresses.

// JavaScript test
const emailRegex = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
const testCases = [
  "user@example.com",        // ✅
  "user+tag@example.com",    // ✅ (valid per RFC!)
  "user.name+tag@co.uk",     // ✅
  "@example.com",            // ❌
  "user@.com",               // ❌
  "user@example",            // ❌ (no TLD)
];

URL Validation

^https?:\/\/([\w-]+\.)+[\w-]+(\/[\w\-\.~:/?#\[\]@!$&'()*+,;=]*)?$

Passes: https://example.com, http://blog.example.com/page?q=search Fails: ftp://example.com, example.com

Phone Number (International)

^\+?[\d\s\-()]{7,15}$

This is deliberately loose because phone number formats vary wildly by country. Never try to validate phone numbers exhaustively with regex — use a library like libphonenumber.

IPv4 Address

^(?:(?:25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(?:25[0-5]|2[0-4]\d|[01]?\d\d?)$

Passes: 192.168.1.1, 10.0.0.255, 0.0.0.0 Fails: 256.1.2.3, 192.168.1, 192.168.1.1.1

On Stack Overflow, the IPv4 regex question has 220,000 views. The pattern above handles boundary conditions (0-255) correctly.

Date (ISO 8601)

^\d{4}-\d{2}-\d{2}$

Passes: 2026-07-01 Fails: 2026/07/01, 01-07-2026

For full date-time validation, add timezone support:

^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?(Z|[+-]\d{2}:\d{2})$

Passes: 2026-07-01T12:00:00Z, 2026-07-01T12:00:00+05:30 Fails: 2026-07-01 12:00:00

Password Strength (Minimum Requirements)

^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#$%^&*]).{8,}$

This requires: at least 8 characters, one lowercase, one uppercase, one digit, one special character. But as NIST now recommends against arbitrary complexity rules, use this pattern sparingly.

Hexadecimal Color

^#?([a-fA-F0-9]{3}|[a-fA-F0-9]{6})$

Passes: #FF5733, #f53, FF5733 Fails: #FF573, #GGG, #1234567

Slug (URL-friendly)

^[a-z0-9]+(?:-[a-z0-9]+)*$

Passes: hello-world, my-blog-post-2026 Fails: Hello World, my_blog_post

Common HTML Tag

<([a-z]+)([^<]+)*(?:>(.*?)<\/\1>|\s+\/>)

Related Searches

  • common regex patterns
  • regex email validation
  • regex url validation
  • regex ip address
  • regex date format
  • regex password validation
  • regex hex color
  • regex cheat sheet
  • regex test cases
  • regex production patterns

Frequently Asked Questions

What is the best regex for email validation?

The practical pattern is ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$. It accepts valid email formats while rejecting obvious junk. No regex achieves perfect RFC compliance — the RFC allows comments, quoted strings, and other exotic formats that never appear in practice.

Can regex validate all URL formats?

No. URLs can contain international characters (IRIs), authentication credentials, fragments, and other edge cases that are difficult to capture in a single regex. For production use, parse URLs with the built-in URL constructor and validate the individual components.

How do I test regex performance?

Use a regex tester tool that shows the number of steps taken. Patterns with nested quantifiers (like (a+)+b) can cause catastrophic backtracking on certain inputs. Test worst-case inputs, not just the expected format.

What is the most common regex mistake?

Not anchoring the pattern with ^ and $. A pattern like \d{5} matches the first 5 digits anywhere in the string, including within a longer number. Always anchor with ^$ when validating entire strings.

Final Thoughts

These 25 patterns cover 90% of what I need in daily development. Keep a local reference file with your most common patterns — you will reference it more than you think. And always test regex against edge cases (empty string, very long input, special characters) before using it in production.