Regex Cheat Sheet

Character classes to assertions to ready-made patterns, one page, plain-language, filterable.

Regex syntax is dense — lookahead, lazy quantifiers and named groups are all true statements until you have not used them in a week. This sheet is organized in six sections: characters & classes, quantifiers, groups & references, assertions, flags, and common patterns, each entry explained in one plain sentence, filterable by syntax or purpose (search "lookahead" or "quantifier").

The common-patterns section collects the high-frequency regexes — email, URL, ISO date, strict-range IPv4, phone numbers — with their limits stated: an email regex is a first-pass filter whose real validation is a sent mail, and HTML should not be parsed with regex at all.

Greedy vs lazy: the default trap

Quantifiers are greedy by default: .* eats to the end of the line and backs off. Extracting tag contents with <.*> swallows the whole line; <.*?> matches one tag at a time. The sheet lists both forms side by side — most "my regex ate too much" bugs are a missing ?.

Do assertions consume characters?

No. (?=abc) requires "abc follows" without advancing the match, so chained assertions like (?=.*\d)(?=.*[a-z]) check several conditions at one position — the idiomatic password-strength pattern. Lookbehind (?<=…) mirrors it for "what came before".

Frequently asked questions

Which regex dialect is this?
JavaScript (ECMAScript) first, heavily overlapping with PCRE; per-environment differences (lookbehind support, \d Unicode behavior) defer to your runtime's documentation.
How do I test these patterns?
Open the live regex tester from the link at the top of the page — highlighting and capture groups make each entry immediately runnable.
Why is the email pattern not RFC-complete?
A fully RFC 5322-compliant email regex runs thousands of characters and nobody uses it. Engineering practice: regex as a format pre-filter, real validation by sending a mail.

Related tools