Regex Tester & Explainer

ReDoS: When Testing a Pattern Here Can Save You From an Outage Later

This tester runs entirely in your browser, so it's a safe place to discover a dangerous pattern before it ever reaches a server. Certain regex shapes — nested quantifiers over overlapping alternation, like (a+)+b or ([a-zA-Z]+)* — can cause catastrophic backtracking, where a specially crafted input makes the matching engine's runtime explode exponentially with input length. If a pattern you're testing here suddenly makes the browser tab freeze on an input that's only a few characters longer than the last one you tried, that's not a coincidence — it's the signature of exponential backtracking, and it means the same pattern would pin a CPU core at 100% for seconds or minutes if it processed attacker-controlled input on a production server. This is a real, named vulnerability class — ReDoS, Regular Expression Denial of Service — and it has caused genuine outages when a single malicious or malformed input hit a vulnerable validation regex on a public-facing endpoint.

Testing here is a legitimate way to screen for this before deployment: paste your pattern, then deliberately try a long, repetitive, almost-but-not-quite-matching input (a long run of the character your quantifier repeats, followed by a character that breaks the match). If match time visibly degrades as you lengthen that input, rewrite the pattern to avoid the nested-quantifier shape — usually by making the inner group possessive-equivalent with a more specific character class, or restructuring the alternation so the branches don't overlap — before it ever reaches a form validator or an API gateway rule.

The Alert Rule That Quietly Stopped Firing

An illustrative, generic scenario: a platform team writes a log-based alert rule to catch a specific error signature in application logs, using a regex built and confirmed against a handful of sample log lines pulled from a recent incident. The pattern matches those samples perfectly and the rule ships. Weeks later, the same underlying error starts occurring again, but a minor logging library upgrade changed the timestamp format from a fixed-width field to a variable-width one — and the alert rule's regex, which had accidentally hardcoded an assumption about field width via a fixed-count quantifier, silently stops matching. Nobody notices for days, because "the alert didn't fire" produces no signal at all; the failure mode of an untested regex is invisible until someone happens to search the raw logs and finds the errors were there all along. The lesson generalizes: any regex feeding an alert, dashboard, or log parser should be tested here against multiple real samples spanning normal variation — not just the one log line that prompted writing it — and revisited whenever an upstream logging format changes.

What This Tool Actually Gets Reached For

• Validating a log-parsing regex against real variation before deploying it: Test against several representative log lines — not just one — to catch optional fields, inconsistent whitespace, and timestamp format differences before the pattern reaches a production log pipeline.
• Building and verifying form or API input validation: Confirm an email, IP, version-string, or custom-identifier pattern correctly accepts valid input and rejects malformed input, including edge cases like leading zeros or unusual but technically valid formats.
• Reverse-engineering an inherited pattern: Paste a dense regex copied from a legacy codebase or an old Stack Overflow answer into the built-in explainer to get a token-by-token, color-coded breakdown of what each part actually does before deciding whether to trust, keep, or rewrite it.
• Confirming an Nginx location or rewrite rule matches the right URLs: Test a proposed location match pattern against sample request paths to verify it captures the intended segment before pushing a reverse-proxy configuration change live.

What Happens Behind the Highlighted Matches

The tool builds a JavaScript RegExp object from your pattern and selected flags with new RegExp(pattern, flags), then repeatedly calls RegExp.prototype.exec() in a loop to walk through every match in the test string, recording each match's start index, matched text, and any capture group values along the way. The live highlighting simply wraps each matched span in the test string with a styled element based on those indices. The pattern explainer works independently: it tokenizes the raw pattern string into its constituent pieces — character classes, quantifiers, anchors, groups — and maps each one to a plain-English, color-coded label, all computed client-side as you type with no network round-trip involved at any point.

Frequently Asked Questions