The body parsers behind express.json and express.urlencoded default to a 100kb limit. A larger body is rejected with a 413 error before your handler runs. Keep the default for most routes, and raise the limit only on the specific route that needs it.
What the limit protects
Every byte of a request body has to be read, decoded and parsed in memory. The body-parser documentation says that allowing larger payloads increases memory usage and can lead to longer response times, and it suggests staying at the default where you can. It gives values of 5 MB or more as an example of "very high".
So the limit is a cheap resource control. It does not stop an attacker from sending many small requests, but it stops one request from costing far more than you planned.
Default values at a glance
| Option | Applies to | Documented default |
|---|---|---|
| limit | json, urlencoded, raw, text | 100kb |
| parameterLimit | urlencoded | 1000 |
| depth | urlencoded with extended true | 32 |
| strict | json | true (objects and arrays only) |
| inflate | all parsers | true |
These come from the body-parser README. Check the README for the version you have installed, because defaults can change between major versions.
Steps to set a sensible limit
- Find out what your largest legitimate JSON body is. Most APIs never exceed a few kilobytes.
- Set an explicit limit globally so the value is visible in code review.
- Give any upload or import route its own parser with a higher limit, mounted only on that route.
- Return a clear 413 response and log the route and size, so you can tell a real need from abuse.
const express = require('express');
const app = express();
// Global default, written down on purpose
app.use(express.json({ limit: '100kb' }));
// One route that genuinely needs more
app.post('/import', express.json({ limit: '2mb' }), importHandler);
Order matters here. If the global parser runs first and rejects a large body, the route level parser never gets a chance. Mount the global parser so it skips that path, or mount parsers per route only.
What a 413 looks like
When the body exceeds the limit, body-parser creates an error with status 413 and the type entity.too.large. The error carries the limit and the received length. Too many form parameters produce a 413 with the type parameters.too.many. If you write a custom error handler, make sure it passes these status codes through instead of turning them into a 500.
Where the limit does not help
The parser limit only applies once Express sees the request. A reverse proxy or load balancer in front of Node should also cap body size, and slow senders need timeouts. See Node.js HTTP server timeouts explained for that half of the story, and API resource limits beyond rate limiting for the wider checklist.
Safeguard's SBOM and dependency scanning can show which body parsing and middleware packages your project actually pulls in, and you can try it with a free scan at gold.safeguard.sh/scan.
Quick check
Does raising the limit to 50mb make my API less secure?
It raises the memory and time a single request can cost, which the body-parser documentation warns about. Do it only on the one route that needs it, and consider streaming uploads instead of buffering them.
Is the 100kb default the same in every Express version?
The documented default in the current body-parser README is 100kb. Confirm against the README for your installed version rather than assuming.
Sources
Last reviewed: 19 October 2026.