Javascript | Toolbox Guides & Articles

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

RegEx Tester & Group Matcher

Toggle the g, i, m, s, and u flags live, inspect every capture group, and read a token-by-token explanation of what your pattern actually does.

Open RegEx Tester & Explainer →

Two Kinds of Regex Engine

Not all regex implementations share the same performance model, and the difference decides whether a pattern can be attacked.

	Backtracking (NFA)	Automaton (DFA/RE2)
Used by	JavaScript, Python `re`, Java, PCRE, .NET, Ruby	Go `regexp`, Rust `regex`, RE2, `grep -E`
Worst case	Exponential in input length	Linear in input length
Backreferences	Supported	Not supported
Lookaround	Supported	Not supported
Attackable	Yes	No

The trade is explicit: backtracking engines buy backreferences and lookaround at the cost of a worst-case time bound. JavaScript uses a backtracking engine, so every pattern you run against untrusted input carries a performance contract you need to understand.

How Backtracking Actually Fails

Take the pattern ^(a+)+$ and the input aaaa!.

The inner a+ is greedy, so it consumes all four a characters.
The outer + tries to repeat; there is nothing left, so it stops.
$ is checked. The next character is !, not end-of-string. Fail.
The engine backtracks: what if the inner a+ had taken three characters and the outer group repeated to take the fourth?
Fail again. What about 2 + 2? 2 + 1 + 1? 1 + 3? 1 + 1 + 2? 1 + 1 + 1 + 1?

Each of those is a distinct partition of the input, and every one must be tried before the engine can report no match. The number of ways to partition n items into ordered groups grows as 2^(n-1).

Input Length	Partitions Explored	Approximate Time
20	~524,000	milliseconds
25	~16.7 million	~0.1 seconds
30	~536 million	several seconds
35	~17 billion	minutes
40	~550 billion	hours

Add five characters, take thirty-two times longer. That is the entire mechanism behind ReDoS.

The critical precondition: the overall match must fail. A pattern that matches successfully finds its answer on the first greedy pass. This is why a vulnerable pattern looks perfectly fast in tests using valid inputs, and only detonates on malformed data — which is exactly what an attacker supplies.

The Three Vulnerable Shapes

Almost every real ReDoS reduces to one of three structures.

1. Nested Quantifiers

/^(a+)+$/ // quantifier inside a quantified group
/^(\d+)*$/
/^([a-z]+)+$/

The outer repetition and the inner repetition compete for the same characters. Ambiguity is the fuel.

2. Overlapping Alternation Under a Quantifier

/^(a|aa)+$/ // both branches match the letter a
/^(\w|\d)+$/ // \w already includes \d
/^(\s|\t|\n)*$/ // \s already includes \t and \n

If two branches can match the same text, the engine has two routes to every position, doubling the search space at each step.

3. Greedy Dot-Star Next to a Similar Pattern

/^(.*),(.*)$/ // both sides compete for every comma
/<div>(.*)<\/div>/ // .* happily crosses tag boundaries
/^(.*?)(.*?)(.*?)$/ // three lazy groups over one string

. matches almost everything, including the delimiter you are trying to find, so the engine must try every split point.

The Real-World Case

On 2 July 2019, Cloudflare’s global network returned HTTP 502 errors for roughly 30 minutes. The published post-mortem attributes the outage to a newly deployed WAF rule containing .*(?:.*=.*) — a nested greedy quantifier that consumed CPU across every machine in the fleet. One regular expression, global outage. The pattern shape above is not academic.

The Rewrites That Fix It

Replace nested quantifiers with a single one

/^(a+)+$/ // vulnerable
/^a+$/ // equivalent, linear

Ask what the outer quantifier adds. In the majority of vulnerable patterns, the answer is nothing.

Make alternation branches mutually exclusive

/^(a|aa)+$/ // vulnerable — branches overlap
/^a+$/ // same language, no ambiguity

/^(\w|\d)+$/ // vulnerable — \w contains \d
/^\w+$/ // same language

Swap greedy dots for negated character classes

/"(.*)"/ // dot crosses the closing quote and backtracks
/"([^"]*)"/ // cannot cross the delimiter at all — no ambiguity

This single substitution — [^delimiter]* instead of .* — is the highest-value change in practice. It also usually fixes the correctness bug where a greedy pattern swallowed two fields.

Emulate atomic groups with a lookahead

JavaScript has no atomic groups (?>...) and no possessive quantifiers a++. You can simulate them with a lookahead plus a backreference, which discards the inner group’s backtracking positions:

// Atomic equivalent of (?>\d+)
const atomic = /(?=(\d+))\1/;

The lookahead matches greedily, the backreference consumes exactly that text, and the engine cannot revisit the choice.

Bound the input before matching

const MAX = 512;

function safeTest(pattern, input) {
 if (typeof input !== 'string' || input.length > MAX) return false;
 return pattern.test(input);
}

Even an exponential pattern is harmless on 512 bytes. A length cap is a blunt instrument, but it is the one mitigation that works without understanding the pattern — apply it at every trust boundary.

Flags Worth Knowing

The tester exposes the five flags that matter most day to day:

Flag	Name	Effect	Gotcha
`g`	Global	Find all matches	Mutates `lastIndex` — see below
`i`	Ignore case	Case-insensitive matching	Unicode case folding needs `u`
`m`	Multiline	`^` and `$` match line boundaries	Does not change what `.` matches
`s`	DotAll	`.` also matches newlines	ES2018
`u`	Unicode	Pattern read as code points; enables `\p{...}`	Makes some previously legal escapes errors

ECMAScript also defines y (sticky), d (hasIndices, ES2022), and v (set notation, ES2024).

The `lastIndex` Trap

A regex literal with g carries mutable state. Reusing one across calls produces alternating results:

const re = /\d+/g;

re.test('123'); // true — lastIndex is now 3
re.test('123'); // false — resumes from index 3, finds nothing
re.test('123'); // true — lastIndex reset to 0 after the failure

Use a non-global regex for test, create the regex inside the function, or reset re.lastIndex = 0 before each use. The same hazard applies to exec in a loop — which is the intended use of g, but only when the loop consumes matches until null.

Detection and Tooling

Static analysis catches most real cases before deployment:

eslint-plugin-regexp with the no-super-linear-backtracking rule flags exponential and polynomial patterns in CI.
recheck performs both static and fuzzing-based analysis and reports an attack string.
Dependency advisories matter too: ReDoS reports against popular parsing and validation libraries are common, so keep npm audit in your pipeline.

Runtime containment for patterns you cannot rewrite — user-supplied search expressions, for instance:

Run matching in a worker thread you can terminate on a timeout. JavaScript regex evaluation is synchronous and uninterruptible on the main thread, so this is the only way to enforce a deadline.
Use a linear-time engine via bindings such as node-re2, accepting the loss of backreferences and lookaround.
Never compile a pattern supplied by a user without both of the above.

Step-by-Step: Diagnosing a Pattern with Toolbox

Open the tool: visit the .
Start from a preset or paste your own pattern into the pattern field.
Toggle the flags — g, i, m, s, u — and watch the match set change, which is the fastest way to confirm a flag is the actual cause of a bug.
Read the token explanation. The explainer breaks the pattern into tokens, which makes nested quantifiers and overlapping alternations visible rather than buried in punctuation.
Inspect capture groups against your sample text to verify indices and named groups resolve as expected.
Test the failure case, not the success case. Paste input that nearly matches — the right prefix with one wrong character at the end. Slow, vulnerable patterns only reveal themselves when the match fails.

Everything is evaluated by your browser’s own RegExp implementation, so test data never leaves the device — which matters when the sample text is a production log line or a customer record.

For the adjacent problem of validating structured text rather than free-form strings, is usually the better tool than a regular expression.

FAQ

Frequently Asked Questions

What is catastrophic backtracking? ▼

Catastrophic backtracking occurs when a backtracking regex engine must explore an exponential number of ways to divide the same input among nested quantifiers before it can conclude that no match exists. The pattern (a+)+$ against a long run of the letter a followed by an exclamation mark is the canonical example: each added character roughly doubles the work, so a string of 30 characters can take longer than a string of 29 by a full second.

What is a ReDoS attack? ▼

ReDoS, or Regular Expression Denial of Service, is an attack in which a request carries input crafted to trigger catastrophic backtracking in a server-side pattern. Because JavaScript regex evaluation is synchronous and blocks the event loop, a single such request can freeze an entire Node.js process. The Cloudflare global outage of 2 July 2019 was caused by exactly this class of bug in a WAF rule.

How do I know whether a pattern is vulnerable? ▼

Look for a quantifier applied to a group that already contains a quantifier or an alternation whose branches can match the same text, such as (a+)+, (\\s*,)*, or (.*)*. Then check whether the pattern can fail after that group, since backtracking only explodes on failure. Static analysers such as the ESLint no-super-linear-backtracking rule and the recheck library detect most real cases automatically.

Does adding an anchor fix a slow regex? ▼

Sometimes, but not reliably. Anchoring with a caret and dollar sign prevents the engine from retrying the pattern at every starting offset, which removes one polynomial factor. It does nothing about exponential blowup inside nested quantifiers, and a trailing dollar sign can make matters worse by guaranteeing the failure that triggers the full backtracking search. Restructuring the pattern is the real fix.

Should I validate email addresses with a regular expression? ▼

Not with a complex one. Full RFC 5322 address syntax is impractical to express as a maintainable pattern, and the elaborate email regexes circulating online are a frequent source of ReDoS. Use a minimal shape check such as one non-space run, an at sign, another non-space run containing a dot, then confirm the address by sending a verification message. Deliverability is the only real proof of validity.

URL Percent-Encoding Explained: RFC 3986, encodeURIComponent, and the %20 vs + Trap

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

URL Percent-Encoding Explained: RFC 3986, encodeURIComponent, and the %20 vs + Trap

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

URL Percent Encoder & Decoder

Switch between Encode and Decode tabs, paste any string, and get instant UTF-8-correct percent-encoding with one-click copy.

Open URL Encoder & Decoder →

Why URLs Need Encoding at All

A URL is not free-form text. It is a structured identifier in which certain characters carry meaning: ? starts the query, & separates parameters, # begins the fragment, / divides path segments.

The moment user data containing those characters is dropped into a URL, the structure collapses:

https://example.com/search?q=fish & chips#1
 ^ ^ ^
 | | └── parsed as a fragment
 | └──────── parsed as a parameter separator
 └─────────────── raw space, invalid in a URL

The server sees the parameter q with value fish , a second empty parameter named chips, and a fragment of 1. Percent-encoding solves this by giving every problematic character an unambiguous escaped form.

https://example.com/search?q=fish%20%26%20chips%231

The RFC 3986 Character Classes

Everything follows from three sets defined in RFC 3986.

Unreserved — safe everywhere, never needs encoding

A-Z a-z 0-9 - . _ ~

Section 2.3 states these are equivalent whether escaped or not. Encoding them is legal but pointless, and normalisers will decode them back.

Reserved — structurally meaningful, must be encoded inside data

Group	Characters	Role
gen-delims	`:` `/` `?` `#` `[` `]` `@`	Separate the major URL components
sub-delims	`!` `$` `&` `'` `(` `)` `*` `+` `,` `;` `=`	Delimiters inside a component

Everything else — must be encoded

Spaces, control characters, ", <, >, \, ^, `, {, |, }, and every non-ASCII character.

The Percent-Encoding Rule

character -> UTF-8 bytes -> %HH for each byte

Character	UTF-8 Bytes	Encoded
space	`20`	`%20`
`&`	`26`	`%26`
`/`	`2F`	`%2F`
`%`	`25`	`%25`
`é`	`C3 A9`	`%C3%A9`
`€`	`E2 82 AC`	`%E2%82%AC`
`🚀`	`F0 9F 9A 80`	`%F0%9F%9A%80`

RFC 3986 §2.1 says the hexadecimal digits should be uppercase; normalisers uppercase them, and %2f and %2F are equivalent on decode.

The Three JavaScript Functions

Function	Leaves Unencoded	Verdict
`encodeURIComponent()`	`A-Z a-z 0-9 - _ . ! ~ * ' ( )`	Use this for values
`encodeURI()`	The above plus `; / ? : @ & = + $ , #`	Only for a whole URL
`escape()`	Legacy, emits non-standard `%uXXXX`	Never use — deprecated in Annex B

The Decision Rule

Encoding a piece of data? encodeURIComponent. Encoding an already-assembled URL? encodeURI.

const query = 'fish & chips';
const redirect = 'https://example.com/next?id=7';

// Correct — each value encoded independently.
const url =
 `https://example.com/search?q=${encodeURIComponent(query)}` +
 `&next=${encodeURIComponent(redirect)}`;

// Wrong — encodeURI leaves & and = intact, so the nested URL's
// own parameters merge into the outer query string.
const broken = encodeURI(`https://example.com/search?next=${redirect}`);

That second case — a URL nested inside a query parameter — is the classic failure. encodeURI preserves ? and & because it assumes they are your delimiters, and an OAuth redirect_uri or a ?next= parameter promptly falls apart.

Where `encodeURIComponent` Diverges from RFC 3986

encodeURIComponent leaves !, ', (, ), and * unescaped, although RFC 3986 classifies them as sub-delims rather than unreserved. Most servers cope, but strict parsers and signature-verifying APIs — AWS Signature V4 and OAuth 1.0a among them — do not. For strict compliance:

function rfc3986(str) {
 return encodeURIComponent(str).replace(
 /[!'()*]/g,
 (c) => '%' + c.charCodeAt(0).toString(16).toUpperCase()
 );
}

`%20` or `+`: Two Specifications, One Space

This trips up experienced engineers because both are correct — in different contexts.

Context	Space Becomes	Governing Specification
Path segment	`%20`	RFC 3986
Fragment	`%20`	RFC 3986
`encodeURIComponent()` output	`%20`	ECMA-262
HTML form `GET` submission	`+`	`application/x-www-form-urlencoded`
`URLSearchParams` serialisation	`+`	WHATWG URL Standard

const p = new URLSearchParams();
p.set('q', 'fish & chips');
p.toString(); // "q=fish+%26+chips"

encodeURIComponent('fish & chips'); // "fish%20%26%20chips"

Both round-trip correctly through a form-encoding parser. But a generic RFC 3986 parser reading a path decodes + as a literal plus sign. The practical consequences:

A + in a path segment is a plus, not a space. /files/my+file.txt refers to a file whose name contains a plus.
Encode a literal plus in form data as %2B. Otherwise user+tag@example.com arrives as user tag@example.com — the reason so many sites mangle plus-addressed email.
Pick one serialiser per codebase. Mixing URLSearchParams with hand-built strings produces query strings that decode inconsistently.

Failure Modes Worth Recognising

1. Double Encoding

Percent-encoding is not idempotent, because % is itself an encodable character.

"a b" -> encode -> "a%20b" -> encode again -> "a%2520b"

The server decodes once and hands your application the literal string a%20b. Symptom: values that visibly contain %20, %3D, or %26 after parsing. Cause: a value encoded at construction time and encoded again by a helper, a proxy, or a template. Encode exactly once, as late as possible.

2. Encoded Slashes Rejected by the Server

%2F inside a path segment is legal, but Apache HTTP Server defaults to AllowEncodedSlashes Off and returns 404 for such requests. Never place a value that might contain / into a path segment — put it in the query string instead.

3. `URIError: URI malformed`

decodeURIComponent throws on a truncated or invalid escape such as %E0%A4 or %ZZ. Any decode of untrusted input needs a guard:

function safeDecode(value) {
 try {
 return decodeURIComponent(value);
 } catch {
 return value; // Malformed input — return it untouched rather than crashing.
 }
}

4. Non-ASCII Hostnames Are Not Percent-Encoded

Percent-encoding applies to the path, query, and fragment. Internationalised domain names use Punycode (RFC 3492/5891) instead: münchen.de becomes xn--mnchen-3ya.de. Encoding a hostname with encodeURIComponent produces an unresolvable name.

5. Encoded Data in Logs Is Still Sensitive

Percent-encoding is not obfuscation. Anything placed in a query string lands in server access logs, proxy caches, Referer headers, and browser history. Tokens and secrets belong in headers or a request body — a point worth remembering when .

When to Reach for Base64 Instead

Percent-encoding is designed for text that is mostly URL-safe already. Encoding binary data with it is wasteful — every byte becomes three characters.

For binary payloads inside a URL, use base64url (RFC 4648 §5), which substitutes - and _ for + and / and drops padding, producing a string made entirely of unreserved characters. This is exactly what JWT segments use. The covers the mechanics, and the shows base64url in production.

Step-by-Step: Encoding with Toolbox

Open the tool: visit the .
Choose a tab — Encode to convert raw text into percent-encoded form, Decode to reverse it.
Paste the value, not the whole URL. Encode one query parameter value or one path segment at a time, then assemble the URL yourself.
Read the output — the encoder applies the browser’s native encodeURIComponent, so UTF-8 multi-byte characters convert correctly.
Copy the result and drop it into your request, config file, or test case.
Diagnose double encoding by pasting a suspect value into the Decode tab. If one pass still leaves % sequences behind, the value was encoded twice upstream.

Encoding runs entirely on your device through the browser’s own URL functions, so tokens, search terms, and customer identifiers in the strings you are debugging are never transmitted.

FAQ

Frequently Asked Questions

What is the difference between encodeURI and encodeURIComponent? ▼

encodeURI is for a complete URL and deliberately leaves the reserved structural characters ; / ? : @ & = + $ , # untouched so the URL keeps working. encodeURIComponent is for a single piece of data being placed inside a URL, such as one query parameter value, and escapes those reserved characters as well. Use encodeURIComponent for values and encodeURI only when handling an entire URL string.

Why does a space sometimes become %20 and sometimes a plus sign? ▼

Percent-encoding under RFC 3986 always represents a space as %20. The plus sign comes from a different and older specification, application/x-www-form-urlencoded, which HTML forms and the URLSearchParams API use for query strings. Both forms are decoded as a space by a form-encoding parser, but a generic RFC 3986 parser treats a literal plus as a plus, which is why the same string can decode differently on two servers.

Which characters never need to be percent-encoded? ▼

RFC 3986 section 2.3 defines the unreserved set as the ASCII letters A to Z and a to z, the digits 0 to 9, and the four symbols hyphen, period, underscore, and tilde. These characters are equivalent whether encoded or not, so encoding them adds length without changing meaning. Every other character is either reserved, meaning it has structural significance, or must be encoded.

Why did my URL break after being encoded twice? ▼

Percent-encoding is not idempotent. The percent sign is itself a character that must be encoded as %25, so running an already-encoded string through the encoder again turns %20 into %2520. The receiving server decodes only once and reads a literal %20 in the value. Encode exactly once, at the point where a raw value is inserted into a URL, and never on a string that already contains percent-escapes.

How are non-ASCII characters such as accented letters encoded? ▼

RFC 3986 section 2.5 specifies that a character is first converted to its UTF-8 byte sequence, then each byte is percent-encoded individually. The letter e-acute becomes the two bytes 0xC3 0xA9, which encode as %C3%A9. This is also why the legacy JavaScript escape function must never be used: it emits a non-standard %uXXXX form that is not valid percent-encoding.

Javascript | Toolbox Guides & Articles

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

RegEx Tester & Group Matcher

Two Kinds of Regex Engine

How Backtracking Actually Fails

The Three Vulnerable Shapes

1. Nested Quantifiers

2. Overlapping Alternation Under a Quantifier

3. Greedy Dot-Star Next to a Similar Pattern

The Real-World Case

The Rewrites That Fix It

Replace nested quantifiers with a single one

Make alternation branches mutually exclusive

Swap greedy dots for negated character classes

Emulate atomic groups with a lookahead

Bound the input before matching

Flags Worth Knowing

The lastIndex Trap

Detection and Tooling

Step-by-Step: Diagnosing a Pattern with Toolbox

Frequently Asked Questions

URL Percent-Encoding Explained: RFC 3986, encodeURIComponent, and the %20 vs + Trap

URL Percent-Encoding Explained: RFC 3986, encodeURIComponent, and the %20 vs + Trap

URL Percent Encoder & Decoder

Why URLs Need Encoding at All

The RFC 3986 Character Classes

Unreserved — safe everywhere, never needs encoding

Reserved — structurally meaningful, must be encoded inside data

Everything else — must be encoded

The Percent-Encoding Rule

The Three JavaScript Functions

The Decision Rule

Where encodeURIComponent Diverges from RFC 3986

%20 or +: Two Specifications, One Space

Failure Modes Worth Recognising

1. Double Encoding

2. Encoded Slashes Rejected by the Server

3. URIError: URI malformed

4. Non-ASCII Hostnames Are Not Percent-Encoded

5. Encoded Data in Logs Is Still Sensitive

When to Reach for Base64 Instead

Step-by-Step: Encoding with Toolbox

Frequently Asked Questions

The `lastIndex` Trap

Where `encodeURIComponent` Diverges from RFC 3986

`%20` or `+`: Two Specifications, One Space

3. `URIError: URI malformed`