Skip to content

HTTP status code · Client errors (4xx)

414 URI Too Long

414 URI Too Long means the requested URL is longer than the server is willing to parse. It usually comes from a GET request carrying too much data in the query string, or from a redirect loop that keeps appending to the URL.

Facts about this status code
Class4xx, Client errors
Also known asRequest-URI Too Long, Request-URI Too Large
Defined inRFC 9110 §15.5.15
Cacheable by defaultYes, heuristically cacheable
Safe to retryNo; shorten the URL or move the data into a POST body
Relevant headers
  • Cache-Control: 414 is heuristically cacheable, so set it if the limit may change

What 414 means

RFC 9110, section 15.5.15, calls this a rare condition and names three likely sources: a client that turned a POST into a GET with a long query, a redirect loop where the target keeps growing, and an attack probing for buffer overflows. The response is heuristically cacheable.

Limits are set by the server, not the protocol. nginx rejects a request line longer than one large_client_header_buffers buffer, 8 KB by default. Apache uses LimitRequestLine, default 8190 bytes. IIS request filtering defaults to maxUrl 4096 and maxQueryString 2048, but reports a violation as 404.14 or 404.15 instead of 414. Node.js counts the URL against its 16 KB header limit and answers 431.

Common causes

If you are visiting the site

  • A link with a huge tracking or state parameter, often copied from an email or a search results page with many filters.
  • A login flow that keeps nesting returnUrl or redirect_uri inside itself on every bounce.

If you run the server

  • A frontend serializes a large filter set, a list of IDs or a whole JSON object into the query string of a GET.
  • A redirect rule appends to the path or query on every hop, so the URL grows until it hits the limit.
  • A form uses method="get" for fields that can contain long text.

How to fix it

If you are visiting the site

  • Remove the query string (everything after ?) and navigate from the site itself.
  • Clear the site cookies and log in again if the error appeared during sign-in.

If you run the server

  • Send large inputs in a POST body. For searches that must stay bookmarkable, store the filter set server-side and put a short ID in the URL.
  • Trace redirects with curl -sIL and fix the rule that keeps appending; the Location headers will show the URL growing.
  • Raise the limit only if the long URLs are legitimate: large_client_header_buffers 4 16k in nginx, LimitRequestLine in Apache.

How to send 414

Express (Node.js)
app.use((req, res, next) => {
  if (req.originalUrl.length > 4096) {
    return res.status(414).json({ error: 'URL longer than 4096 characters' });
  }
  next();
});
Go net/http
func limitURL(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		if len(r.RequestURI) > 4096 {
			http.Error(w, "URL too long", http.StatusRequestURITooLong) // 414
			return
		}
		next.ServeHTTP(w, r)
	})
}
Nginx
# A request line longer than one buffer gets 414.
# Default: large_client_header_buffers 4 8k;
http {
  large_client_header_buffers 4 16k;
}

Commonly confused with

414 vs 413
413 rejects a large body; 414 rejects a long URL, and the fix is often to move data from the URL into the body.
414 vs 431
431 covers oversized header fields; Node.js reports an overlong URL as 431 because it counts the request line against the header limit.
414 vs 400
nginx answers 400 when a single header line is too long, and 414 only when the request line is.

Frequently asked questions

What is the maximum URL length?
HTTP sets no maximum; RFC 9110 recommends supporting at least 8000 octets. Real limits come from servers: about 8 KB in nginx and Apache by default, 4096 bytes in IIS, 16 KB total headers in Node.js.
How do I fix 414 in nginx?
Increase the buffer size, for example large_client_header_buffers 4 16k; in the http or server block. Better still, stop sending that much data in the URL.
Can a redirect loop cause 414?
Yes. RFC 9110 names it as one of the typical causes: a redirect whose target contains the original URL grows on each hop until the server refuses it.

Last reviewed by Arielton Oberek.