maxParamLength limits how long a URL parameter can be in a Fastify route. The default is 100 characters. If a parameter is longer, Fastify invokes the not found route instead. The docs note this is useful for regex based routes, because a short input bounds the work a bad pattern can do.
Definition
A parametric route has a variable segment, such as /users/:id. Standard, regex and multi parameter routes all count. Regular expression denial of service, or ReDoS, happens when a pattern takes extremely long on crafted input. The longer the input, the worse the blow up, so a length cap is a cheap defense in depth.
What the docs say
The Fastify server reference describes maxParamLength with a default of 100 characters and says that once the limit is reached, the not found route is invoked. It says this can protect regex based routes against ReDoS attacks. There is also an onMaxParamLength option for custom handling of that case.
When to lower it
| Parameter type | Realistic maximum | Suggested setting |
|---|---|---|
| Numeric id | 10 to 20 chars | Lower globally if all ids are short |
| UUID | 36 chars | 36 is enough |
| Slug | Depends on your CMS | Match your slug limit |
| Opaque token in a path | Longer | Raise per need, avoid in paths |
The option is server wide, so choose one number that covers your longest legitimate parameter. If one route needs much longer values, consider moving that value into a request body or header.
Steps
- List your route parameters and the longest real value of each.
- Set maxParamLength to the smallest value that covers them.
- Look for regex routes and any validation patterns on parameters. Simplify nested quantifiers.
- Add a test that sends a parameter one character over the limit and expects the not found response.
- Combine with schema validation on params, with a maxLength per field. See Fastify's Ajv defaults.
const fastify = require('fastify')({ maxParamLength: 40 });
fastify.get('/orders/:id', async (request) => {
return { id: request.params.id };
});
What it does not do
It does not fix a vulnerable pattern. It only limits how long the input can be before the router refuses it. The pattern itself should still be reviewed, and dependencies that contain regex flaws are a separate problem. The wider topic is explained in ReDoS explained and regex denial of service in JavaScript.
A reminder on the other side: the not found response for oversized parameters can surprise API clients that expect a 400. Document it, or add a handler through the option mentioned above.
Safeguard's dependency scanning and reachability analysis can show whether a ReDoS advisory in a library is on a code path you call. Free scan: gold.safeguard.sh/scan.
Quick check
Is 100 characters too long for ids?
Usually yes. Most ids are far shorter, so lowering the value tightens the router for free.
Does this protect regexes inside my handlers?
No. It applies to route parameters only. Review patterns elsewhere and bound their input.
Sources
Last reviewed: 19 October 2026.
