HTTP 413 Content Too Large – Free, Online, Private

What HTTP 413 means

413 says the request body exceeds a limit. The older name was Payload Too Large. The request was refused and should not be retried unchanged. If the server is willing to accept a smaller body, it can say so. A connection close is common, because the rest of a huge upload is not wanted. This is not a validation error inside a small JSON document.

413 Content Too Large belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 413

When you see HTTP 413 Content Too Large, stop on that exact status line. 413 Content Too Large means the request body is bigger than the server will accept. The trace that usually produces it: An upload exceeded a gateway's body limit. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 413 when the body crosses a size limit you enforce. Use 400 when the document is small but invalid. Use 411 when the length is missing. Tell the client the limit if you can do it without making the error a tuning guide for attackers. A limit you never document produces retries.

How to fix HTTP 413

To fix HTTP 413, change the condition that made the server choose Content Too Large. Stop sending that body. Shrink it or split it. Do not retry the same bytes. If you already streamed most of the body, the connection is dead. Start over with less data. Only after the body is smaller. An unchanged retry is refused again and wastes bandwidth. If the log line is a different code, leave this page. The mix-up people make with 413 is this one: 411 is a missing length. 400 is a malformed body of acceptable size. 507 is the server running out of storage while handling a request that was otherwise acceptable.

• A JSON array of records was larger than the API allows.
• The client retried the same file and made the outage worse.
• A proxy returned 413 and the origin never logged the request.

An access log that only stores 413 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 413 Content Too LargeHTTP/1.1 413 Content Too Large
Connection: close
Content-Type: application/json

{"error":"body exceeds 1 MB"}

Connection: close stops the upload. The JSON names the limit. The client must send a smaller body, not the same body with a different header. If a gateway emits 413, raise the gateway limit or shrink the client. Arguing with the status will not help.

What the client should do

Stop sending that body. Shrink it or split it. Do not retry the same bytes. If you already streamed most of the body, the connection is dead. Start over with less data.

Do not cache 413. It is about one request body, not the resource.

Only after the body is smaller. An unchanged retry is refused again and wastes bandwidth.

Codes people confuse with HTTP 413

411 is a missing length. 400 is a malformed body of acceptable size. 507 is the server running out of storage while handling a request that was otherwise acceptable.