Developer

Encoders, converters & dev utilities

12 tools
Developer · United States

Regex Cheat Sheet & Common Patterns

Regex syntax reference + copy-ready email/date/URL patterns, per-language notes & a live tester. Accurate, instant and free — for United States.

A copy-ready reference for JavaScript-flavour regular expressions: the full token syntax, a library of battle-tested common patterns (each checked in CI against real examples and counter-examples), the per-language differences that trip people up, and a live tester that runs entirely in your browser.

Live regex tester

Test input is capped at 5,000 characters to limit catastrophic-backtracking (ReDoS) risk.

Syntax reference

Anchors

^Start of string (or line with m flag)^abc
$End of string (or line with m flag)abc$
\bWord boundary\bcat\b
\BNot a word boundary\Bcat

Character classes

.Any char except newline (all chars with s flag)a.c
\dDigit — ASCII 0–9 in JS (see engine notes)\d{3}
\wWord char [A-Za-z0-9_]\w+
\sWhitespace (space, tab, newline…)a\s+b
[abc]Any one of a, b or c[aeiou]
[^abc]Any char except a, b or c[^0-9]
[a-z]Any char in the range a–z[a-z0-9]

Quantifiers

*0 or more (greedy)a*
+1 or more (greedy)\d+
?0 or 1 (optional)colou?r
{n}Exactly n times\d{4}
{n,}n or more timesa{2,}
{n,m}Between n and m timesa{2,4}
*? +? ??Lazy (non-greedy) — match as few as possible".*?"

Groups & references

(…)Capturing group(ab)+
(?:…)Non-capturing group(?:ab)+
(?<name>…)Named capturing group(?<yr>\d{4})
\1Backreference to group 1(\w)\1
a|bAlternation — a or bcat|dog

Lookaround

(?=…)Positive lookahead\d(?=px)
(?!…)Negative lookahead\d(?!px)
(?<=…)Positive lookbehind(?<=\$)\d+
(?<!…)Negative lookbehind(?<!\$)\d+

Flags

gGlobal — find all matches, not just the first/a/g
iCase-insensitive/abc/i
mMultiline — ^ and $ match line breaks/^x/m
sDotall — . also matches newline/a.b/s
uUnicode mode (enables \p{…})/\p{L}/u
ySticky — match from lastIndex only/a/y

Common patterns (CI-tested)

Email address

^[^\s@]+@[^\s@]+\.[^\s@]+$

Pragmatic email shape: something, an @, a domain, a dot and a TLD — with no spaces.

Caveat: Pragmatic — a perfect RFC-5322 regex is impractical and not worth it; validate deliverability by sending a confirmation email.

ISO date (YYYY-MM-DD)

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

A four-digit year, two-digit month and two-digit day joined by hyphens.

Matches
2026-07-04
Rejects
2026-7-407/04/20262026/07/04not-a-date

Caveat: Shape only — this accepts 2026-13-40; range-check the month/day in code.

HTTP(S) URL

^https?://[^\s/$.?#].[^\s]*$

An http:// or https:// URL with a non-empty host and no whitespace.

Matches
https://a.comhttp://x.io/p?q=1
Rejects
ftp://a.comnot a urlhttp://

Caveat: Matches http(s) URLs loosely; use the URL constructor for real validation.

Phone (E.164)

^\+[1-9]\d{7,14}$

A leading +, a non-zero country-code digit, then 7–14 more digits (max 15 total).

Matches
+14155552671+919876543210
Rejects
4155552671+0123+1 415 555 2671

Caveat: E.164 international format (no spaces); local formats vary widely.

URL slug (kebab-case)

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

Lowercase letters/digits in hyphen-separated groups — no leading, trailing or doubled hyphens.

Matches
hello-worlda1my-post-2
Rejects
Helloa--b-xx-

Caveat: Lowercase kebab-case.

Hex color

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

A # followed by exactly 3 or 6 hexadecimal digits.

Matches
#fff#FF8800
Rejects
fff#ff#gggggg

Caveat: 3 or 6 hex digits; add {8} for alpha.

IPv4 address

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

Four dot-separated octets, each range-checked to 0–255.

Matches
192.168.0.18.8.8.8255.255.255.255
Rejects
256.0.0.11.2.31.2.3.4.5

Caveat: Validates 0-255 octets.

Strong password

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

Lookahead-enforced: at least one lowercase, one uppercase and one digit, minimum 8 characters.

Matches
Abcdef12StrongP4ss
Rejects
short1Aalllowercase1NoDigitsHere

Caveat: ≥8 chars with upper+lower+digit; consider a passphrase policy + a breach check instead.

Per-engine differences

FeatureJavaScriptPCREPython (re)Go (RE2).NET
\d matchesASCII 0–9 only (even with u — use \p{Nd})ASCII unless UCP is setUnicode by default (ASCII with re.ASCII)ASCII 0–9Unicode unless ECMAScript option
Named group(?<name>…)(?<name>…) or (?P<name>…)(?P<name>…)(?P<name>…)(?<name>…)
LookbehindYes (ES2018+)YesYes (fixed-width)No (RE2)Yes (variable-width)
BackreferencesYesYesYesNo (RE2)Yes

\d is not the same everywhere

In JavaScript, \d matches only ASCII 0–9 — the u flag does not make it match Unicode digits; use \p{Nd} with the u flag for that. Python 3's \d is Unicode by default (add re.ASCII to restrict it); PCRE is ASCII unless the UCP option is set. Never assume \dmeans “any digit in any script”.

Go's RE2 drops backreferences and lookbehind

Go's regexp package (and RE2) guarantees linear-time matching by omitting backreferences and lookaround. Patterns that rely on \1 or (?<=…) simply won't compile there. Named groups also use the Python-style (?P<name>…) syntax, not JS/.NET's (?<name>…).

Avoid catastrophic backtracking (ReDoS)

Nested quantifiers over overlapping alternatives — classics like (a+)+, (a|aa)+ or (.*)* — can make a backtracking engine take exponential time on a crafted input, freezing the thread. Prefer specific character classes, atomic-style rewrites, or a linear engine (RE2) for untrusted input, and always bound your quantifiers.

Greedy vs lazy

*, + and {n,m} are greedy — they grab as much as possible, then give back. Add a ? to make them lazy: on <a><b>, <.+> matches the whole string but <.+?> matches just <a>.
Anatomy

How to read a regular expression

A regex is a small language built from four kinds of token: what to match (character classes like \d or [a-z]), how many times (quantifiers like + or {2,4}), where (anchors like ^ and $), and grouping (parentheses, alternation and lookaround).

Character classes

What to match

  • \d \w \s — digit, word char, whitespace
  • [abc] [^abc] — set / negated set
  • . — any char (except newline)

Quantifiers

How many times

  • * + ? — 0+, 1+, optional
  • {n} {n,} {n,m} — exact / range
  • *? — lazy (fewest)

Anchors & groups

Where & grouping

  • ^ $ \b — start, end, boundary
  • (…) (?:…) — capture / non-capture
  • (?=…) (?<=…) — lookaround
The mental model
What
\d [a-z] .
How many
+ * {2,4}
Where
^ $ \b
Grouping
(…) | (?=…)
Patterns

Matching an email, a date and a URL

The three most-searched patterns are also the three most misused. Each is a shape check, not a truth check — regex tells you the text looks right, not that it is valid.

Email

^[^\s@]+@[^\s@]+\.[^\s@]+$

Pragmatic shape. A perfect RFC-5322 regex isn't worth it — confirm with a verification email.

ISO date

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

Shape only — it accepts 2026-13-40. Range-check in code.

HTTP URL

^https?://[^\s/$.?#].[^\s]*$

Loose match. For real validation, use the URL constructor.

Regex validates shape, not meaning

A pattern can confirm a string looks like an email, date or IP — it cannot confirm the mailbox exists, the date is a real calendar day, or the octets are ≤ 255 unless you build that range-checking in. The copy-ready patterns above the fold are each verified in CI against real examples and counter-examples, so the shapes are correct; pair them with semantic validation in your code.
Flavours

Why the same regex differs per language

Regex is a family of dialects, not one standard. A pattern copied from a Python answer can silently behave differently — or fail to compile — in JavaScript or Go.

The \d trap

In JavaScript \d matches only ASCII 0–9, and the u flag does not change that — use \p{Nd} for Unicode digits. Python 3 treats \d as Unicode by default (add re.ASCII to restrict it), and PCRE is ASCII unless the UCP option is on.

Go's RE2 has no backreferences or lookbehind

Go's regexp package uses RE2, which trades those features for a guaranteed linear-time match. Patterns with \1 or (?<=…) won't compile. Named groups use (?P<name>…) (Python style), not (?<name>…) as in JavaScript, .NET and PCRE.
Pitfalls

Greedy vs lazy, and catastrophic backtracking

Greedy vs lazy

How much to consume

  • <.+> on <a><b> → the whole string
  • <.+?> → just <a>
  • Add ? to any quantifier to make it lazy

Avoid ReDoS

Don't hang the thread

  • Avoid nested quantifiers: (a+)+, (.*)*
  • Bound repetition with explicit {n,m}
  • Use RE2 for untrusted input

Catastrophic backtracking is a denial-of-service risk

A pattern like (a+)+$ against a long string of as followed by a non-a forces the engine to explore exponentially many ways to split the input, freezing for seconds or longer. Never run an unbounded, nested-quantifier pattern against user-supplied text on a backtracking engine.
FAQ

Frequently asked questions

A pragmatic pattern is ^[^\s@]+@[^\s@]+\.[^\s@]+$ — one or more non-space, non-@ characters, an @, a domain, a dot, and a TLD, all with no spaces. This deliberately does not try to be RFC 5322 compliant: a fully correct email regex is thousands of characters long, still rejects some valid addresses, and accepts some invalid ones. The industry practice is to use a loose shape check like this one and then confirm the address really exists by sending a verification email. Do not treat a regex pass as proof the mailbox is real.

Use ^\d{4}-\d{2}-\d{2}$ for the ISO 8601 shape: four digits, a hyphen, two digits, a hyphen, two digits. Be aware this validates shape only — it happily matches 2026-13-40, because regex cannot easily range-check that the month is 1–12 and the day is valid for that month. After the pattern passes, parse the value with a real date library (or Date) and confirm it is a legal calendar date. Regex is the wrong tool for semantic validation of numbers.

By default *, + and {n,m} are greedy: they consume as many characters as possible and then backtrack only if the rest of the pattern fails. Adding a ? makes them lazy (non-greedy): they consume as few as possible and expand only when needed. The classic example is matching <a><b>: the greedy <.+> matches the entire string <a><b>, whereas the lazy <.+?> stops at the first > and matches just <a>. Reach for lazy quantifiers when you want the shortest match between two delimiters.

Regex engines implement different flavours. The biggest trap is \d: in JavaScript it matches only ASCII 0–9, and the u flag does not change that (use \p{Nd} for Unicode digits), whereas Python 3 treats \d as Unicode by default unless you pass re.ASCII. Go uses the RE2 engine, which guarantees linear-time matching by dropping backreferences and lookbehind entirely, so patterns using \1 or (?<=…) simply will not compile there. Named groups also differ: (?<name>…) in JS/.NET/PCRE versus (?P<name>…) in Python and Go. Always test a pattern in the engine you will actually run it in.

ReDoS (regular-expression denial of service) happens when a backtracking engine hits a pattern with nested or overlapping quantifiers — classics like (a+)+, (a|aa)+ or (.*)* — on an input crafted to make it explore an exponential number of paths. The match can hang a thread for seconds or minutes, taking a service down. Avoid it by not nesting quantifiers over overlapping alternatives, preferring specific character classes over .*, bounding repetition with explicit {n,m} limits, and using a linear-time engine (such as RE2) for any pattern that runs against untrusted input.

Lookarounds are zero-width assertions: they check that something does or does not appear next to the current position without consuming characters. (?=…) is positive lookahead (the following text must match), (?!…) is negative lookahead (must not match), and (?<=…) / (?<!…) are the positive and negative lookbehind equivalents for the preceding text. A common use is a password rule like ^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,}$, where each lookahead independently asserts that a lowercase letter, an uppercase letter and a digit each appear somewhere, while .{8,} enforces the length.

Sources

Method, standards & references

Method: every pattern in the common-patterns library is a JavaScript RegExp checked in continuous integration — each must match all of its example strings and reject all of its counter-examples, so the shapes shown here are verified. The live tester runs entirely in your browser via the native RegExp constructor, guards invalid patterns in a try/catch, and caps the test input to limit ReDoS exposure. Nothing is sent to a server.

How we calculate this

Reviewed by Reckonist Editorial · Last reviewed 4 July 2026. Figures follow the methods and sources set out in our editorial standards.

This reference and tester are for building and debugging regular expressions in the browser. Regex validates the shape of text, not its meaning — always pair a pattern with semantic validation (a real date parse, a URL constructor, a verification email) before trusting user input.

Keep going

Same-category tools follow this colour; a cross-category link keeps its own.