Regex ReDoS Checker: Find Catastrophic Backtracking Before Production
Use Regex ReDoS Checker to scan regular expressions for catastrophic backtracking, risky quantifiers, and unsafe alternations. Get an instant safety score and test patterns entirely in your browser.
Table of Contents
Regular expressions are compact, powerful, and easy to add to an application. They can also become a denial-of-service risk when a backtracking regex engine spends an unreasonable amount of time exploring possible matches. This vulnerability is known as Regular Expression Denial of Service, or ReDoS.
Regex ReDoS Checker gives you a fast first-pass security review before a pattern reaches production. Paste a pattern, inspect the detected risk signals, and see a safety score without uploading your code or regex to a server. The analysis runs 100% in your browser.
The checker is especially useful during code review, while validating user-input filters, and when migrating patterns between runtimes. It does not replace a full security assessment, but it helps surface common dangerous structures early, when they are still inexpensive to fix.
Why Use Regex ReDoS Checker?
- Catch classic ReDoS structures: Identify nested quantifiers such as (a+)+, quantified groups such as (a*)+, and other patterns associated with catastrophic backtracking.
- Review patterns before deployment: Run a quick check during development or pull-request review instead of waiting for a slow request to become a production incident.
- Understand why a pattern is risky: Each detected issue includes a practical explanation, so the result is useful for learning and remediation rather than being only a red warning.
- Check syntax at the same time: The tool attempts to compile the expression and reports invalid JavaScript regular-expression syntax before you test it.
- Test a sample string instantly: Use the built-in test input to confirm whether the regex matches expected data while reviewing its performance risks.
- Keep sensitive patterns private: Analysis is client-side. Your regex and test string remain in the browser instead of being sent to an API.
Key Features
| Feature | What it checks | Why it matters |
|---|---|---|
| Syntax validation | Attempts to compile the supplied regex | Finds expressions that would fail at runtime |
| Risk pattern scan | Nested quantifiers, quantified groups, overlapping classes, and alternation | Highlights common backtracking hazards |
| Lookbehind review | Detects lookbehind usage and risky quantified lookbehind structures | Flags compatibility and performance concerns |
| Safety score | Produces a score with safe, caution, or danger severity | Provides an easy-to-scan review signal |
| Sample matcher | Tests the regex against a string in the browser | Confirms expected matching behavior |
| Private processing | Performs analysis locally | Keeps patterns and test data on your device |
A few implementation details are worth remembering:
- The checker looks for multiple competing wildcards such as .* or .+, which can force a backtracking engine to reconsider many possible partitions of the same input.
- It recognizes adjacent quantified parts that can consume overlapping characters, for example [a-z]+[a-z]+. The exact risk depends on the surrounding expression and input, but the structure deserves review.
- Lookbehind is reported because browser support can vary across older environments. A syntactically valid pattern in one runtime is not automatically portable to every target browser.
How to Use
- Open the checker: Visit Regex ReDoS Checker in a modern browser.
- Paste the pattern: Enter the regex without assuming that a successful match means the pattern is safe. You may include the expression exactly as it appears in your application.
- Read the validation result: If compilation fails, fix the syntax error first. If it compiles, review the safety score and each issue explanation.
- Try representative input: Enter a normal matching string and a deliberately challenging non-matching string. Long input that almost matches is often more revealing than a short happy-path example.
- Remediate and recheck: Simplify the expression, remove ambiguous overlap, or choose a safer matching strategy. Run the revised pattern through the checker again before shipping it.
Do not paste production secrets into any online tool, even when processing is designed to be local. Treat regexes as potentially sensitive if they include internal identifiers, proprietary formats, or embedded business rules.
Understanding ReDoS and Catastrophic Backtracking
Many mainstream regex engines use backtracking. When a pattern contains alternatives and quantifiers, the engine may try one path, discover that it cannot complete the match, and then return to an earlier decision to try another path. This is useful because it supports expressive features, but the number of paths can grow rapidly.
Consider (a+)+$. The inner a+ can consume a run of a characters, while the outer + can divide that run into different repetitions. On a string made mostly of a characters followed by a non-matching character, the engine may explore many decompositions before concluding that the final $ cannot succeed. The longer the input, the more expensive the failure can become.
A related issue appears when alternatives overlap. In (a|a)*, both branches accept the same character, so the engine has no useful reason to prefer one. Similar ambiguity can occur in expressions such as (a|aa)+ or with broad tokens placed next to one another. A pattern does not need to look exactly like a famous “evil regex” to deserve review; the important question is whether multiple branches can consume the same input in many ways.
The score from Regex ReDoS Checker is a heuristic signal. A danger result means the structure matches a known risk pattern and should be investigated. A safe result means the implemented checks found no common red flags; it is not a mathematical proof that every regex engine and every input are safe. Runtime behavior depends on the engine, flags, input size, surrounding code, and timeout controls.
For high-risk services, combine static review with adversarial performance tests. Consider a linear-time engine such as an RE2-style implementation when you do not need backreferences or other backtracking-specific features. Enforce maximum input lengths, set request or operation timeouts where supported, and avoid allowing arbitrary user-supplied regexes to run inside a shared worker without isolation.
Practical Use Cases
Validating form and API input
A registration or API endpoint may use a regex to validate usernames, email-like values, identifiers, or URLs. Test both expected values and long malformed values. A validator that is harmless on a 20-character example can become expensive when an attacker submits thousands of nearly matching characters.
Reviewing pull requests
Add the checker to a developer’s manual review workflow. When a pull request introduces a complex pattern, paste it into the tool and record the result in the review discussion. This is a lightweight complement to unit tests and security scanning, particularly for patterns hidden in configuration files.
Building search and filtering features
Search boxes, log filters, and admin dashboards sometimes accept a regex from a user. If arbitrary patterns are supported, the threat model is different from a fixed application regex. Review the pattern policy, cap input size, restrict syntax where possible, and prefer a non-backtracking engine for untrusted expressions.
Migrating between runtimes
A pattern may move from a server-side language to JavaScript or from one service to another. Use the checker to catch unsupported lookbehind and compare behavior with representative inputs. Then verify the expression in the exact production runtime, because a browser-side check cannot model every engine.
Best Practices
- Prefer simple expressions: A clear sequence of character classes is easier to audit than a deeply nested combination of groups and quantifiers.
- Avoid ambiguous overlap: Do not place broad quantified tokens next to one another when they can consume the same characters.
- Anchor intentionally: Anchors can reduce search work, but they do not automatically make a nested or ambiguous expression safe.
- Bound input: Enforce reasonable maximum lengths before running a regex, especially on public endpoints.
- Use safe engines when possible: Choose a linear-time or RE2-compatible engine for untrusted patterns and inputs when its feature set is sufficient.
- Test failure paths: Include long, almost-matching strings in automated performance tests. ReDoS often appears on rejection rather than on a successful match.
Check Your Regex Before You Ship
A regex review takes seconds, while diagnosing a CPU spike caused by one malformed input can take hours. Start with Regex ReDoS Checker, understand the flagged structure, and then verify the fix in your application’s actual runtime. Combine the result with input limits, timeouts, and security-focused tests for a defense-in-depth approach.
Related Tools You Might Like:
- Regex Tester — check matching behavior against sample strings.
- Regex Generator — build patterns from structured requirements.
- Regex Cheatsheet — quickly look up syntax and common constructs.
Happy auditing, and safer regex building!