[Bug Report] bodySizeLimit Rejects Files at Exact Size Due to HTTP Protocol Overhead

[jucieltonsantos-orbia]

Goals

1.- Allow uploads of files with size exactly equal to serverActions.bodySizeLimit without triggering a 413 Payload Too Large error.
2. Reduce confusion for developers who set the limit expecting it to allow files up to exactly X MB.
3. Clarify and/or implement a safe buffer (protocol overhead) in the request body size calculation.

Non-Goals

Background

Currently, when setting bodySizeLimit: '5mb', uploads of files exactly at that size fail with error 413 because Next.js compares the raw stream size with the limit without accounting for HTTP protocol overhead from multipart/form-data (boundary delimiters, field metadata, headers, etc.). This overhead typically adds 0.5–3% to the actual payload sent.

The current behavior forces developers to configure limits with manual "padding" — something that goes against user expectations and is not clearly documented. This is especially confusing for those migrating from other frameworks (Express, Fastify, etc.) where body parsers naturally account for this margin.

Current workarounds:

1. Manually set the limit higher (e.g., use 6mb to allow 5MB files)
2. Implement custom parsing/validation outside Next.js
3. Accept 413 errors and guide end-users to reduce file size manually

There's no official way to guarantee uploads up to the exact limit without trial-and-error.

Proposal

Option 1: Add Automatic Overhead Buffer (Recommended)
Add 5–10% overhead tolerance when comparing totalSize with bodySizeLimit:

// packages/next/src/server/image-optimizer.ts line 953
const maxSizeWithOverhead = Math.ceil(maximumResponseBody * 1.05) // 5% buffer
if (totalSize > maxSizeWithOverhead) {
  throw new ImageError(413, ...)
}

Option 2: Change Comparison Operator
Use >= instead of > to allow uploads exactly at the limit size.

Option 3: Improve Documentation
Add explicit guidance that bodySizeLimit should include extra margin, with a formula/table showing recommended overhead percentages.

[icyJoseph]

I've added #94137 - The framework can only reliably enforce the total request size; it cannot know where the file bytes end and the multipart framing begins without parsing the body, which defeats the purpose of the limit check.

A percentage based approach is not the right direction either, as the overhead is not proportional to the request body size, but the number of items, their names, boundary length, etc...

That's why I think documentation is the way to go here.