Regex Cheatsheet Lookup

The Regex Cheatsheet Lookup is a free online tool that searchable reference for 100+ regex tokens with live examples, common pattern library, inline tester, and cross-flavor notes for js, python, pcre, posix.. It runs entirely in your browser with no installation or sign-up needed.

JavaScript (ECMAScript), Python (re/regex), PCRE (PHP/Perl), and POSIX (BRE/ERE). The Flavors tab highlights differences: \A/\Z anchors, possessive quantifiers, POSIX classes.

Yes. Every match and highlight is computed in your browser via native JavaScript RegExp. Nothing is sent to a server.

Yes — click Copy next to any token or common pattern (Email, URL, IPv4, UUID, strong password, etc.) to put the raw pattern on your clipboard.

Yes, the Regex Cheatsheet Lookup is 100% free with no registration, no hidden fees, and no usage limits. All processing happens locally in your browser, ensuring complete privacy.

Absolutely. The Regex Cheatsheet Lookup processes everything client-side in your browser. No data is uploaded to or stored on any server. Your content remains private on your device at all times.

Yes, the Regex Cheatsheet Lookup is fully responsive and works on smartphones and tablets. You can use it on any device with a modern web browser -- no app download required.

No account or registration is needed. Simply open the Regex Cheatsheet Lookup in your browser and start using it immediately. There are no sign-up walls or usage restrictions.

The Regex Cheatsheet Lookup supports a wide range of popular formats and languages. Check the tool interface for the full list of supported options.

Simply enter your input in the provided field, adjust any settings to your preference, and the tool will process it instantly. You can then copy the result to your clipboard or download it.

Greedy quantifiers like *, +, and {n,m} match as much text as possible, then backtrack only if the rest of the pattern fails. Lazy quantifiers, written by adding a ? (so *?, +?, ??, {n,m}?), match as little as possible and expand only when forced. The classic example is <.*> against "<b>hi</b>": the greedy version grabs the whole string from the first < to the last >, while the lazy <.*?> stops at the first >, matching just "<b>". Lazy quantifiers are essential for extracting individual tags, quoted strings, or delimited fields without overshooting. The cheatsheet's Quantifiers section lists every greedy and lazy form with worked examples, and you can drop a pattern straight into the inline tester to watch greedy versus lazy behavior on your own text before committing it to code.

Both are zero-width assertions: they check whether text exists around a position without consuming it or including it in the match. Lookahead checks what follows. (?=abc) is positive (must be followed by abc) and (?!abc) is negative (must not be). So \d+(?=px) matches the digits in "10px" but leaves "px" out of the result. Lookbehind checks what precedes: (?<=abc) positive and (?<!abc) negative, so (?<=\$)\d+ grabs 99 from "$99" without capturing the dollar sign. JavaScript has supported lookbehind since ES2018, but some older engines and POSIX flavors lack it entirely. The Groups and Lookarounds section of the cheatsheet shows all four assertions with examples, and the live tester lets you confirm exactly which characters land inside the match versus the assertion.

A regex that matches nothing usually has an unescaped special character, a wrong flag, or an anchor mismatch: ^ and $ only span lines when the m flag is set, and . skips newlines unless you add the s flag. A regex that freezes is almost always catastrophic backtracking, caused by nested quantifiers like (a+)+ or overlapping alternation that forces the engine to try an exponential number of paths on a non-matching string. Fixes include making quantifiers more specific, using atomic groups or possessive quantifiers in PCRE, or rewriting the pattern to avoid ambiguity. The inline tester here helps both cases: it shows the exact RegExp error message when a pattern is invalid, and it highlights every match so you can see immediately whether your pattern over-matches, misses edge cases, or returns nothing.

Those tools use POSIX regular expressions, which do not define the shorthand classes \d, \w, or \s that you know from JavaScript, Python, or PCRE. In POSIX you use bracket expressions instead: [[:digit:]] for digits, [[:alpha:]] for letters, [[:alnum:]] for alphanumerics, and [[:space:]] for whitespace. POSIX also splits into two dialects: BRE (basic, used by grep and sed) requires backslashes before \(, \), \{, \?, and \+, while ERE (extended, used by grep -E and egrep) treats those as special by default. POSIX has no lookaround, no non-greedy quantifiers, and limited backreferences. The Flavors tab spells out exactly which features each engine supports, so before porting a pattern from your code into a shell command you can check whether the shorthand and assertions you rely on actually exist there.

By default a regex returns only the first match. To find every occurrence you add the global flag, g, to the pattern. Without g, JavaScript's exec and match return the single first hit; with g set, match returns an array of all matches and a loop with exec walks through each one. The g flag also tracks position via lastIndex, which is why repeatedly calling a global regex advances through the string. Pair g with i for case-insensitive matching across the whole input. In the inline tester, type g into the flags field and the match count updates to show every occurrence, with each one highlighted and listed by its character index; remove g and you will see it collapse back to just the first match. The Flags section explains g, i, m, s, u, and y with examples.