414 URI Too Long 4xx
The URI requested by the client is longer than the server is willing to interpret.
What does 414 mean?
A 414 URI Too Long response means the URL (including any query string) the client sent exceeds a length limit the server is willing to process. While 413 is about an oversized request body, 414 is specifically about the URL itself being too long — most commonly an issue with GET requests, since GET requests encode all their parameters in the URL rather than a body.
There's no single universal length limit across the web — different servers, browsers, and proxies impose their own limits (commonly somewhere in the range of a few thousand to around 8,000 characters, though this varies considerably), and 414 results from exceeding whichever limit applies in a given request's path.
How a 414 behaves
- It's specifically about URL length, not the request body — a request with a short URL but a huge body would hit 413, not 414, and vice versa
- It can carry a body with a brief explanation
- Multiple layers can impose their own limits — similar to 413, a CDN, load balancer, or web server might each have different URL-length limits, with the smallest one determining when 414 appears
- It's almost exclusively a GET-request issue in practice — POST/PUT/PATCH requests typically put data in the body, where length limits are governed by 413 instead
Common causes
If you're building the API or website:
- A search/filter feature is designed in a way that accumulates many parameters into the query string (e.g., a multi-select filter where each selected option adds to the URL), and with enough selections, the URL becomes too long
- A "share this search/filter state via URL" feature generates URLs that grow unbounded with user customization
- A GET-based API endpoint is being used for what's conceptually a "bulk" operation, encoding many IDs or parameters directly in the query string
If you're calling an API:
- You're constructing a GET request with a very long query string — often from passing many IDs, filters, or search terms as URL parameters
- A redirect chain or URL-shortening/expansion process has resulted in an unexpectedly long final URL
If you're a website visitor:
- You're using a search/filter feature with many active filters, and the resulting URL has grown beyond what the site's server accepts
- You followed an extremely long URL (sometimes generated by URL-shortener expansion, tracking parameters, or poorly-designed "share" links)
How to fix it
As an API/website builder:
- For operations that might involve many parameters (bulk lookups, complex filters), consider using POST with a request body instead of GET with a long query string — this sidesteps URL-length limits entirely (subject to 413's body-size limits instead, which are typically much more generous)
- If a GET-based design is preferred (e.g., for shareable/bookmarkable URLs), consider whether parameters can be encoded more compactly, or whether there's a reasonable practical limit on how many filters/selections a URL needs to represent
- Be aware of URL-length limits across your entire stack (CDN, load balancer, web server) when designing URL-heavy features
As an API consumer:
- For bulk operations involving many IDs or parameters, check if the API offers a POST-based alternative to a GET endpoint with query parameters
- If constructing URLs programmatically, consider whether the number of parameters could grow unbounded, and whether that's likely to exceed practical URL-length limits
As a website visitor:
- Reduce the number of active filters/selections if using a search feature that's producing an extremely long URL
- If following a problematic long URL from elsewhere, try navigating to the site directly and reconstructing your search/filter manually with fewer parameters
413 vs 414
| 413 Payload Too Large | 414 URI Too Long | |
|---|---|---|
| What's too large | The request body | The request URL (including query string) |
| Typical cause | Large file uploads, bulk data submissions | Extremely long query strings, often from poorly-designed GET-based search/filter parameters |
| Common fix | Chunked uploads, smaller payloads | Switch to POST with a body, or reduce query parameter count |
Real-world examples
Search and filter interfaces that encode every selected filter option as a separate query parameter can accumulate very long URLs with enough selections — particularly in e-commerce or data-table interfaces with many filterable attributes, where power users selecting numerous filters can occasionally hit URL-length limits. Some browsers and servers have historically had URL-length limits that differ from each other, meaning a URL that works in one browser/server combination might trigger 414 in another — a source of occasional cross-browser inconsistency for URL-heavy applications.
SEO implications
Extremely long URLs are generally discouraged for SEO independent of 414 — they're harder to share, less readable, and search engines may truncate how much of a URL is meaningfully indexed/displayed. If a site's URL structure is so long that it risks 414 from some servers/proxies, that's a strong signal the URL design itself needs simplifying, which would likely also improve SEO-friendliness.
FAQ
What's the difference between 413 and 414?
413 is about the request body being too large. 414 is about the request URL (including the query string) being too long. A request can hit one without the other — a short URL with a huge body (413), or a tiny/no body with an enormous URL (414).
Is there a standard maximum URL length?
No single universal standard — different browsers, servers, and infrastructure components have historically implemented their own limits, commonly somewhere in the range of a few thousand to around 8,000 characters, though this varies and isn't governed by a single specification value.
How can I avoid 414 for features with many filter options?
Consider using POST with a request body for operations involving many parameters, which sidesteps URL-length limits (subject to body-size limits instead, which are typically far more generous). If a GET-based, shareable URL is important, consider more compact parameter encoding or reasonable limits on how many options can be combined.
Can 414 happen even if my server has no explicit URL-length configuration?
Yes — limits can exist at other layers (CDN, load balancer, browser) independent of your application server's own configuration, similar to how 413 can originate from multiple layers in a stack.
Does 414 ever happen with normal page browsing?
Rarely, for typical websites — most page URLs are well within any reasonable limit. It's more likely with search/filter-heavy applications, certain analytics/tracking URL patterns with many parameters, or unusual redirect chains that progressively lengthen a URL.
Fun fact
414 highlights an interesting asymmetry in how HTTP requests can carry data — GET requests are constrained by URL-length limits (414's domain), while POST/PUT/PATCH requests are constrained by body-size limits (413's domain) — meaning the same amount of data might be perfectly fine in one request format and trigger an error in the other, which is part of why "should this be a GET or a POST?" questions sometimes come down to practical limits as much as semantic correctness.