Regex Cheatsheet for Developers (with Real Examples)

Regular expressions (regex) let you match patterns in text. They look cryptic at first but follow consistent rules. Most cheatsheets list the syntax and stop there. This one is built around real patterns you actually use day-to-day: validating an email, extracting a URL, matching a Pakistani +92 phone or CNIC, parsing a date, finding a hex colour. Each example is testable in our Regex Tester so you can paste, tweak, and see live matches.

Character classes (the basic building blocks)

• \d matches any digit (0-9)
• \D matches any non-digit
• \w matches any word character (letters, digits, underscore)
• \W matches any non-word character
• \s matches any whitespace (space, tab, newline)
• \S matches any non-whitespace
• . matches any single character except newline
• [abc] matches any of a, b, c
• [^abc] matches anything except a, b, c
• [a-z] matches any lowercase letter

Quantifiers (how many times)

• * zero or more
• + one or more
• ? zero or one (optional)
• {n} exactly n times
• {n,} n or more times
• {n,m} between n and m times
• Add ? after a quantifier (e.g. .+?) to make it lazy / non-greedy

Anchors (where in the string)

• ^ start of string (or line, with multi-line flag)
• $ end of string (or line)
• \b word boundary
• \B non-word boundary

Real-world worked examples

Each pattern below is shown with an example, what it matches, and what it does NOT match. Test these in the Regex Tester.

Email (basic)

Pattern: ^[\w.-]+@[\w-]+\.[\w.-]+$

Matches: alice@example.com, bob.test+filter@gmail.co.uk Does not match: missing@, no@dot, @nouser.com

This is a "good enough for most cases" email pattern. For strict RFC 5322 compliance, the regex becomes much longer. Most real email validation should rely on the input field type or a dedicated library, with regex as a quick sanity check only.

URL

Pattern: ^https?:\/\/[\w.-]+(?:\/[\w./?=#&-]*)?$

Matches: https://example.com, http://sub.domain.co.uk/path?query=1 Does not match: ftp://example.com, just-a-string

For more permissive URL detection in free text, drop the anchors (^ and $).

Pakistani phone number (+92 mobile or landline)

Pattern: ^(?:\+92|0)3\d{2}[\s-]?\d{7}$ for mobile Pattern: ^(?:\+92|0)\d{2,3}[\s-]?\d{6,8}$ for general PK numbers

Matches: +923001234567, 03001234567, +92 300 1234567 Does not match: 12345, +91234567890 (Indian +91)

Pakistani mobile numbers start with +92 3XX or 03XX followed by 7 more digits. Adjust if you need stricter operator-prefix validation (Jazz, Telenor, Zong, Ufone each have specific number ranges).

Pakistani CNIC

Pattern: ^\d{5}-\d{7}-\d$

Matches: 35202-1234567-8 Does not match: 35202 1234567 8, 12345-67-8 (wrong segment lengths)

The CNIC format is fixed: 5 digits, dash, 7 digits, dash, 1 check digit.

Hex colour

Pattern: ^#?([a-f\d]{6}|[a-f\d]{3})$ (case-insensitive)

Matches: #fff, fff, #FFAA00, ffaa00 Does not match: #ff, #fffff (invalid lengths)

Use the i flag (case-insensitive) when implementing. Both 3-character shorthand and 6-character full hex are accepted.

Date YYYY-MM-DD (ISO format)

Pattern: ^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$

Matches: 2026-05-09, 2026-12-31 Does not match: 2026-13-01 (invalid month), 2026-02-30 (invalid day, but regex does not validate days-per-month, use a date library for that)

For loose validation that accepts any 4-2-2 format including invalid months: ^\d{4}-\d{2}-\d{2}$

IP address (IPv4)

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

Matches: 192.168.1.1, 8.8.8.8, 255.255.255.255 Does not match: 256.0.0.1, 192.168.1, 192.168.1.1.1

Each octet is 0-255 with proper bounding, so 256.0.0.0 correctly fails.

Strong password (length plus character classes)

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

Matches: Tarbooz12!Mountain, Strong-Pass-99 Does not match: short, alllowercase12, NoSpecialChars1

Lookaheads ensure each requirement (lowercase, uppercase, digit, symbol) is satisfied independently. Length minimum is set to 12. Adjust as needed.

Slug from title

Pattern (replace) operations: lowercase the input, then [^a-z0-9]+ replaced with - and trim leading / trailing dashes.

Useful for converting "How to Pick a Domain Name" into "how-to-pick-a-domain-name" for URL-safe blog slugs.

Whitespace cleanup

Pattern: \s+ replaced with single space, then trim.

Collapses any runs of whitespace (spaces, tabs, newlines) into single spaces. Used everywhere from form input cleaning to log parsing.

Extract YouTube video ID

Pattern: (?:youtube\.com\/(?:[^\/]+\/.+\/|(?:v|e(?:mbed)?)\/|.*[?&]v=)|youtu\.be\/)([^"&?\/\s]{11})

Captures: dQw4w9WgXcQ from any YouTube URL variant (watch?v=, embed/, youtu.be/, etc.)

The capture group (the part in parentheses) gives you just the 11-character video ID.

Capture groups (extract parts of the match)

Wrap part of the pattern in parentheses to capture it.

Pattern: (\d{4})-(\d{2})-(\d{2}) on input "2026-05-09" captures: - Group 1: 2026 (year) - Group 2: 05 (month) - Group 3: 09 (day)

Use named groups for readability: (?\d{4})-(?\d{2})-(?\d{2}). Access via match.groups.year in JavaScript / Python regex APIs that support named groups.

Use a non-capturing group with (?:...) when you need the grouping for alternation or quantification but do not need to extract the matched value. Example: (?:https?|ftp):// matches http://, https://, or ftp:// but does not capture the protocol.

Greedy vs lazy quantifiers (the most common bug)

Default quantifiers (* and +) are greedy: they match as much as possible. Add ? after the quantifier to make it lazy: match as little as possible.

Worked example on input

first

second

.+

first

second

.+?

first

Greedy is often what you do NOT want. When extracting tags, attributes, or quoted strings, prefer lazy quantifiers.

Lookahead and lookbehind (assertions)

Lookarounds match conditions WITHOUT consuming characters in the match.

• Lookahead (?=...): matches if followed by ... but does not include ... in the match
• Negative lookahead (?!...): matches if NOT followed by ...
• Lookbehind (?<=...): matches if preceded by ... but does not include ... in the match
• Negative lookbehind (?

Worked example: \d+(?=USD) matches the digits in "100USD" but NOT in "100PKR" (and the match is just "100", the "USD" is asserted but not captured).

Worked example: (?<=\$)\d+ matches the digits in "$100" (after the dollar sign) but the match is just "100".

Per-language regex flavour notes

Different programming languages implement slightly different regex grammars. Common differences:

• JavaScript / ECMAScript: documented in MDN. Supports lookahead always. Lookbehind requires modern engines (ES2018+).
• Python: re module is similar to JS but supports verbose mode (re.VERBOSE) for commenting your regex. Named groups use (?P...) historically though (?...) also works on modern Python.
• PCRE (PHP, many CLI tools): most powerful, supports recursion and conditional patterns.
• POSIX (grep, awk by default): minimal feature set. Basic ERE / BRE. No lookahead unless using -P (PCRE mode in GNU grep).
• .NET: very rich, supports balancing groups for nested-bracket parsing.

When porting a regex between languages, always re-test it. Subtle differences in escape rules and feature support can break otherwise identical patterns.

Common mistakes and how to debug

• Forgetting to escape special characters: . + * ? ( ) [ ] { } | \ ^ $ all have special meanings. To match a literal dot, write \.
• Greedy quantifier eating too much: see greedy vs lazy section above
• Anchors missing: ^ and $ are required if you want to validate (match-the-whole-string) rather than search (match-anywhere)
• Case sensitivity: add the i flag for case-insensitive matching
• Multiline mode: ^ and $ match start/end of line (not just whole string) only with the m flag
• Unicode: \d matches Unicode digits with the u flag in JavaScript (without it, only ASCII 0-9)
• Backslash escaping in source code: in JavaScript string literals, you need double-backslash (\\d) but in regex literals (/\d/), single backslash is enough

Test, do not guess

Always test regex against many inputs including edge cases: empty string, special characters, very long input, Unicode characters, malformed input. Use our Regex Tester to paste a pattern and a test string and see live matches with capture-group breakdowns. Pair with this cheatsheet for the syntax reference.