DEV Community: Sathvic Kollu

How I Audit JavaScript Regexes for Catastrophic Backtracking

Sathvic Kollu — Sun, 30 Aug 2026 05:48:11 +0000

I maintain CodeSwap, a developer-tools site with browser-based utilities and technical guides. While reviewing its regular-expression tools, I wanted a repeatable answer to a deceptively simple question:

How can I tell whether a regex is merely slow or capable of pinning a CPU with a tiny hostile input?

The answer was not another list of patterns labeled “safe” or “unsafe.” It was a small audit process: identify ambiguous repetition, construct a failing input, measure growth at several lengths, rewrite the pattern, and measure the same input again.

This article documents that process. The exact timings come from a Node.js 22 test run used for the original CodeSwap guide. Hardware and engine versions change absolute numbers, but the growth curve is the useful signal.

The failure mode: many valid paths, followed by one failure

Most JavaScript regular expressions use backtracking. The engine makes a greedy choice, and if something later fails, it revisits earlier choices.

That is normally harmless. The dangerous case appears when the same characters can be divided or matched in many different ways.

Consider this pattern:

/^(a+)+$/

The inner a+ can consume one or many a characters. The outer + can repeat that group one or many times. For an all-a string, the first path succeeds quickly. Add one final character that cannot match, however, and the engine must explore a rapidly growing number of partitions before returning false.

OWASP uses this same nested-quantifier shape when explaining Regular Expression Denial of Service, or ReDoS. Its warning signs include repetition inside a repeated group and overlapping alternatives inside repetition.

A measurement that exposes the curve

The useful test input is not a random long string. It is a string that lets the risky portion match repeatedly and then fails at the end:

const vulnerable = /^(a+)+$/;

function measure(length) {
  const input = "a".repeat(length) + "!";
  const started = performance.now();
  const matched = vulnerable.test(input);
  return {
    length,
    matched,
    milliseconds: performance.now() - started,
  };
}

for (const length of [20, 22, 24, 26, 28, 30]) {
  console.log(measure(length));
}

The recorded run produced this curve:

Repeated `a` characters	Time before rejecting
20	6 ms
22	25 ms
24	98 ms
26	402 ms
28	1,494 ms
30	6,060 ms

Every two added characters multiplied the time by roughly four. That is the evidence I look for: not one slow result, but growth that accelerates as the input grows.

Do not run an unknown pattern against unbounded input on a production request thread. Use short, controlled samples in an isolated test process or worker and stop before the duration becomes disruptive.

The two shapes I check first

1. A quantified group containing another quantifier

Examples include:

(a+)+
(\d+)*
([a-z]*)+

Nesting alone is not a proof of exploitation, but it is a strong review signal. I ask whether the inner and outer repetitions create multiple ways to consume the same text.

2. Overlapping alternatives under repetition

This pattern also creates ambiguity:

/^(a|aa)+$/

At many positions, either branch can consume the next characters. Real patterns hide the overlap inside character classes, such as \w|\d, where every digit can match both alternatives.

The question is always the same: can more than one path consume the same input, and can a later failure force the engine to revisit those paths?

Rewrite first, then compare the same hostile input

For the minimal example, the outer group adds no useful behavior:

const vulnerable = /^(a+)+$/;
const repaired = /^a+$/;

Both accept one or more a characters and reject everything else. The repaired version removes the ambiguity.

In the same recorded test:

Pattern	30-character hostile input	100,000-character hostile input
`^(a+)+$`	6,060 ms	stopped rather than attempted
`^a+$`	0.02 ms	0.09 ms

I do not treat those exact numbers as a universal benchmark. I treat the change in growth behavior as the acceptance criterion: the repaired pattern remains approximately linear on the same family of inputs.

My practical review checklist

Before a JavaScript regex processes user-controlled input, I now check:

Nested repetition: Does a +, *, or open-ended range wrap a group that contains another quantifier?
Overlapping alternatives: Can two branches under repetition match the same character or substring?
A forced failure: Is there an anchor or required literal after the ambiguous part that can trigger exhaustive backtracking?
Input bounds: Is there a maximum accepted length before the regex runs?
Measured growth: Does duration remain stable or roughly linear as a hostile input is lengthened?
Runtime isolation: If patterns or inputs are untrusted, can evaluation happen in a worker, subprocess, or engine with an enforceable timeout?

Length limits matter even after a rewrite. OWASP's input-validation guidance recommends explicit minimum and maximum lengths, and those bounds reduce the damage from mistakes that survive review.

Static checks are useful, but measurement closes the loop

I built a browser-based ReDoS checker around this workflow. It looks for ambiguous structures and can run a bounded timing probe locally in the browser. It does not upload the pattern or test input to a server.

The tool is a review aid, not a security certification. Static detection can produce false positives, while one timing sample can miss an engine-specific worst case. I use both signals, inspect the pattern manually, and compare the repaired version against the same adversarial input.

The longer catastrophic backtracking and ReDoS guide contains the full measurement table and more examples. This DEV version declares that original URL as canonical.

What changed in my maintenance process

The main lesson was to treat regex complexity like ordinary algorithmic complexity. A pattern can be functionally correct on every normal test and still be unsafe under a carefully chosen non-match.

So “the regex returns the right answer” is no longer enough for patterns on untrusted input. I want three pieces of evidence:

a structural review for ambiguity;
a bounded test showing how runtime changes with input length; and
a repaired pattern measured against the same hostile case.

That is a small amount of work compared with diagnosing a production thread that appears frozen while doing exactly what its regex engine was asked to do.

Disclosure: I maintain CodeSwap and the links above point to that project. This article was prepared with AI assistance from the site's documented implementation and test records. Its technical claims and measurements were checked against the live guide, live tool and dated maintenance evidence before publication.

References: OWASP ReDoS explanation, OWASP input-validation guidance, and MDN's JavaScript regular-expression reference.

Simple probe title

Sathvic Kollu — Fri, 17 Jul 2026 03:54:11 +0000

Just a body.

UUID-Tools API - Live Now

Sathvic Kollu — Fri, 17 Jul 2026 03:53:25 +0000

UUID Tools

Free UUID API.

Live: https://uuid-tools.techtenstein.com

probe-published-9928

Sathvic Kollu — Fri, 17 Jul 2026 03:47:08 +0000

hi

body

Introducing Password Strength API — score, crack-time, and generation

Sathvic Kollu — Thu, 16 Jul 2026 06:54:11 +0000

Just shipped Password Strength API — score passwords, estimate crack time, and generate strong passwords or passphrases. Passwords are processed at the edge and never logged.

Endpoints

GET /check?password=hunter2 → score 0-4, entropy, crack time, feedback
GET /generate?length=24&symbols=true&count=3
GET /passphrase?words=5 (diceware-style)

Try it

curl "https://password-strength.techtenstein.com/check?password=CorrectHorseBatteryStaple"

Live at https://password-strength.techtenstein.com — OpenAPI 3.1 spec at /openapi.json. MIT.

Introducing Timezone Convert API — DST-aware IANA conversion at the edge

Sathvic Kollu — Thu, 16 Jul 2026 06:53:29 +0000

Just shipped Timezone Convert API — DST-aware IANA timezone conversion. Free, no key, CORS-enabled.

Endpoints

GET /convert?time=2026-07-16T09:00&from=Asia/Kolkata&to=America/New_York
GET /now?zone=Europe/London
GET /offset?zone=Pacific/Auckland
GET /diff?a=Asia/Tokyo&b=Asia/Kolkata
GET /zones (400+ IANA zones)

Try it

curl "https://timezone-convert.techtenstein.com/now?zone=Europe/London"

Live at https://timezone-convert.techtenstein.com — OpenAPI 3.1 spec at /openapi.json. MIT.

Introducing Color Palette API — zero-key palettes and WCAG contrast at the edge

Sathvic Kollu — Thu, 16 Jul 2026 06:53:28 +0000

Just shipped Color Palette API — a free, no-key, CORS-enabled API for generating color palettes and checking WCAG contrast.

Endpoints

GET /palette?color=3498db&scheme=triadic&count=5
GET /random?scheme=analogous
GET /convert?color=%233498db
GET /contrast?fg=000&bg=fff (WCAG AA/AAA pass/fail)

Schemes supported

complementary, triadic, analogous, tetradic, split-complementary, monochromatic, shades, tints

Try it

curl "https://color-palette.techtenstein.com/palette?color=3498db&scheme=triadic"

Live at https://color-palette.techtenstein.com — OpenAPI 3.1 spec at /openapi.json. MIT.

Introducing Slug API — Unicode URL slugs in one call, on the Cloudflare edge

Sathvic Kollu — Tue, 14 Jul 2026 04:32:17 +0000

The problem

Every CMS, blog engine, and e-commerce site needs URL slugs. Every one of them re-implements slugify. And most implementations break the moment someone types München or café.

The API

One endpoint. Handles Unicode properly. Sub-100ms globally.

curl 'https://slug-api.techtenstein.workers.dev/?text=Hello%20World%202026'
# {"slug":"hello-world-2026","length":16,"processing_ms":0}

Unicode is the differentiator

Most slugify libraries strip accented characters. Ours transliterates them properly:

curl 'https://slug-api.techtenstein.workers.dev/?text=M%C3%BCnchen%20Stra%C3%9Fe%20caf%C3%A9%20se%C3%B1or'
# {"slug":"muenchen-strasse-cafe-senor"}

Notice: München → muenchen (not mnchen), Straße → strasse (not strae), café → cafe, señor → senor.

Configurable

curl 'https://slug-api.techtenstein.workers.dev/?text=The+quick+brown+fox+jumps&max=20&sep=_'
# {"slug":"the_quick_brown_fox"}

max — length cap, cleanly truncated at word boundary
sep — separator character
lower — case control

POST support for larger inputs

curl -X POST https://slug-api.techtenstein.workers.dev/ \
  -H 'Content-Type: application/json' \
  -d '{"text":"Blog post with emoji ✨ and \"quotes\"", "max":40}'

How it's built

Deploy target: Cloudflare Workers (single-file JS, module syntax)
Total code: ~120 lines
Cold start: none — Workers keep JS warm at every edge
Latency: 60-120ms globally (p50 68ms in test)
Cost: free 100K req/day, then $5/mo for 10M

Free vs. paid

Free: 1000 req/day per IP, no key needed. Great for prototypes.
Paid ($2/mo unlimited): https://techtenstein.gumroad.com — API key for production apps.

Try it

👉 slug-api.techtenstein.workers.dev

Docs live at that URL. Zero signup for the free tier.

How much VRAM do you actually need to run Llama 3 or Gemma locally?

Sathvic Kollu — Wed, 17 Jun 2026 03:56:47 +0000

Every few days someone in a local LLM thread asks the same question: "will this run on my 3060?" And the answers are almost always vibes. "Should be fine." "Probably need to quantize." Nobody shows the math, so you download 16GB, load it up, and find out the hard way.

I did exactly that a while back. Grabbed an 8B model, it loaded fine on a 12GB card, I felt clever, and then it OOM'd about 20,000 tokens into a long document. The weights fit. The KV cache didn't. That gap is the whole reason for this post.

So here is the actual math, with real numbers for Llama 3 and Gemma, including the part that surprised me, where two models that look identical on paper need very different amounts of memory.

Three things eat your VRAM

When you run a model locally, your GPU memory goes to three places:

The model weights
The KV cache
A bit of overhead (CUDA context, activations, fragmentation)

Most "how much VRAM" answers only talk about the first one. That is the mistake.

1. Weights: the number everyone quotes

This one is simple. The weights take up parameters × bytes per weight. Full precision (FP16) is 2 bytes per weight, and quantization shrinks that:

Format	Bytes/weight	Llama 3 8B weights
FP16	2.0	~15 GB
Q8_0	~1.06	~8 GB
Q5_K_M	~0.73	~5.5 GB
Q4_K_M	~0.58	~4.3 GB
Q3_K_M	~0.46	~3.5 GB

Q4_K_M is the one I reach for. It is the usual sweet spot: roughly a quarter of the FP16 size, with quality that is hard to tell apart for most tasks. So an 8B model is about 4.3GB of weights. Easy. Fits anything.

And that is the number that lies to you, because it is only part of the story.

2. KV cache: the part that scales with your prompt

When a model generates text, it caches the key and value vectors for every token it has already seen, so it does not recompute them on every new token. That cache is the KV cache, and it grows linearly with context length. Long prompt, big cache.

The formula:

KV bytes = 2 × layers × kv_dim × context_length × bytes_per_element

The leading 2 is one slot for keys and one for values. For Llama 3 8B that is 32 layers, a KV dimension of 1024 (it uses grouped-query attention, so the KV heads are smaller than the attention heads), and 2 bytes per element for an FP16 cache:

2 × 32 × 1024 × 8192 × 2  ≈  1 GB at 8K context

So far so good, 1GB is nothing. But watch what happens as the context grows, because the weights stay put and the cache does not:

8K context: ~1 GB
32K context: ~4 GB
128K context: ~16 GB

Sixteen gigabytes of KV cache for a model whose weights are four. That is why your model loads fine and then dies halfway through a long document. You did not run out of room for the model. You ran out of room for its memory of the conversation.

3. Overhead

CUDA reserves some memory, activations need scratch space, and allocators leave gaps. I budget about 10% on top of weights plus cache. It is a rule of thumb, not a law, but it keeps you from cutting it too fine.

Putting it together: Llama 3 8B

Q4_K_M weights (about 4.3GB) plus 1GB of KV at 8K plus 10% overhead lands around 5.8GB total. That fits a 12GB card with plenty of headroom, and even an 8GB card with a little room to spare. Push the context to 32K and you are at about 9GB, still fine on 12GB. Go to a 128K context and the KV cache alone is bigger than the weights, and now you need a 24GB card.

Same model, same quant. The only thing that changed was how much text you fed it.

The part that surprised me: Gemma 2 9B

Gemma 2 9B and Llama 3 8B look like the same weight class. A billion parameters apart, both run on a normal gaming GPU, so you would assume they need about the same VRAM.

Run the math. The weights are close, a touch over 4GB for Llama and about 5GB for Gemma at Q4_K_M. But the KV cache at 8K is roughly 2.6GB for Gemma, not 1GB. Gemma uses a larger head dimension and more layers, so its kv_dim is double Llama's and it has ten more layers to cache. Total comes out around 8.4GB, versus Llama's 5.8GB.

A billion more parameters, but about 2.5GB more VRAM, almost all of it hiding in the KV cache. You would never guess that from the parameter count, and it is exactly the kind of thing that turns "should fit" into an OOM at the worst moment.

So I stopped doing this by hand

Working this out per model, per quant, per context length got old, so I built a calculator that does it: LLM VRAM Calculator. Pick a model (or punch in your own params, layers, and KV dim), choose a quant and a context length, and it breaks out weights, KV cache, and overhead, then tells you which GPUs it fits on. It runs in the browser, and nothing gets uploaded.

A few things worth knowing once you can see the breakdown:

If you OOM at long context, it is almost always the KV cache, not the weights. Drop the context window, or set the KV cache to FP8, which halves it.
Concurrent requests multiply the cache. Serving four users at 8K is roughly four times the KV memory of one.
Apple Silicon cheats this a little, since unified memory is one shared pool, so the usual VRAM ceilings do not apply the same way.

The rule of thumb I actually use: take the weight size from your quant, add about 1GB of KV per 8K of context for a 7 to 8B model (more for Gemma-style architectures), then 10% on top. Or skip the arithmetic and check the calculator before you download 16 gigabytes.

If you run something with a wildly different memory profile than the parameter count suggests, I would genuinely like to hear it. Those are the ones worth knowing about before you hit buy on a GPU.