HTTP status codes / 414
414 URI Too Long — HTTP Status Code
414 URI Too Long means the server refused the request because the URL is longer than it is willing to interpret. It usually comes from very large query strings, data that should have been sent in a POST body, or a redirect loop that adds to the URL on every hop. Shortening the URL is almost always a better fix than raising the limit.
What 414 means
RFC 9110 (Section 15.5.15) defines 414 URI Too Long as the server refusing to service the request because the target URI is longer than it is willing to interpret. The RFC calls this a rare condition and names three typical causes: a client that turned a POST into a GET with long query information, a client stuck in a redirect loop where the URI keeps growing, and an attacker probing for security holes.
On limits, RFC 9110 (Section 4.1) recommends that all senders and recipients support URIs of at least 8,000 octets. Anything beyond that depends on the software in the path.
When you see it
- nginx returns 414 when the request line does not fit in one of the buffers set by
large_client_header_buffers, which default to 8 KB each. - Apache returns 414 when the request line exceeds
LimitRequestLine, which defaults to 8,190 bytes. - CDNs and load balancers enforce their own URL limits and can reject a request before it reaches your origin.
- Application servers such as Node.js, Gunicorn or Kestrel have their own request line limits, although most sit behind a proxy that rejects first.
Common causes
- Search and filter pages that put many selections into the query string, such as long lists of IDs or tags.
- GET forms that should be POST. A form with a large text area submitted with
method="get"puts the entire text into the URL. - Redirect loops with return parameters. A login page redirects to itself with
?next=containing the current URL, which already contains?next=, and so on until the URL explodes. - Tracking parameters appended repeatedly by a misbehaving script or redirect chain.
- Encoded state in the URL, such as serialized JSON or base64 blobs in a query parameter.
- Automated scans sending deliberately huge URLs. Here the 414 is the server doing its job.
How to fix it
Treat the long URL as the bug, not the limit.
- Move data to the body. Large inputs belong in a POST body. Change
method="get"tomethod="post"on forms that carry free text, and make API clients send long ID lists as JSON. - Store state on the server. Save complex search filters and put a short ID in the URL, for example
/search?saved=7f3a. - Break redirect loops. Check that your login redirect does not run on the login page itself, and that return URLs are not nested inside each other.
If you genuinely need longer URLs, raise the limit at every layer. In nginx:
http {
large_client_header_buffers 4 32k;
}
In Apache:
LimitRequestLine 16384
LimitRequestFieldSize 16384
LimitRequestFieldSize is raised as well because a long URL tends to come back in the Referer header of the next request, and that header is checked against the field size limit.
How to check it
Print the length of the URL you are sending and the status code you get back:
URL="https://example.com/search?ids=$(seq -s, 1 3000)"
echo "${#URL} characters"
curl -sS -o /dev/null -w "%{http_code}\n" "$URL"
To spot a growing redirect loop, follow redirects verbosely and watch the Location headers lengthen on each hop:
curl -sS -o /dev/null -L --max-redirs 10 -v https://example.com/account 2>&1 | grep -i "^< location"
What it means for uptime monitoring
PingRobot's checker sends a GET to the URL you configured, with the user agent PingRobot/1.0 (+https://pingrobot.io/bot), follows redirects, and counts the final response as up only if its status is between 200 and 399. A 414 is reported as down.
If your monitored URL is short, a 414 almost certainly means the site is redirecting into a loop that grows the URL, which is a real problem for visitors too. If the monitored URL itself carries a large query string, shorten it: monitor the plain page or a health endpoint instead of a long search URL.
Related codes
- 431 Request Header Fields Too Large when headers, not the URL, are too large
- 413 Content Too Large when the body is too large
- 400 Bad Request for other malformed requests
- 302 Found and 301 Moved Permanently, which can form loops
- 404 Not Found when a shortened URL has no matching route
Start monitoring free — 10 monitors, no credit card.
Frequently asked questions
How long can a URL be?
There is no single maximum. RFC 9110 recommends that senders and recipients support URIs of at least 8,000 octets, and each server, proxy and CDN sets its own limit from there.
Why do I get 414 on a login or callback URL?
Usually a redirect loop that appends the current URL as a return parameter on every hop, so the query string doubles until it hits the limit. Fix the loop rather than raising the limit.
What is the difference between 414 and 431?
414 is about the request target, the path plus query string. 431 Request Header Fields Too Large is about the headers, such as oversized cookies.