Fastify's bodyLimit option defaults to 1048576 bytes, which is 1 MiB. Bodies larger than that get a FST_ERR_CTP_BODY_TOO_LARGE error reply. Set a smaller server wide value that fits your API, and raise it only on the individual routes that really need more.
Definition
bodyLimit is the maximum payload, in bytes, that the server accepts. The Fastify server reference describes it as applying to the default body reader. If you add a preParsing hook, the limit applies to the size of the stream the hook returns, meaning the decoded body.
That detail matters for compressed requests. A small compressed body can decode into something much larger, and the limit is measured on the decoded stream when a preParsing hook is involved.
Compare the defaults
| Framework option | Documented default |
|---|---|
| Fastify bodyLimit | 1048576 bytes (1 MiB) |
| Express body-parser limit | 100kb |
Neither is wrong. They are just different starting points, so a team moving from Express to Fastify can end up accepting bodies ten times larger without changing any code.
Steps to choose a value
- Measure the largest legitimate body each route receives. Use your access logs or a quick middleware that records length.
- Set the server value to the highest number most routes need, rounded up a little.
- Override per route for the few that need more.
- Add a test that sends a body one byte over the limit and checks for the error reply.
const fastify = require('fastify')({ bodyLimit: 102400 }); // 100 KiB server wide
fastify.post('/import', { bodyLimit: 5242880 }, async (request, reply) => {
return { ok: true };
});
The route level bodyLimit option is the safer place to be generous, because only that route pays the cost.
Related settings worth reading together
The same server reference lists two timeout settings that sit next to the body limit. requestTimeout is the maximum time to receive the entire request from the client. Its default is 0, meaning no limit, and the docs recommend a non zero value such as 120 seconds if the server runs without a reverse proxy, as a guard against denial of service. connectionTimeout also defaults to 0.
A size limit without a time limit leaves a gap, because a client can send a body very slowly. Pair them. The Node side of this is covered in Node.js HTTP server timeouts explained.
What the limit will not do
It does not validate content. A 900 KiB body of deeply nested JSON can still be expensive. Use schema validation to restrict shape, and see Fastify's Ajv defaults for what the built in validator changes about your input.
Safeguard's dependency scanning and SBOM generation can list the Fastify plugins in your project and flag known advisories on them. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is bodyLimit measured in kilobytes?
No. It is in bytes. The default is 1048576, which is 1 MiB.
Do I need a body limit if my reverse proxy already has one?
Keep both. The proxy protects the process from the network, and the framework limit protects you if traffic ever reaches Node another way, such as internal service calls.
Sources
Last reviewed: 19 October 2026.
