live regex tester and debugger. write a pattern, paste test text, and see matches highlighted in real time.
matches will be highlighted here
Paste a regular expression and a chunk of test text, and the tester highlights every match in real time. Toggle case sensitivity, global, and multiline flags. See capture groups per match. Test in the JavaScript flavor of regex, which is the dialect every browser and Node.js process uses.
“Regex” is the family name of half a dozen related but incompatible dialects. The pattern that works in your editor's find-and-replace might not work in your codebase's linter, and a regex that works in JavaScript often does not work in Python, PostgreSQL, or grep without modification.
The major flavors:
grep, sed, and many shell utilities. Two sub-flavors (BRE and ERE) that disagree on whether + needs escaping.The differences matter. A regex with (?<name>...) named groups works in JavaScript and PCRE but not POSIX. A regex with backreferences works in PCRE and JavaScript but not RE2. If you are debugging a regex against the wrong tester, you can spend an hour confused about why the same pattern works in one place and not another.
The single most common source of regex confusion is how quantifiers consume input.
*, +, ?, {n,m}) — consume as much as possible, then back off if the rest of the pattern does not match.*?, +?, etc.) — consume as little as possible, then expand if the rest of the pattern requires more.*+, ++) — consume as much as possible and never back off, even if it means the overall match fails. Not supported in JavaScript.The classic illustration: matching <.*> against <a> hello <b> with greedy * matches the entire string from <a> through <b>. Switching to lazy <.*?> matches just <a>. The difference is purely the quantifier behavior; the rest of the pattern is identical.
Regex engines that implement backreferences and certain nested patterns can fall into exponential-time matching on malicious or accidentally pathological inputs. This is the ReDoS (regex denial of service) attack class.
Classic example: the pattern (a+)+$ matched against the string aaaaaaaaaaaaaaaaaaaaab takes time exponential in the number of as. Adding a few more as pushes the matcher into seconds, then minutes, then hours.
The shape that causes this is generally nested quantifiers on overlapping alternatives — any time the engine has multiple ways to partition the same input across two quantifiers, it has to try all of them when the overall pattern does not match. RE2 (the Go flavor) is built specifically to avoid this by giving up backreferences in exchange for guaranteed linear time.
If your regex is slow on real inputs
(a*)*, (a+)*b) and overlapping alternatives ((a|a)*). Either rewrite to remove the ambiguity, or anchor the pattern so the engine can fail faster.u too.^ and $ match start/end of every line, not just the start/end of the input.. match newlines. Without this, the dot does not cross line boundaries.Regex testing is a perfect candidate for client-side execution: the browser ships a regex engine, the operation is instant, and your test data — which might be log entries, production text, or sensitive content — has no business being uploaded to a third party. The tester runs every match in your browser using the native regex engine, the same one your code will use in production.
Paste a regular expression and a chunk of test text, and the tester highlights every match in real time. Toggle case sensitivity, global, and multiline flags. See capture groups per match. Test in the JavaScript flavor of regex, which is the dialect every browser and Node.js process uses.
“Regex” is the family name of half a dozen related but incompatible dialects. The pattern that works in your editor's find-and-replace might not work in your codebase's linter, and a regex that works in JavaScript often does not work in Python, PostgreSQL, or grep without modification.
The major flavors:
grep, sed, and many shell utilities. Two sub-flavors (BRE and ERE) that disagree on whether + needs escaping.The differences matter. A regex with (?<name>...) named groups works in JavaScript and PCRE but not POSIX. A regex with backreferences works in PCRE and JavaScript but not RE2. If you are debugging a regex against the wrong tester, you can spend an hour confused about why the same pattern works in one place and not another.
The single most common source of regex confusion is how quantifiers consume input.
*, +, ?, {n,m}) — consume as much as possible, then back off if the rest of the pattern does not match.*?, +?, etc.) — consume as little as possible, then expand if the rest of the pattern requires more.*+, ++) — consume as much as possible and never back off, even if it means the overall match fails. Not supported in JavaScript.The classic illustration: matching <.*> against <a> hello <b> with greedy * matches the entire string from <a> through <b>. Switching to lazy <.*?> matches just <a>. The difference is purely the quantifier behavior; the rest of the pattern is identical.
Regex engines that implement backreferences and certain nested patterns can fall into exponential-time matching on malicious or accidentally pathological inputs. This is the ReDoS (regex denial of service) attack class.
Classic example: the pattern (a+)+$ matched against the string aaaaaaaaaaaaaaaaaaaaab takes time exponential in the number of as. Adding a few more as pushes the matcher into seconds, then minutes, then hours.
The shape that causes this is generally nested quantifiers on overlapping alternatives — any time the engine has multiple ways to partition the same input across two quantifiers, it has to try all of them when the overall pattern does not match. RE2 (the Go flavor) is built specifically to avoid this by giving up backreferences in exchange for guaranteed linear time.
If your regex is slow on real inputs
(a*)*, (a+)*b) and overlapping alternatives ((a|a)*). Either rewrite to remove the ambiguity, or anchor the pattern so the engine can fail faster.u too.^ and $ match start/end of every line, not just the start/end of the input.. match newlines. Without this, the dot does not cross line boundaries.Regex testing is a perfect candidate for client-side execution: the browser ships a regex engine, the operation is instant, and your test data — which might be log entries, production text, or sensitive content — has no business being uploaded to a third party. The tester runs every match in your browser using the native regex engine, the same one your code will use in production.
PDF utilities, image tools, developer helpers — all free, no signup.
Crop images with preset aspect ratios or freeform selection.
Generate favicons at every size from any image.
Encode text or files to Base64, or decode Base64 back to text and files.
Convert SVG files to high-resolution PNG at any scale.
Generate MD5, SHA-1, SHA-256, and SHA-512 hashes for text or files.
Add text or logo watermarks to photos with custom position, opacity, and tiling.