Regex Cheat Sheet for JavaScript

Regular expressions are excellent for recognizing bounded text patterns and extracting fields. They are less suitable for fully parsing nested formats such as HTML or programming languages. The examples below use JavaScript RegExp syntax and should be adapted to your exact input rules.

Character classes and anchors

\d        digit
\w        ASCII word character
\s        whitespace
.         any character except line terminators (without s)
^ and $   start and end
[abc]     one listed character
[^abc]    one character not listed
\p{L}    Unicode letter (with the u flag)

Quantifiers

?       zero or one
*       zero or more
+       one or more
{3}     exactly three
{3,6}   three through six
*?      lazy zero or more

Common validation patterns

# Simple email shape (not full address validation)
^[^\s@]+@[^\s@]+\.[^\s@]+$

# HTTPS URL—prefer new URL() for application validation
^https:\/\/[^\s]+$

# ISO date shape—still validate the real calendar date
^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$

# UUID v4
^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$

Phone numbers

# E.164 international form: +14155551234
^\+[1-9]\d{1,14}$

# Loose North American form: (555) 123-4567 or 555-123-4567
^\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}$

Phone formatting varies enormously by country. E.164 is the only form worth validating strictly; for anything else, normalise the input first and use a phone-number library rather than growing the expression.

IP addresses

# IPv4 with correct 0-255 ranges
^((25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(25[0-5]|2[0-4]\d|[01]?\d\d?)$

# IPv6, loose shape only—full validation needs a parser
^([\da-fA-F]{0,4}:){2,7}[\da-fA-F]{0,4}$

The IPv4 pattern enforces real octet ranges, so it rejects 999.1.1.1. The IPv6 form is deliberately approximate: compressed notation, zone identifiers, and embedded IPv4 make a complete expression unreadable and easy to get wrong.

Colours

# Hex: #FFF, #FFFFFF, or #FFFFFFFF
^#([A-Fa-f0-9]{3}|[A-Fa-f0-9]{6}|[A-Fa-f0-9]{8})$

# rgb() with three channels
^rgb\(\s*\d{1,3}\s*,\s*\d{1,3}\s*,\s*\d{1,3}\s*\)$

Versions, numbers, and postal codes

# Semver core, with optional pre-release and build
^\d+\.\d+\.\d+(-[\w.]+)?(\+[\w.]+)?$

# Signed decimal number
^-?\d+(\.\d+)?$

# Percentage
^\d+(\.\d+)?%$

# US ZIP, optional +4
^\d{5}(-\d{4})?$

# Indian PIN
^[1-9][0-9]{5}$

# Canadian postal code
^[A-Za-z]\d[A-Za-z][ -]?\d[A-Za-z]\d$

Card type detection

# Visa
^4\d{12}(\d{3})?$

# Mastercard
^(5[1-5]\d{14}|2(2[2-9]\d|[3-6]\d{2}|7[01]\d|720)\d{12})$

# American Express
^3[47]\d{13}$

Use these to label a card brand in the interface, not to decide whether a number is real. Validity requires a Luhn checksum at minimum, and authorisation is the only genuine answer. Never store or log a full card number while testing these patterns.

Extraction patterns

# Named key/value groups
(?<key>[A-Za-z_][\w-]*)=(?<value>[^\s]+)

# HTTP or HTTPS links in plain text
https?:\/\/[^\s<>()]+

# Hashtag text using Unicode letters and numbers
#[\p{L}\p{N}_]+   flags: gu

# Double-quoted string contents
"([^"]*)"

# Email addresses inside prose
[\w.+-]+@[\w-]+\.[\w.]+

Stripping HTML, carefully

# Removes tag-like runs; adequate for trusted text only
<[^>]+>

This is fine for tidying a known-safe snippet, and wrong for anything security-sensitive. Attributes can contain angle brackets, comments and CDATA nest, and malformed markup does not follow the rule. To sanitise untrusted HTML, parse it with DOMParser or a maintained sanitiser and work on the resulting tree.

Useful JavaScript flags

• g finds every match rather than stopping at the first.
• i enables case-insensitive matching.
• m makes ^ and $ operate at line boundaries.
• s allows dot to match line terminators.
• u enables Unicode-aware parsing and property escapes.
• y performs a sticky match beginning at lastIndex.

Avoid catastrophic backtracking

Nested ambiguous quantifiers such as (a+)+ can take extremely long on a near-match. Prefer bounded quantifiers, unambiguous delimiters, input-length limits, and tests containing long adversarial strings. Do not run an untrusted pattern against unbounded input on a request-handling thread.

Validation is more than matching a shape

A regex can confirm that 2026-02-31 looks like YYYY-MM-DD but cannot make it a real calendar date. Likewise, email and URL validity depends on application requirements. Use dedicated parsers such as URL, Date logic, or a standards-aware library after the initial shape check.

Writing your own

• Start with the simplest expression that works and add specificity only when a real input demands it.
• Anchor with ^ and $ when validating a whole value rather than searching within text.
• Use lazy quantifiers when matching between delimiters.
• Escape characters you mean literally, especially . and /.
• Use named capture groups so the extraction code reads clearly.

Testing checklist

• Test expected matches and expected failures.
• Include empty, Unicode, multiline, and very long inputs.
• Anchor the expression when validating an entire value.
• Document the flavor and flags next to the pattern.
• Measure performance when input or patterns can be user-controlled.