413 Payload Too Large 4xx

What does 413 mean?

A 413 Payload Too Large response means the request body exceeds a size limit the server has configured — most commonly encountered with file uploads, but applicable to any request with a body (large JSON payloads, bulk API requests, etc.) that exceeds whatever limit is in place.

What makes 413 tricky in practice is that size limits are often configured at multiple layers of a typical web stack — a CDN, a load balancer, a web server (Nginx/Apache), and the application framework itself can all impose their own limits, and the smallest one determines when 413 appears. A developer increasing the application-level limit might still see 413s if a layer in front of the application has a smaller limit they didn't realize existed.

How a 413 behaves

• It can include a Retry-After header in some cases (if the limit is temporary, e.g., due to server load), though this is uncommon — usually the limit is a fixed configuration
• It can carry a body explaining the size limit, though many implementations return minimal information
• The request is rejected outright — the server doesn't process any portion of an oversized request body
• Different layers may report it differently — a CDN or load balancer rejecting an oversized request might return a generically-styled 413 page that looks different from the application's own error responses

Common causes

If you're building the API or website:

• File upload functionality doesn't account for the actual size limits configured across your stack (web server, reverse proxy, CDN, application framework all potentially having different limits)
• Default framework/server configuration limits (often a few MB) are too small for your use case (e.g., users uploading images, videos, or documents) and haven't been explicitly increased
• A bulk API endpoint accepting large JSON arrays hits a body-size limit not anticipated when the endpoint was designed

If you're calling an API:

• You're uploading a file or sending a payload larger than the API's documented size limit
• You're hitting a limit that isn't in the API's documentation but exists at an infrastructure layer (CDN, gateway) in front of the API

If you're a website visitor:

• You're trying to upload a file (image, video, document) larger than the site allows
• You're submitting a form with an unusually large amount of data (e.g., pasting a huge amount of text into a text area)

How to fix it

As an API/website builder:

• Audit size limits across every layer of your stack — web server config, reverse proxy/load balancer config, CDN settings, and application framework settings — and ensure they're aligned with your actual requirements
• Document upload/payload size limits clearly for API consumers
• For large file uploads, consider chunked/resumable upload patterns (uploading in smaller pieces) rather than relying on one very large request, which also helps with 408 (Request Timeout) on slow connections
• Return a clear, specific error message indicating the size limit and the size of what was received, if possible

As an API consumer:

• Check the API's documented size limits and ensure your payload is within them
• For file uploads, consider compressing files before upload where appropriate, or check if the API supports chunked/multipart upload for large files
• If you're confident your payload should be within documented limits but still getting 413, the issue might be at an infrastructure layer (CDN/gateway) with a stricter limit than the application itself documents

As a website visitor:

• Check the site's stated file size limits (often shown near upload buttons) and ensure your file is within them
• Try compressing images/videos/documents before uploading
• For large text submissions, consider whether the content can be split into smaller pieces or uploaded as a file attachment instead

413 vs 414

Real-world examples

Web hosting platforms and CDNs commonly impose their own request-body size limits independent of what an application server allows — a developer might configure their application framework to accept 50MB uploads, but if the CDN or hosting platform in front of it caps requests at 10MB, users will see 413 well before reaching the application's own limit, often without an obvious indication of which layer is responsible. File upload features in content management systems and media platforms are among the most common real-world sources of 413, particularly for video or high-resolution image uploads.

SEO implications

413 is relevant to form submissions and file uploads (POST requests with bodies), not regular page navigation (GET requests for content), so it has no direct SEO implications for indexable pages.

FAQ

Why does increasing my application's upload limit not fix 413?

Because size limits often exist at multiple layers — your web server, reverse proxy, load balancer, and CDN may each have their own limits independent of your application framework's setting. The smallest limit across all these layers determines when 413 appears, so you need to check and align all of them.

What's the difference between 413 and 414?

413 is about the request body being too large (common with file uploads and large payloads). 414 is about the request URL (including query string) being too long — a completely different part of the request.

Is there a "standard" size limit that triggers 413?

No — there's no universal default; it varies enormously depending on the server software, hosting platform, CDN, and application framework involved, and is typically configurable at each of those layers independently.

How can I upload large files without hitting 413?

Chunked or resumable upload protocols — breaking a large file into smaller pieces, each within size limits, and reassembling them server-side — are the standard solution for uploads that would otherwise exceed body-size limits at one or more layers of the stack.

Can 413 happen with non-file requests, like JSON API calls?

Yes — any request with a body can hit a size limit, including large JSON payloads (e.g., bulk-create endpoints accepting arrays of many items). The cause and fixes are conceptually the same as for file uploads: check limits across all layers, and consider whether the payload can reasonably be split into smaller requests.

Fun fact

413 is a good illustration of how modern web infrastructure has many "invisible" layers each capable of independently rejecting a request — a single 413 error might originate from any of half a dozen different systems (CDN, WAF, load balancer, reverse proxy, application server, application framework) in a typical production setup, making "which layer actually returned this 413?" sometimes a more involved debugging question than the error itself might suggest.