413 Content Too Large

RFC 9110, section 15.5.14, renamed the code Content Too Large; RFC 7231 called it Payload Too Large and RFC 2616 Request Entity Too Large, which is the text nginx still prints. The server may close the connection once it sees the body is too big, and if the limit is temporary it should add Retry-After.

The hard part is finding which layer said no, because every hop has its own ceiling. Cloudflare accepts 100 MB bodies on Free and Pro plans and 200 MB on Business. Vercel Functions stop at 4.5 MB with FUNCTION_PAYLOAD_TOO_LARGE. nginx defaults to 1 MB, Express.json() to 100 KB, Next.js Server Actions to 1 MB, and PHP to upload_max_filesize = 2M with post_max_size = 8M. IIS request filtering allows about 28.6 MB. The smallest limit on the path wins.

A quick way to tell them apart is the response body. nginx serves an HTML page titled 413 Request Entity Too Large, Express returns its error handler output, and Cloudflare and Vercel brand their pages. Browsers often cannot show it at all, because the server closes the connection while the upload is still being sent.

If you are visiting the site

• The file you are uploading (photo, video, PDF) is larger than the site accepts.
• A form with several attachments adds up to more than the limit, even though each file is small.

If you run the server

• nginx in front of the app still has the default client_max_body_size 1m.
• The app body parser limit is lower than the uploads you expect, such as express.json() with its 100 KB default receiving base64 images.
• The platform caps the body: 4.5 MB on Vercel Functions, 100 MB on Cloudflare Free, 1 MB for Next.js Server Actions.
• In PHP, post_max_size or upload_max_filesize is too low. PHP itself usually does not send 413; it just drops the POST data, so the 413 comes from the web server in front.

If you are visiting the site

• Compress or resize the file (export the image at a lower resolution, zip the documents) and try again.
• Upload attachments one at a time if the form allows it, or use a sharing link instead of attaching a large video.

If you run the server

• Raise client_max_body_size in the relevant server or location block of nginx and reload it (nginx -s reload). Set it per location so only the upload route accepts big bodies.
• Raise the parser limit where you need it: express.json({ limit: "5mb" }), serverActions.bodySizeLimit in next.config, post_max_size and upload_max_filesize in php.ini.
• For files bigger than your platform allows, upload straight from the browser to object storage with a presigned URL (S3, R2, GCS) and send only the key to your API.
• Check every layer in order (CDN, load balancer, nginx, app) and raise the smallest limit; changing only the app does nothing if nginx rejects first.

Content-Length can be absent or wrong on chunked uploads, so a header check is only a fast path; the Go MaxBytesReader and Express parser limits count the bytes actually read. For Next.js Server Actions, raise serverActions.bodySizeLimit in next.config instead.

// express.json() and express.raw() answer 413 on their own;
// err.type is 'entity.too.large'
app.use(express.json({ limit: '5mb' }));

app.use((err, req, res, next) => {
  if (err.type === 'entity.too.large') {
    return res.status(413).json({ error: 'Body exceeds 5 MB' });
  }
  next(err);
});

// app/uploads/route.ts
const MAX = 5 * 1024 * 1024;

export async function POST(request: Request) {
  const length = Number(request.headers.get('content-length') ?? 0);
  if (length > MAX) {
    return Response.json({ error: 'Body exceeds 5 MB' }, { status: 413 });
  }
  // ...
}

mux.HandleFunc("POST /uploads", func(w http.ResponseWriter, r *http.Request) {
	r.Body = http.MaxBytesReader(w, r.Body, 5<<20) // 5 MB
	data, err := io.ReadAll(r.Body)
	var tooBig *http.MaxBytesError
	if errors.As(err, &tooBig) {
		http.Error(w, "body exceeds 5 MB", http.StatusRequestEntityTooLarge) // 413
		return
	}
	_ = data // ...
})

from fastapi import FastAPI, HTTPException, Request

app = FastAPI()
MAX = 5 * 1024 * 1024

@app.post("/uploads")
async def upload(request: Request):
    if int(request.headers.get("content-length", 0)) > MAX:
        raise HTTPException(status_code=413, detail="Body exceeds 5 MB")
    ...

# Too-large bodies get 413. Default is 1m; 0 disables the check
server {
  client_max_body_size 2m;

  location /uploads/ {
    client_max_body_size 50m;
    proxy_pass http://app;
  }
}

413 vs 414

414 is about the URL being too long; 413 is about the body being too big.

413 vs 431

431 means the headers (often cookies) are too large, while the body may be tiny.

413 vs 507

507 means the server has no disk space left to store the upload; 413 means it will not accept one that size at all.

How do I fix 413 Request Entity Too Large in nginx?

Add client_max_body_size 50m; (or the size you need) to the http, server or location block that handles uploads, then run nginx -t and nginx -s reload. The default is 1m, and 0 disables the check.

Is 413 Payload Too Large the same as 413 Request Entity Too Large?

Yes. It is one code with three names over time: Request Entity Too Large (RFC 2616), Payload Too Large (RFC 7231) and Content Too Large (RFC 9110, the current one).

Why do I still get 413 after raising the limit?

Another layer has a lower limit. Check the CDN (Cloudflare Free allows 100 MB), the hosting platform (Vercel Functions allow 4.5 MB), the reverse proxy and the app parser, and confirm nginx actually reloaded the new config.

What is the default upload limit in Next.js?

Server Actions reject bodies over 1 MB unless you raise serverActions.bodySizeLimit in next.config. Route handlers have no framework limit of their own, but your host may impose one, like the 4.5 MB cap on Vercel Functions.