HTTP 414 URI Too Long
Quick reference
| Code | 414 |
|---|---|
| Name | URI Too Long |
| Category | 4xx Client Error |
| Spec | RFC 9110 §15.5.15 |
| Cacheable? | Yes — by default (RFC 9110) |
What 414 means
HTTP 414 URI Too Long means the server refuses to process the request because the request-target (the URL path plus query string) exceeds the server's configured maximum URI length. The HTTP specification does not define a universal maximum URL length, so each server implementation sets its own limit.
Common server limits: nginx defaults to 8 KB for the request line (method + URI + HTTP version). Apache defaults to 8,190 bytes for the URI. AWS Application Load Balancer enforces a 8,192-byte URL limit. Cloudflare enforces a 32 KB URL limit. These limits exist to prevent buffer overflow attacks, DoS via resource exhaustion, and to prevent clients from encoding large payloads in the URL instead of the request body.
RFC 9110 notes that 414 is cacheable by default — a URL that is too long today will be too long tomorrow. However, if the server's limit is configured dynamically, add Cache-Control: no-store to prevent stale 414 responses from being served after the limit changes.
Common causes
Search or filter parameters accumulated in query string. A client-side search UI appends filters to the URL: /search?q=term&category=A&category=B&category=C&...&sort=price&page=1. After many filter selections the URL grows beyond the server limit. This is the most frequent real-world cause of 414.
POST data sent via GET by mistake. An API client or form handler uses GET for an operation that should use POST, putting large payloads in the query string instead of the request body. GET is for retrieval; POST, PUT, and PATCH are for sending data.
Redirect loop or client bug appending parameters. A client-side bug repeatedly appends parameters to the URL on redirect, growing the URL unboundedly across redirect hops until the URI limit is hit.
Base64-encoded data in the URL. Some applications encode binary data (images, files) as base64 and pass it as a URL parameter. Base64 encoding inflates the size by ~33%, and even small files quickly exceed URL limits.
JWT or session tokens in the URL. Long authentication tokens placed in query parameters instead of headers. A typical JWT is 300-500 bytes; multiple tokens in the URL push past limits.
Server-side configuration
nginx — increase large_client_header_buffers for the request line:
Apache — adjust LimitRequestLine:
Node.js (http module) — configure maxHeaderSize and use a framework limit:
Client-side fixes
The preferred fix is to move data from the URL to the request body. For search and filter operations, switch from GET to POST and send the filter state as a JSON body:
For shareable URLs that need to encode complex state, consider hashing the state and storing it server-side, returning a short token that reconstructs the full state. This keeps URLs short while preserving shareability.
For authentication tokens, use headers instead of query parameters: Authorization: Bearer <token> instead of ?token=<token>.
414 vs related codes
Frequently asked questions
What is the maximum safe URL length?
There is no universal standard. Practically: keep URLs under 2,000 characters to ensure compatibility with all major browsers, servers, and intermediaries. Chrome supports up to ~2 million characters, but servers and proxies impose much shorter limits. 2,000 characters is the widely cited safe maximum for broad compatibility.
Is 414 a client error or server error?
It is classified as a 4xx client error because the fix is typically on the client side — either shorten the URL or move data to the request body. However, the server determines the limit, so in some cases increasing the server limit is the appropriate fix (for example, when a legitimate API endpoint generates long but valid URLs).
Can GET requests have a body to avoid 414?
RFC 9110 does not prohibit a body on GET requests, but many intermediaries, proxies, and servers strip GET request bodies or treat them as malformed. The correct solution for sending large query data is to use POST. Alternatively, define a dedicated search endpoint that accepts POST with a JSON body.
Why is 414 cacheable by default?
RFC 9110 lists 414 among default-cacheable codes because a URL that exceeds the server's limit is expected to consistently exceed it. Caching the 414 prevents repeated full round-trips for the same overlong URL. Add Cache-Control: no-cache if the limit may change or vary by configuration.