The Regex Cheat Sheet Developers Actually Need
· Tutorials
Battle-tested regex patterns for email validation, URL extraction, HTML stripping, and slug generation. No theory — just patterns that work in production.
Last updated: July 10, 2026 · 4-minute read
I have tested every pattern below across at least 200 real-world inputs — scraped emails, user-submitted URLs, messy HTML from CMS exports, and filenames with every special character imaginable. These are the ones that survived.
Email Validation — The One That Actually Works
Most email regexes are either too permissive or too restrictive. The W3C HTML5 spec uses a regex that passes "@" as valid. RFC 5322's full implementation is 6,000 characters long. Neither of those is useful.
Here is what I use in production:
It covers 99.7% of real-world email addresses and rejects the obvious garbage. It will not catch every edge case per the RFC — if you need that, use a proper validation library like isemail. But for sign-up forms and contact inputs, this is the sweet spot between accuracy and readability.
Someone on X posted a 300-character monster regex that was "RFC-compliant." The replies were a mix of admiration and concern. My position: if your regex needs a comment block to explain what it does, it belongs in a library, not inline.
URL Extraction From Arbitrary Text
Pulling URLs out of user-generated content is a surprisingly hard problem. You need to handle http and https, optional www, paths with query parameters, and avoid matching trailing punctuation.
This handles most cases. It will not match URLs without a protocol — which is intentional. If someone types example.com in plain text, you probably should not auto-link it without confirmation. That is how you end up linking random words that happen to end in .com.
Stripping HTML Tags
The classic approach uses a regex, and yes, I know the "you cannot parse HTML with regex" argument. For stripping tags — not parsing structure — this works fine:
This removes all HTML tags and leaves the text content. It will break on malformed HTML with unescaped < characters in attribute values. If you are processing untrusted HTML, use the browser's DOMParser or a sanitizer library like DOMPurify instead. But for cleaning up CMS output where you control the source, this one-liner has saved me hundreds of lines of code.
A Reddit thread on r/webdev had a great point about this: regex HTML stripping is fine until it is not, and the moment it is not, you have a XSS vulnerability. Use your judgment.
Slug Generation
Turning a title into a URL-safe slug is a pattern I reach for constantly. Here is the version I use:
This handles multiple spaces, special characters, and trims leading and trailing dashes. It does not handle Unicode transliteration — café becomes caf-, not cafe. For that, add a transliteration step with a library like transliteration before slugifying.
Matching Phone Numbers (Indian Context)
Since I work primarily with Indian users, here is a pattern that catches most Indian mobile numbers:
It handles +91 9876543210, 09876543210, and plain 9876543210. It will not match landlines or numbers starting with 0-5 (those are not valid mobile prefixes in India). If you need to handle landlines, you are in for a much longer regex — Indian telecom numbering is not clean.
Quick Reference Table
When to Stop Using Regex
There is a point where regex becomes the wrong tool. If you are trying to parse nested structures, validate complex grammars, or handle context-sensitive matching, use a proper parser. I hit that wall last year trying to match nested Markdown links with a regex — three hours later I switched to a state machine and solved it in 20 minutes.
For everything else — form validation, text cleanup, simple extraction — regex is still the fastest path from problem to solution. Browse the projects to see where these patterns show up in production, or check the blog for more technical deep dives.
---
Not affiliated with any regex library or tool. Tools used: JavaScript, VS Code with Regex Preview extension, regex101.com.