HTTP 414 vs 413 — URI Too Long vs Payload Too Large Comparison

Quick Cheat Sheet

Aspect	414 URI Too Long	413 Content Too Large
What's too big?	The request line / URL	The request body
Triggered by	Long path, huge query string	Big upload, oversized JSON
Typical limit	4–8 KB in URL	1 MB – 5 GB depending on stack
Headers to look at	large_client_header_buffers (Nginx)	client_max_body_size (Nginx)

What Each Code Means

414 URI Too Long (RFC 9110 § 15.5.15) is returned when the URL — not the body — exceeds what the server is willing to parse. The most common cause is a runaway query string, often from accidentally serializing a large JSON object into a GET parameter.

413 Content Too Large (renamed from "Payload Too Large" in RFC 9110 § 15.5.14) is for oversized request bodies: file uploads, base64-encoded images, large JSON payloads.

Typical Limits in the Wild

For URL length (414 territory):

• Nginx: ~8 KB by default (large_client_header_buffers 4 8k)
• Apache: 8190 bytes by default (LimitRequestLine)
• AWS ALB: 16 KB total request line + headers
• Cloudflare: 8 KB URL maximum
• Most browsers: 2 KB practical limit (IE), ~32 KB (Chrome/Firefox)

For body size (413 territory):

• Nginx: 1 MB default (client_max_body_size)
• Express/body-parser: 100 KB default
• AWS API Gateway REST: 10 MB hard cap
• Cloudflare Free: 100 MB
• AWS S3 single PUT: 5 GB (use multipart above)

When 414 Hits Production

The classic cause of 414 in real apps is a GET request with hundreds of query parameters — for example, a search UI that builds a filter list as ?ids[0]=1&ids[1]=2... and accidentally generates 5,000 IDs. The fix is almost always to switch to POST with a JSON body.

When 413 Hits Production

• Forgetting to raise client_max_body_size in Nginx for an upload endpoint
• Sending base64-encoded image data in JSON (33% larger than binary)
• Hitting AWS API Gateway's 10 MB cap (use S3 pre-signed PUT instead)
• WordPress' notorious upload_max_filesize PHP limit

Best Practice

• For uploads, design the API to accept multipart/form-data or use a pre-signed direct-to-S3 URL, both of which bypass typical body limits.
• For long lists of IDs, prefer POST with JSON body over giant GET query strings.
• Always document body limits in your API reference.

A Pitfall

Many proxies silently truncate URLs or bodies before returning these codes, leading to mysterious 400s instead of clear 414/413. Check proxy logs.