Why Use a Regex Cheat Sheet Instead of Writing One?
Most of the strings developers need to match against, email addresses, URLs, IPv4 addresses, UUIDs, phone numbers, dates, are already-solved problems. Writing one of these common regex patterns from scratch is an easy way to accidentally miss an edge case: an email regex pattern that's too permissive, an ipv4 regex pattern that accepts 999 as an octet, a phone number pattern that doesn't match the way real numbers are actually formatted. This regex cheat sheet collects 26 of these regex examples in one place, each one already tested against its own working example, so you can copy paste regex directly into your code instead of debugging your own version against the same edge cases everyone else has already hit. Every pattern lists its flags, a plain-English description of what it matches, and a live example you can test against your own data before you commit to it.
How to Test a Pattern Against Your Own Data
Type into the search box to filter by name, description, or category, or use the category dropdown to browse one group at a time (web, network, dates, numbers, IDs, security, code). Paste or type your own sample text into the "Test input" box, then click the play icon on any pattern card to test it. The panel on the right shows "Match found" or "No match" along with the exact matched substring, using the same flags shown on the pattern card, so what you see here is exactly what that pattern would do in your own code.
Patterns Covered in This Library
Web patterns cover email addresses, an HTTP/HTTPS url regex pattern, hex colors, CSS class selectors, US phone numbers, and URL-safe slugs. Network patterns cover IPv4 and IPv6 addresses, MAC addresses, and CIDR notation. Date patterns cover ISO 8601 dates and datetimes plus US MM/DD/YYYY format. Number patterns cover integers, decimals, and US currency amounts. ID patterns cover UUID v4. Security patterns cover strong passwords, usernames, and JWT tokens. Code patterns cover semantic versions (SemVer), Git commit hashes, and HTML tags. System patterns cover Unix and Windows file paths and file extensions.
Known Limitations of Regex-Based Matching
A regex can confirm a string has the right shape, it can't confirm the thing it describes is real: the email pattern here validates format only, it can't confirm the mailbox exists. The HTML tag pattern matches a single element and its content using a non-greedy search for the nearest matching closing tag, which works for typical markup but isn't a real HTML parser, deeply nested elements of the same tag name or malformed markup can produce an unexpected match. The US phone number pattern enforces the real North American Numbering Plan rule that an exchange code can't start with 0 or 1, so it correctly rejects numbers real US carriers wouldn't issue either, but it doesn't validate international formats. These are disclosed here rather than silently glossed over, the same way any regex-based tool should be honest about where pattern matching ends and real validation begins.