Regex Tester & Explainer

Regular expressions are powerful but notoriously difficult to debug and read. This free tester evaluates regular expressions in real time, highlights matches, calculates match statistics, tests string substitutions, and translates dense regex syntax into plain-English explanations. It also flags catastrophic backtracking (ReDoS) risks before patterns reach production. Everything runs entirely in your browser—no text or patterns are ever uploaded.

Free tool · nothing is uploaded

Test & explain regular expressions

Real-time matching, token-by-token plain-English breakdown, substitution testing, and ReDoS safety auditing.

  • Live match highlighting
  • Token-by-token explainer
  • Substitution tester
  • ReDoS safety audit

Pattern & configuration

Do not include enclosing slashes. Escape meta-characters (e.g. \., \?, \*) to match literal symbols.

g: all matches; i: ignore case; m: multiline ^/$; s: dotAll.

Select a preset to load sample pattern and test data.

Use $& for full match, $1, $2 for capture groups, or $<name> for named groups.

Safety & match score

95 safety & fit

A Optimal & Safe Pattern

Valid ECMAScript regular expression

Matched text coverage: 58% 3 matches found

  • Matches 3
  • Capture groups 0
  • Exec time < 0.1ms
  • Pattern len 48 chars

Test string & interactive match inspector

Matches are highlighted in real time below. Click any highlighted match to inspect group details.

Highlighted match viewer 3 matches

Token-by-token regex explainer

Every token, quantifier, anchor and character group translated into plain English.

Token Category Plain-English explanation

Safety & optimization advice

    How the regex tester and explainer works

    Regular expressions (regex) define search patterns across text using formal grammar. When processing user input, web scraping, data migrations, or form validations, small mistakes in regex syntax lead to missed matches, false positives, or devastating server freezes caused by catastrophic backtracking. This browser-based tester evaluates ECMAScript-compliant regular expressions against your sample text, inspecting each token, measuring performance, and verifying safety.

    The tool operates through four integrated phases:

    1. Compilation & Syntax Verification: Your pattern and active flags are compiled using JavaScript's native RegExp engine. Any structural errors—such as dangling quantifiers, unclosed character classes, or invalid quantifier ranges—are caught instantly and pinpointed with error diagnostics.
    2. Safe Match Execution & Loop Prevention: The engine executes global (/g) or singular searches while guarding against infinite zero-width match loops. Matches are tagged with exact character indices, match lengths, indexed capture groups ($1, $2), and named capture groups ($<name>).
    3. Token-by-Token Explainer: The raw pattern is decomposed into individual syntactic tokens: anchors (^, $, \b), character sets (\d, \w, [a-z]), quantifiers (greedy vs. lazy), and lookarounds. Each token is explained in clear, accessible English.
    4. ReDoS Vulnerability Auditing: The pattern is analyzed for nested quantifier repetition (e.g. (a+)+ or ([a-z]+)*). These constructs cause polynomial or exponential backtracking when evaluated against non-matching strings, which can freeze server threads.

    Anatomy of regular expression syntax

    Every regular expression is constructed from a combination of literals, metacharacters, character classes, quantifiers, anchors, and group constructs. Understanding how these elements interact is essential for writing robust expressions.

    Anchors and word boundaries

    Anchors do not consume characters; instead, they assert that the engine is positioned at a specific boundary within the string or line:

    • ^ (Caret): Asserts the start of the entire string. When the multiline flag m is enabled, it asserts the start of any line immediately following a newline character.
    • $ (Dollar): Asserts the end of the entire string, or the end of a line when multiline flag m is active.
    • \b (Word Boundary): Matches a zero-width position where a word character (\w) meets a non-word character (\W) or the boundary of the string. Essential for preventing substring partial matches (e.g., \bcat\b matches "cat" but not "catch" or "scat").
    • \B (Non-Word Boundary): Asserts that the current position is not a word boundary.

    Character classes and shorthands

    Character classes match one character from a designated set of possibilities:

    Class Equivalent Set Description
    \d [0-9] Matches any ASCII numerical digit from 0 through 9.
    \D [^0-9] Matches any character that is not a digit.
    \w [a-zA-Z0-9_] Matches any ASCII word character: letters, digits, and underscores.
    \W [^a-zA-Z0-9_] Matches any character that is not a word character.
    \s [ \t\n\r\f\v] Matches any whitespace character including spaces, tabs, and line breaks.
    \S [^ \t\n\r\f\v] Matches any non-whitespace character.
    . (Dot) [^\n\r] Matches any character except line break terminators (matches newlines too if s flag is set).
    [a-z0-9] Custom range Matches any single character within the specified inclusive ranges.
    [^a-z] Negated range Matches any single character that does not appear inside the brackets.

    Quantifiers: greedy versus lazy

    Quantifiers specify how many times the preceding element may repeat. By default, quantifiers in regular expressions are greedy: they consume as many characters as possible before backtracking if subsequent tokens fail to match. Appending a question mark (?) turns any quantifier lazy (or non-greedy), causing it to match as few characters as possible.

    Greedy Lazy Count Behavior Difference
    * *? 0 or more Greedy consumes entire remaining string then backs up; lazy matches 0 first and advances character by character.
    + +? 1 or more Greedy consumes all matching characters; lazy stops after the first valid match.
    ? ?? 0 or 1 Greedy attempts to match 1 character first; lazy attempts to match 0 characters first.
    {n,m} {n,m}? Between n and m Greedy tries m matches down to n; lazy tries n matches up to m.

    Capturing groups, non-capturing groups, and lookarounds

    Parentheses serve three distinct purposes in regular expressions:

    1. Capturing Groups (pattern): Sub-patterns enclosed in parentheses isolate matched text into memory registers accessible via numbered backreferences ($1, $2) or array elements. Useful for extracting parts of a string (such as extracting domain names from email addresses).
    2. Named Capturing Groups (?<name>pattern): Available in modern JavaScript (ES2018+), named groups assign explicit identifiers to captures, making replacement patterns and data pipelines far more readable: $<name>.
    3. Non-Capturing Groups (?:pattern): Groups tokens together for applying quantifiers or alternation without storing the result in memory, saving computation overhead.
    4. Lookahead and Lookbehind Assertions:
      • (?=pattern) Positive lookahead: Asserts that what follows matches pattern without consuming characters.
      • (?!pattern) Negative lookahead: Asserts that what follows does NOT match pattern.
      • (?<=pattern) Positive lookbehind: Asserts that what precedes matches pattern.
      • (?<!pattern) Negative lookbehind: Asserts that what precedes does NOT match pattern.

    The danger of catastrophic backtracking (ReDoS)

    Most programming languages—including JavaScript (V8), Python, PHP, Java, and Ruby—use Non-deterministic Finite Automaton (NFA) regex engines. An NFA engine tries every possible branch of a regular expression until it finds a match or exhausts all combinations.

    When a pattern contains nested or overlapping quantifiers such as (a+)+$ or ([a-zA-Z]+)*$, an input string with repeated "a" characters followed by an unexpected trailing character (e.g. aaaaaaaaaaaaaaaaaaaaaaaaaaaa!) triggers an explosion of backtrack permutations. For an input of length N, the engine may explore 2N branching paths.

    A string of just 30 characters can cause an NFA engine to perform over one billion backtracking calculations, pegging a server CPU core at 100% and causing a Regular Expression Denial of Service (ReDoS). Our tester audits every pattern for nested repetition and warns you before you ship vulnerable regexes to production or cloud workers.

    Worked examples

    Use Case Recommended Pattern Key Mechanics
    Email Address ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ Anchors prevent partial prefix/suffix matches; character classes permit valid email symbols; requires at least a 2-letter TLD.
    URL with Protocol https?:\/\/(?:www\.)?[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{2,6}\b[-a-zA-Z0-9()@:%_\+.~#?&//=]* Matches both HTTP and HTTPS; non-capturing group ignores www; handles query parameters and URL fragments safely.
    ISO 8601 Date \b(?<year>\d{4})-(?<month>0[1-9]|1[0-2])-(?<day>0[1-9]|[12]\d|3[01])\b Enforces strict 4-digit years, 01-12 months, and 01-31 days using alternation; captures into named groups.
    UUID / GUID \b[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-5][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}\b Validates standard RFC 4122 UUID structure, including version nibble (1-5) and variant nibble (8, 9, a, b).

    Limitations and browser requirements

    • Engine Standard: This tool runs directly in your browser using the ECMAScript RegExp engine. Features specific to PCRE (Perl-Compatible Regular Expressions) such as atomic groups ((?>...)), possessive quantifiers (++, *+), recursive patterns ((?R)), or callouts are not supported in standard JavaScript.
    • Lookbehind Compatibility: Positive and negative lookbehinds ((?<=...) and (?<!...)) require modern evergreen browsers (Chrome 62+, Firefox 78+, Safari 16.4+, Edge 79+). Older legacy browsers will fail on lookbehind compilation.
    • Client-Side Processing: No test strings or patterns are uploaded to any server. Testing occurs entirely on your device, ensuring complete privacy for sensitive logs, API keys, or proprietary data.
    • Match Cap: For global search queries, matches are capped at 500 occurrences to safeguard browser memory from freezing on massive inputs.

    Frequently asked questions

    What is the difference between greedy and lazy matching?

    Greedy matching (the default in regex) consumes as many matching characters as possible before checking if the remainder of the pattern matches. Lazy matching (enabled by appending ? after a quantifier, such as +? or *?) consumes as few characters as possible, stopping at the very first point where the following token matches. For example, given the text <b>bold</b> text, the greedy expression <.*> matches <b>bold</b>, whereas the lazy expression <.*?> matches only <b>.

    How do the regex flags g, i, m, s, and u work?

    Flags alter how the regular expression engine behaves: g (global) finds all matches throughout the text rather than stopping after the first match; i (ignore case) matches uppercase and lowercase characters interchangeably; m (multiline) treats ^ and $ as the start and end of every line instead of the entire string; s (dotAll) allows the dot wildcard . to match newline characters; and u (Unicode) enables strict UTF-16 code point processing.

    Why is my regex hanging or freezing the browser tab?

    A frozen tab is almost always caused by catastrophic backtracking (ReDoS). When an expression contains nested quantifiers like (a+)+ or multiple overlapping repetitions, an input that almost matches but fails at the very end forces the engine to test an exponential number of permutations. Rewriting the pattern with exclusive character classes or removing nested repetitions eliminates the bottleneck.

    How can I replace text using regex capture groups?

    In our tester, enter your replacement string into the Substitution field. You can reference entire matches with $&, numbered capture groups with $1, $2, and named capture groups with $<name>. For example, using the pattern (\d{3})-(\d{4}) and substitution $1.$2 will reformat 555-1234 into 555.1234.

    Does this tool support PCRE atomic groups or recursion?

    No. Browsers execute JavaScript's ECMAScript regex engine, which lacks PCRE-specific features like atomic groups (?>...) and recursion (?R). However, you can achieve equivalent non-backtracking behavior in JavaScript using lookaheads and capture groups: (?=(pattern))\1.

    Is my test data uploaded to any server?

    No. All regex compilation, string matching, token explanation, and replacement calculations take place locally inside your browser's JavaScript engine. No data leaves your machine, making it completely safe for proprietary data, passwords, and PII.

    Related developer & data tools

    • PII Scanner — Detect sensitive personal data, emails, and credentials across bulk CSV files using regex.
    • Bulk Find & Replace — Perform mass multi-rule replacements across unstructured text and spreadsheets.
    • Merge-Variable Checker — Validate personalization tokens and variables across template strings.

    Next step

    Building automated data enrichment pipelines, lead extraction scripts, or webhook handlers? That is what mizanursguide.com specializes in. Explore our marketing automation and data workflows to connect your data cleanly without manual copy-paste.