Pattern · Flags · Test · Replace · Explain

/ /g

Private Runs in your browser. Your pattern and test string stay on this page — nothing is sent to Mungomash, and no third-party API is contacted for the analysis.

Common patterns

Result

No matches yet


    
    
  


  
  

  
  

    

      
Match list

    

    

    
No matches.

    
  


  
  

    
Regex flavors — this page tests JavaScript only

    

      

        Every language with regex support has its own dialect. The major flavors:
      

      
    
        
  • JavaScript / ECMAScript — what this page tests. Built into every browser; the engine your client-side code runs against.
    • 
        
  • PCRE — Perl-Compatible Regular Expressions. Used in Perl, PHP's preg_* functions, and many command-line tools.
    • 
        
  • Python re — close to but not the same as PCRE. Verbose mode, named-group syntax, and inline flags differ.
    • 
        
  • Java / .NET — their own dialects, mostly PCRE-like with some quirks.
    • 
        
  • POSIX BRE / ERE — what classic grep and sed use. Older, more limited.
    • 
      

      

        The biggest gotchas when porting between flavors:
      

      
    
        
  • Lookbehind ((?<=…)) — ECMAScript only added support in 2018 (ES2018). Older browsers may not support it. PCRE supports only fixed-width lookbehinds; .NET supports variable-width.
    • 
        
  • Atomic groups ((?>…)) — PCRE / Java / .NET have them; JavaScript does not. They're the cleanest way to prevent catastrophic backtracking, and their absence is one reason JS regexes are easier to write but harder to make robust.
    • 
        
  • Possessive quantifiers (a++, a*+) — PCRE / Java / .NET; not JavaScript.
    • 
        
  • Named groups — JavaScript and .NET use (?<name>…); PCRE / Python prefer (?P<name>…) (PCRE accepts both).
    • 
        
  • Unicode property classes (\p{L}) — require the u flag in JavaScript; on by default in PCRE / Python with appropriate options.
    • 
      

      

        If your target is JavaScript, this page tells you the truth. If your target is something else, treat the result as a strong hint and double-check against your actual runtime.
      

    

  


  

    
Greedy, lazy, and the quantifier you reach for

    

      

        Quantifiers (*, +, ?, {n,m}) are greedy by default — they consume as much of the string as possible, then back off only if needed for the rest of the pattern to match. The lazy form — same quantifier with a trailing ? — consumes as little as possible.
      

      

        The classic mistake: trying to extract HTML tag content with <.+>. Against <b>hi</b>, greedy .+ matches b>hi</b (everything between the first < and the last >). The fix is the lazy form: <.+?>, which matches only <b>. (For HTML specifically, use a parser, not a regex — but that's a different sermon.)
      

    

  


  

    
Catastrophic backtracking

    

      

        A regex engine matches by trying alternatives and backtracking when one fails. For most patterns this terminates quickly. For some constructions — especially nested quantifiers like (a+)+ or alternations with overlapping options like (a|a)* — the number of paths the engine explores grows exponentially with the input length. A 30-character input can take seconds; a 50-character input can take hours.
      

      

        This page wraps every evaluation in a 200ms hard timeout. If the engine doesn't finish in time, the result panel shows a "likely catastrophic backtracking" message instead of locking the tab. The two patterns to watch for:
      

      
    
        
  • Nested quantifiers: (a+)+, (a*)*, (\w+)+. Almost always rewriteable as a single non-nested quantifier.
    • 
        
  • Alternations with overlapping branches: (a|a)*, (\w|\d)+. Make the branches mutually exclusive.
    • 
      

      

        The deeper fix is atomic groups ((?>…)) or possessive quantifiers, both of which JavaScript lacks. The pragmatic fix is to write less ambiguous patterns — or to switch to a non-backtracking engine like RE2 for any pattern fed user input.
      

    

  


  

    
Privacy — the actual mechanics

    

      

        Every operation on this page — tokenization, evaluation, highlighting, replacement preview — runs in your browser's JavaScript engine. The page makes zero network requests for the analysis. The only network calls in the page's lifecycle are:
      

      
    
        
  • Loading the page itself (HTML, the favicon, the logo) from mungomash.com.
    • 
        
  • Loading the Tailwind CSS framework from cdn.tailwindcss.com.
    • 
        
  • Loading the Google Analytics 4 tag for aggregate pageview metrics.
    • 
      

      

        None of those carry the pattern or the test string you paste. You can verify by opening your browser's DevTools network tab, typing a regex, and confirming no further requests fire. Safe for production data, internal log lines, or anything containing secrets.