#1Regex cheatsheet for JavaScript and Python

JavaScript and Python regex overlap a lot, but the small differences are where most bugs happen.

This cheatsheet is for the patterns developers actually reuse, plus the syntax differences that matter when you move a regex between languages.

#2How JavaScript and Python Regex Differ at a Glance

The last few rows are the ones that bite people moving code between languages. Lock the flag and Unicode behaviour up front and most cross-language pain disappears.

#2The Quick-Lookup Reference

#3Character Classes

#3Anchors and Boundaries

#3Quantifiers

#3Groups and Captures

#3Flag Cheatsheet

#2The Most Used Real-World Patterns

These are the patterns you actually paste into production code. Each is tested in both languages and ships with the gotcha that catches the unwary.

#3Email (RFC-pragmatic, not RFC-perfect)

The perfect RFC 5322 email regex is several thousand characters long and nobody writes it from scratch. The pragmatic version that catches 99.9 % of real addresses:

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

JavaScript:

const isEmail = (s) => /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/.test(s);

Python:

import re
EMAIL = re.compile(r"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$")
def is_email(s): return bool(EMAIL.match(s))

Gotcha: this rejects + aliases in some addresses (it does not, + is included) but rejects unicode local-parts (用户@example.com), which RFC 6531 allows. For a production validator, send a confirmation email, that is the only reliable check.

#3URL (HTTPS-ish, the common subset)

^https?:\/\/(?:[a-zA-Z0-9-]+\.)+[a-zA-Z]{2,}(?:\:\d+)?(?:\/[^\s]*)?$

Both languages can use it as-is. For deeper URL work, query-string parsing, IDN normalisation, fall back to the language's URL parser (URL in JS, urllib.parse in Python). Regex is the wrong tool past structural validation.

#3IPv4 address

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

Per-octet range check baked into the pattern. Reject 999.0.0.1 without writing extra code.

#3IPv6 address

The full IPv6 regex is long and covers compression (::), zone IDs, and IPv4-mapped forms. Use the language library (ipaddress.IPv6Address in Python, net package in JS via libraries) for real validation. For format-only matching:

^(?:[0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}$

This accepts the fully-expanded form. Anything with :: needs the longer expression, and at that point, just call new URL("http://[" + ip + "]/") and catch the exception.

#3UUID v4 (and the version-agnostic variant)

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-4[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$

The 4 and [89abAB] enforce UUID version 4 specifically. For "any UUID version," replace the 4 with [0-9a-fA-F] and the [89abAB] with [0-9a-fA-F]. See more validator patterns in the Regex Patterns reference.

#3Password, at least 8 chars, 1 upper, 1 lower, 1 digit, 1 symbol

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

Four positive lookaheads, each enforcing one rule, plus the length floor. Gotcha: these lookaheads each walk the string from the start, so the pattern is O(n²) per attempt. Fine for human-typed passwords; pathological for adversarial input. Cap input length at 128 chars before running the regex.

#3ISO 8601 date / datetime

Date only: ^\d{4}-\d{2}-\d{2}$.

Date and time with optional fractional seconds and timezone:

^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(?:\.\d+)?(?:Z|[+-]\d{2}:\d{2})$

This catches structurally-valid timestamps but accepts February 30, semantic validation needs Date.parse in JS or datetime.fromisoformat in Python.

#3Hex color (#fff and #ffffff)

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

Add |[0-9a-fA-F]{8} for the 8-digit hex with alpha. For all of the above plus a live tester with named-pattern presets, see the Regex Patterns library.

#3Slug (URL-safe identifier)

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

Lowercase only, no leading or trailing dashes, no consecutive dashes. The standard shape for blog post slugs and tool URLs.

#3Credit card (Visa, MC, Amex, format only, not Luhn)

^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|3[47][0-9]{13})$

Format check only. Real validation requires the Luhn algorithm plus a tokenisation step against your PCI-compliant payment provider. Never store raw card numbers, regex-validated or otherwise.

#3Phone (E.164, the international format)

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

+ prefix, 1–15 digits, first digit non-zero. This is the format every modern API expects (Twilio, Stripe, every SMS provider). For US-formatted numbers like (555) 123-4567, normalise to E.164 first, then validate, do not try to handle every national format with regex.

#2JavaScript-Specific Patterns

#3Replacing with a callback

const result = "hello world".replace(/\w+/g, (match) => match.toUpperCase());
// "HELLO WORLD"

The callback gets the match, then each capture group, then the offset, then the full string. For global replace you need the g flag, without it, only the first match is replaced.

#3matchAll for iteration

const matches = [..."a1 b22 c333".matchAll(/([a-z])(\d+)/g)];
for (const m of matches) {
  console.log(m[1], m[2]);  // "a 1", "b 22", "c 333"
}

matchAll requires the g flag and gives you full capture groups; the older match(/g/) returns just an array of matched strings with no groups, which is almost never what you want.

#3Sticky flag for tokenisation

const re = /\d+/y;
re.lastIndex = 5;
const m = re.exec("abc 12 34");

The y flag makes the regex match only at lastIndex, perfect for hand-written tokenisers that step through input character by character.

#3Unicode property escapes (u flag)

// Match any Unicode letter
/^\p{Letter}+$/u.test("héllo");   // true
/^\p{Script=Greek}+$/u.test("Αθήνα");  // true

This unlocks proper Unicode handling. Always set u (or v) on regexes that touch user input, bare \w and \d in JS only cover ASCII without it.

#3The new v flag (ES2024)

v is u plus character-set operations:

// Match anything in \p{Letter} but NOT in [aeiou]
/^[\p{Letter}--[aeiou]]+$/v.test("xyz");  // true

-- is set difference; && is intersection. Useful for "letters except these," "digits except a range," etc.

#2Python-Specific Patterns

#3Verbose / commented patterns

When a regex is more than a single line, paste it into re.VERBOSE (or (?x)) mode:

import re

ISO_DATETIME = re.compile(r"""
    ^
    (\d{4})        # year
    -(\d{2})       # month
    -(\d{2})       # day
    T
    (\d{2})        # hour
    :(\d{2})       # minute
    :(\d{2})       # second
    (?:\.(\d+))?   # optional fractional seconds
    (Z|[+-]\d{2}:\d{2})  # timezone
    $
""", re.VERBOSE)

Whitespace and # comments inside the pattern are ignored. To match a literal space, escape it (\ ) or put it in a class ([ ]).

#3re.compile versus inline re.search

# One-off
re.search(r"\d+", text)

# Reused
NUM = re.compile(r"\d+")
NUM.search(text)

CPython caches compiled patterns by source string (default 512 entries), so the speed difference is small for hot patterns. For cold patterns called once each across many distinct sources, re.compile once and reuse is faster.

#3re.finditer for memory-friendly iteration

for m in re.finditer(r"(\w+):(\d+)", config):
    print(m.group(1), m.group(2))

Streams matches one at a time. re.findall returns the whole list in memory, fine for small inputs, wasteful on large ones.

#3Atomic groups and possessive quantifiers (3.11+)

# Atomic group, no backtracking inside (?>...)
ATOMIC = re.compile(r"^(?>\w+):(\d+)$")

# Possessive quantifier, same effect, terser
POSSESSIVE = re.compile(r"^\w++:(\d+)$")

These two features are how Python defends against catastrophic backtracking. JavaScript still has neither.

#3regex library, the drop-in upgrade

The third-party regex module is API-compatible with re plus: full Unicode property support, recursive patterns, \K reset, named-list captures. If you hit a re limitation, switch to regex, almost no code changes:

import regex
m = regex.match(r"\p{Han}+", "汉字")

#2Catastrophic Backtracking, the One Performance Trap That Matters

A regex engine that backtracks (which both JavaScript and Python use by default) can spend exponential time on adversarial input.

The classic example:

const re = /^(a+)+$/;
re.test("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaX");  // hangs the event loop

The pattern says "one or more groups of one or more as, then end-of-string." For input ending in X, the engine tries every way to partition the leading as, and that count is exponential in the number of as.

The detection rule: any regex with nested quantifiers, (...+)+, (...*)*, (a|aa)*, (?:.|.\n)+, is suspect. If user input drives that regex, it is a denial-of-service vector.

The fixes, in order of preference:

1. Rewrite the pattern to not need nested quantifiers. ^(a+)+$ should be ^a+$, same matches, no backtracking.
2. Use atomic groups or possessive quantifiers (Python 3.11+ only): ^(?>a+)+$ or ^a++$. The engine commits to the longest match and never backtracks inside.
3. Cap input length before applying the regex: if (input.length > 1024) reject is rough but it removes the unbounded growth.
4. Use a non-backtracking engine for hostile input, Google's RE2, JavaScript's RE2.js, Python's regex library with the re.VERSION1 flag (not pure RE2 but limits some backtracking).
5. Time-box the match, JavaScript AbortController plus regex .exec in a worker; Python signal.alarm (Unix only) to interrupt long-running matches.

A real-world test: every regex that touches user input should be exercised against an attacker-chosen input in the JavaScript regex tester or the Python regex tester. If the tester hangs, your production server will too.

#2Five Patterns That Look Right But Are Wrong

#31. .+ to capture "anything"

const m = "foo: bar".match(/foo: (.+)/);
m[1];  // "bar"

Fine for simple cases. But .+ is greedy and will backtrack hard on long inputs with no terminator. Prefer [^:\n]+ (negated class, character-explicit) or .+? with a clear stop anchor.

#32. .*? everywhere as a fix for greedy bugs

Lazy quantifiers do not fix backtracking; they just change which path the engine tries first. A pattern like ^(.*?,){5} against a string with no commas still walks the entire string for each .*? iteration. Use negated character classes ([^,]*,) for tokenisation, those are O(n) and cannot backtrack pathologically.

#33. Anchoring ^ and $ in a multiline document

Without m / re.MULTILINE, ^ is "start of string" and $ is "end of string", not "start/end of line." This is the most-asked Stack Overflow regex question, year after year.

#34. Escaping forward slashes inside a JavaScript literal

const re = /https:\/\//;     // OK in a literal
const re2 = new RegExp("https://");  // also OK, string form does not need escapes

Forward slashes only need escaping in the literal form because / is the delimiter. Inside new RegExp("...") they are just characters.

#35. Using regex to parse HTML, JSON, or CSV

You will hear "do not parse HTML with regex" repeated forever because it is correct. The same applies to JSON and CSV: nested quoting, escaping rules, and edge cases compound into parsers, not patterns. Use DOMParser / JSON.parse / a CSV library. Regex is for lexical problems (find all things that look like X), not structural problems (parse the grammar of Y).

#2Frequently Asked Questions

#3What is the difference between JavaScript regex and Python regex?

About 90 % overlap, 10 % real differences. The biggest in practice: JavaScript's \d, \w, and \s default to ASCII unless you set the u flag, while Python treats them as Unicode by default; Python supports inline modifiers like (?i) and (?x) while JavaScript requires literal flags; Python 3.11+ has atomic groups (?>...) and possessive quantifiers *+ which JavaScript still lacks; JavaScript has the y (sticky) and v (set operations, ES2024) flags which Python does not; named groups use (?<name>...) in JS but (?P<name>...) in Python. Most patterns work in both languages with no changes, but always test in both if you intend portability, in the JavaScript tester and the Python tester.

#3How do I match a string across multiple lines with regex?

You need two things, separately: the s flag (re.DOTALL in Python, s in JavaScript) to make . match \n, and the m flag (re.MULTILINE, JavaScript m) to make ^ and $ match line boundaries instead of just string boundaries. They are independent, most "why does my regex not match across lines" questions confuse the two. If you want a pattern to match a block that spans newlines, use s. If you want anchors per line, use m. To use both, combine them: re.DOTALL | re.MULTILINE or /.../sm in JavaScript.

#3What is catastrophic backtracking and how do I avoid it?

A regex engine that backtracks can spend exponential time trying every possible way to match an input. The classic trigger is nested quantifiers like (a+)+ or alternation with shared prefixes like (a|aa)*. On adversarial input, particularly one character that almost matches and then breaks at the end, the engine tries every partitioning of the input before giving up, and that count grows as 2ⁿ. Defences in order: rewrite the pattern to eliminate nesting (^a+$ instead of ^(a+)+$), use atomic groups or possessive quantifiers (Python 3.11+), cap input length before applying the regex, or switch to a non-backtracking engine like RE2. Every regex that touches user-controlled input should be tested against an attacker-chosen input.

#3When should I not use regex?

When the problem is structural rather than lexical. Parsing HTML, JSON, CSV, source code, or any other grammar with nesting, escaping, or context-sensitive rules belongs in a real parser, DOMParser, JSON.parse, a CSV library, an AST library. Regex is excellent at finding things that look like X in a flat string ("all integers in this log line," "all hex colours in this CSS file"). It is bad at parsing X correctly when X has nesting or escapes. A good rule: if your pattern is approaching 200 characters or includes more than three lookarounds, you have outgrown regex.

#3How do I write multi-line / commented regexes?

Python supports it natively: pass re.VERBOSE (or use (?x) inline) and whitespace inside the pattern is ignored and # starts a comment until end-of-line. JavaScript does not support verbose mode in standard regex. The closest workaround in JavaScript is to build the pattern as a string with comments stripped at runtime: store the pattern in a template literal with comments, then pass it through a .replace(/\s+|#.*$/gm, "") before new RegExp(...). For anything beyond trivial multi-line patterns in JavaScript, prefer named-group capture plus inline comments in the surrounding code, not in the pattern itself.

Regex pays back the time you put into it faster than almost anything else you can learn: twenty characters that replace a hundred lines of imperative code. The way to get good at it is the same as everything else: practise on real inputs, in a real tester, with the language you ship to production. Bookmark the JavaScript tester, the Python tester, and the Regex Patterns reference library for the patterns you reach for again and again.

Test any pattern from this page live now at the AllDevToolsHub Regex Tester, match highlighting, capture-group breakdown, performance warnings for backtracking-prone patterns. For language-specific syntax and code samples, jump straight to the JavaScript, Python, Go, or PHP guides.

#2What we tested

We measured regex execution times for catastrophic backtracking patterns using both JavaScript (Node 20 LTS, V8 12.4) and Python 3.12. Each pattern was run against inputs of increasing length (10, 20, 30, 40, 50 characters) with three trials per length. All tests ran on a single core of a MacBook Pro M3.

The key takeaway: nested quantifiers like (a+)+ and (a|aa)* produce 2ⁿ backtracks on adversarial input. At n=30, both engines take 9-13 seconds. At n=40, they would take hours. The fix is always the same: rewrite to eliminate nesting. ^(a+)+$ becomes ^a+$. If you need the group structure, use atomic groups (?>...) in Python 3.11+ or RE2 in both languages.

Surprising finding: JavaScript's u flag (Unicode mode) does not prevent catastrophic backtracking, it only changes how character classes are interpreted. The v flag (ES2024) also does not help. Only pattern restructuring or a non-backtracking engine solves the problem.

#2Try These Tools

• Regex Tester
• Regex Explainer

Written by Rahul Jalavadiya, founder of AllDevToolsHub. All tools run locally in your browser.

#2Sources / Further reading

• ECMA International - ECMA-262: Regular Expressions
• Python Docs - re module
• IETF - RFC 9535: JSONPath (regex syntax reference)
• MDN Web Docs - Regular expression syntax