Regex Performance Calculator
GeneralPaste any regex pattern to instantly estimate its time complexity, detect catastrophic backtracking (ReDoS), and calculate execution time at your target scale.
Last updated: April 2026
This calculator is designed for real-world usage based on typical engineering scenarios and publicly available documentation.
A regex performance calculator helps developers catch slow patterns before they reach production. Most regex engines use backtracking — when a pattern fails to match, the engine reverses and tries alternative paths. For simple patterns this is harmless, but certain constructions like nested quantifiers (e.g. (a+)+) can cause the match time to grow exponentially with input length, a class of vulnerability known as ReDoS (Regular Expression Denial of Service). This calculator analyses your pattern for quantifier count, alternation branches, and nested quantifier structures. It classifies the result as O(n), O(n log n), O(n²), or O(n³) and converts that to an estimated wall-clock time using a 100 million steps-per-second baseline — a reasonable figure for V8, PCRE2, and most production-grade engines running on modern hardware. The tool is useful for backend engineers validating user-supplied input patterns, security reviewers auditing APIs that accept regex strings, and frontend developers who need to understand why a particular form validation hangs the browser tab on long inputs. Enter your pattern and a realistic input length — worst-case strings are usually close to the pattern length — then adjust executions to model throughput. Note that this is an analytical estimate, not a benchmark. Actual performance depends on the specific engine, JIT compilation, input distribution, and early-exit optimisations. Use the results as a relative signal: O(n) patterns are safe, O(n²) patterns warrant review, and O(n³) patterns with nested quantifiers should be rewritten before deployment.
How the Regex Performance Calculator Works
1. Enter your regex pattern — the calculator strips character classes and counts quantifiers (* + ? {n,m}) and alternation operators (|) in the remaining structure. 2. It checks for nested quantifiers: a group containing a quantifier that is itself followed by a quantifier, e.g. (a+)+ or ([a-z]{2,})*. 3. The complexity class is determined: O(n) for simple patterns, O(n log n) for many quantifiers or alternations, O(n²) for combined alternation and quantifiers, O(n³) for nested quantifiers. 4. Estimated steps = string length raised to the complexity exponent (1, 1.5, 2, or 3). 5. Estimated time per execution = steps ÷ 100,000,000 × 1,000 ms. 6. A performance rating (Excellent / Good / Fair / Poor / Critical) is assigned based on the time per execution.
Formula
Estimated Steps = String Length ^ Complexity Exponent Complexity Exponent: No nested quantifiers, ≤ 2 quants, 0 alternations → 1 (O(n)) ≥ 3 quantifiers OR ≥ 1 alternation → 1.5 (O(n log n)) ≥ 3 quantifiers AND ≥ 2 alternations → 2 (O(n²)) Nested quantifier detected → 3 (O(n³) — ReDoS) Estimated Time (ms) = (Estimated Steps ÷ 100,000,000) × 1,000 Total Time (ms) = Time per Execution × Number of Executions String Length — characters in the input string to match Complexity Exponent — derived from pattern structure above 100,000,000 — baseline regex steps per second (modern engine estimate)
Example Regex Performance Calculations
Example 1 — Simple email domain validator (O(n))
Pattern: ^[a-z0-9]+\.[a-z]{2,6}$
Quantifiers: 2 Alternations: 0 Nested: No
Complexity: O(n) Exponent: 1
String length: 50 chars
Estimated steps: 50 ^ 1 = 50
Time per exec: 50 ÷ 100,000,000 × 1,000 = 0.0005 ms
Rating: Excellent
→ Safe for any production workload. Example 2 — URL validator with multiple quantifiers (O(n log n))
Pattern: ^https?://([a-z0-9-]+\.)+[a-z]{2,}(/[^\s]*)?$
Quantifiers: 4 Alternations: 0 Nested: No
Complexity: O(n log n) Exponent: 1.5
String length: 200 chars
Estimated steps: 200 ^ 1.5 ≈ 2,828
Time per exec: 2,828 ÷ 100,000,000 × 1,000 ≈ 0.028 ms
Rating: Good
→ Acceptable. At 10,000 executions/sec total time ≈ 283 ms. Example 3 — Catastrophic backtracking pattern (O(n³) ReDoS)
Pattern: ^(([a-z]+)*)+$ Quantifiers: 3 Alternations: 0 Nested: Yes Complexity: O(n³) Exponent: 3 String length: 30 chars (e.g. "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!") Estimated steps: 30 ^ 3 = 27,000 Time per exec: 27,000 ÷ 100,000,000 × 1,000 = 0.27 ms String length: 50 chars Estimated steps: 50 ^ 3 = 125,000 → 1.25 ms String length: 100 chars Estimated steps: 100 ^ 3 = 1,000,000 → 10 ms — Poor → Rewrite to atomic group or possessive quantifier to eliminate backtracking.
Tips to Improve Regex Performance
- › Anchor your patterns. Adding ^ and $ eliminates backtracking by preventing the engine from searching for the pattern at every position in the string.
- › Avoid nested quantifiers entirely. Patterns like (a+)+ or (x*y*)+ are the primary source of catastrophic backtracking. Flatten them to a single non-nested quantifier.
- › Prefer non-capturing groups (?:...) over capturing groups (...) when you do not need the captured value — they skip the overhead of storing match offsets.
- › Use character classes instead of alternation for single characters. [aeiou] is faster than (a|e|i|o|u) because it avoids branching.
- › Test against worst-case inputs, not just happy-path strings. A valid email address will match quickly; a 200-character string of repeated characters designed to maximise backtracking will not.
- › In Node.js and browser environments, consider using a linear-time regex engine such as <a href="https://github.com/google/re2" rel="noopener">RE2</a> via the <code>re2</code> npm package for user-supplied patterns — it guarantees O(n) matching at the cost of some PCRE features.
Notes
- › Results are estimates and may vary based on actual usage.
- › Always validate against your production environment.