414 Request-URI Too Large

The short version: Shorten the URL. A 414 means the request line (method, URL, and query string) blew past a fixed server buffer, so trimming everything after the ? and navigating from the website's home page usually gets you through. If the long URL is yours, the durable fix is to move those parameters into a POST body rather than raise the limit.

Key takeaways

• A 414 is about the request line, not the request body. The method, the URL, the query string, and the HTTP version all travel on one line, and that line outgrew the buffer the server reserved for it. An upload that is too big is a 413, a different error entirely.
• One code, four spellings. RFC 9110 calls it 414 URI Too Long; the older RFC 2616 called it 414 Request-URI Too Long, which is still the reason phrase Apache httpd sends. nginx sends 414 Request-URI Too Large. They all mean the same thing.
• The defaults are lower than people expect: nginx caps the request line at one large_client_header_buffers buffer, 8k out of the box; Apache allows 8190 bytes via LimitRequestLine; IIS request filtering allows 4096 bytes of URL and 2048 bytes of query string.
• The right fix is almost never a bigger buffer. If a URL is long enough to break a server, the parameters belong in a POST body, because every hop in front of your origin (CDN, load balancer, WAF, framework) enforces its own ceiling and you would have to raise all of them.
• Some stacks answer 400 instead of 414 for the same oversized URL: ASP.NET does it via maxUrlLength, and Windows http.sys does it before IIS ever runs. If you are chasing a long-URL failure that reports as a 400, see 400 Bad Request.

Error type

HTTP 4xx client error

Whose side

Usually the request; sometimes a limit set too low

Fix difficulty

Easy for a visitor, moderate for an owner

Common cause

The request line outgrew the server's buffer

What does 414 Request-URI Too Large mean?

A 414 means the server refused the request because the target URI is longer than it is willing to interpret. The important word is line. In HTTP/1.1 the first thing a client sends is a single request line holding the method, the full target URL with its query string, and the protocol version, for example GET /search?q=... HTTP/1.1. Servers read that line into a fixed buffer allocated in advance, and when the line does not fit, they stop there and answer 414. Nothing about the request body matters, which is why a 414 never has anything to do with an upload: an oversized body is a 413, a completely separate error.

The name has changed and the servers disagree about it. RFC 2616 called the code 414 Request-URI Too Long. RFC 9110, the current HTTP specification, renamed it 414 URI Too Long in Section 15.5.15. Apache httpd still sends the old reason phrase, nginx sends Request-URI Too Large, and MDN documents the new name. Software only ever looks at the number, so treat all four spellings as the same error.

RFC 9110 is unusually specific about how you get here, and its list matches what happens in practice. It names three situations: a client that improperly converted a POST request into a GET with long query information, a client that has descended into an infinite loop of redirection (the spec's own example is a redirected URI prefix that points to a suffix of itself), and a server under attack from a client probing for security holes. The redirect case looks a little different in modern applications, where each hop nests the previous full URL inside a return parameter rather than pointing at itself, but the result is the same runaway URL. Add the two current favorites, a session or SAML message stuffed into the query string and a filter interface that serializes every option into parameters, and that covers nearly every real case.

One quirk worth knowing before you start debugging: not every server answers 414 for an over-long URL. IIS request filtering returns a 404 with substatus 404.14, ASP.NET returns 400 Bad Request when maxUrlLength is exceeded, and Windows http.sys returns a 400 in the kernel before IIS runs at all. So a long-URL failure can turn up as a 400 or a 404 in your logs, and the 400 Bad Request guide covers that overlap from the other side.

414

HTTP status code, in the 4xx client error class

8k

nginx buffer the whole request line must fit inside

8190

Bytes Apache allows on the request line by default

4096

Bytes of URL IIS request filtering allows by default

How the 414 Request-URI Too Large error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com/search?q=aaaaaaaaaaaa...

414

Request-URI Too Large

The URL you requested is longer than this server will accept.

• 414 Request-URI Too Large The nginx reason phrase, and the wording most people end up searching for
• 414 URI Too Long The current name in RFC 9110, used by MDN and most modern HTTP clients
• 414 Request-URI Too Long The RFC 2616 name, still the reason phrase Apache httpd sends
• Request-URI Too Long Short form printed on Apache's default error page
• HTTP Error 414 Generic browser, proxy, or framework rendering of the status
• 414 error The shorthand people use in tickets and log summaries
• nginx 414 What you search for when the error page carries an nginx footer
• 404.14 URL Too Long Not a 414 at all: IIS request filtering rejects an over-long URL as a 404 substatus

414 vs 400, 413 and 431

These four all mean "something you sent was too big or unreadable", but each points at a different part of the request, and the fixes have nothing in common.

Where the URL length limit lives, layer by layer

A 414 is one of these ceilings being hit. Find the layer that answered before you change any number, because raising the wrong one does nothing.

What actually makes a query string run away

Almost every real 414 traces back to one of these patterns. The third column is the fix that survives the next CDN or framework you put in front.

What causes 414 Request-URI Too Large?

• A GET carrying data that belongs in a POST body: a saved report definition, a long filter expression, or a list of hundreds of record ids in the query string.
• A redirect loop that appends or nests a parameter on every hop, typically a returnUrl or redirect_uri wrapping the previous full URL, so the request line roughly doubles each time round until it breaks. See Too Many Redirects for the loop itself.
• A session token, auth blob, or SAML message passed in the query string. SAML over the HTTP-Redirect binding is the usual offender, because the message is base64-encoded and grows with the user's group membership.
• Percent-encoding inflation: every reserved or non-ASCII byte becomes three characters (%XX), so a filter that looks short in the UI can be three times that size on the wire.
• Tracking and campaign parameters accumulating as a link gets copied, re-tagged, and re-shared until the query string dwarfs the path.
• A broken rewrite or proxy rule that appends the same path segment or parameter on each pass, producing URLs like /app/app/app/....
• A limit set unusually low somewhere in the chain rather than a genuinely huge URL: ASP.NET's maxUrlLength default of 260 characters, IIS's maxQueryString default of 2048 bytes, or a tight WAF rule.
• Automated scanners and exploit attempts sending deliberately enormous URIs. RFC 9110 lists this as one of the reasons the status exists, and a handful of these in your logs is background noise, not an incident.

How to find the cause fast

1. Measure the URL before you theorize. printf '%s' "$URL" | wc -c gives you the byte count, which is what the server counts. Compare it against the ceilings that apply: 8 KB on default nginx, 8190 on default Apache, 4096 on default IIS request filtering.
2. Binary-search the length. Cut the query string in half, retry, and keep halving or doubling until you find the exact point where the status flips. The number you land on usually names the layer for you, since 2048, 4096, and 8190 each belong to a specific default.
3. Work out which hop answered. Check the Server header on the 414 and the look of the error page: an nginx page, an Apache page, an IIS 404.14 detailed error, and a CDN block page are all visually distinct, and each has a different setting behind it.
4. Look for a redirect loop feeding the URL. Run curl -sIL against the original request and watch whether each Location is longer than the last. Growth per hop means you have a loop, not a long URL.
5. Read the access log, but do not trust the length you see there. A server that refused the request line never finished reading it, and plenty of log formats and log pipelines truncate long URLs anyway, so a URL that looks reasonable in the log may have arrived far longer.
6. On Windows, check httperr.log for a FieldLength reason. That is http.sys rejecting the request in the kernel with a 400, which no IIS-level setting affects.

Terminal

LONG=$(printf "a%.0s" $(seq 1 20000))curl -sI "https://example.com/search?q=$LONG"HTTP/1.1 414 Request-URI Too LargeServer: nginxConnection: close# the request line outgrew the 8k buffer, so nginx refused it

How 414 Request-URI Too Large looks from the outside

A 414 is almost invisible to ordinary monitoring, because the URLs people monitor are short. The home page, the health endpoint, and the login page all fit comfortably inside any buffer, so an external check reports the website up and fast while the long, parameterized URLs that carry real work quietly fail. The server is genuinely healthy from its own point of view too: it answered in milliseconds and logged a normal 4xx. That combination is what lets a 414 sit in production for weeks after someone lowered a buffer or added a WAF, noticed only when a customer with more data than everyone else complains. If long URLs matter in your product, monitor one representative long URL alongside the short ones and assert on the status code, not just on the host answering.

To confirm the exact code a URL returns, or to re-test several at once after a fix, run them through the free bulk URL status checker.

How to fix 414 Request-URI Too Large

If you are a visitor

1. Delete everything from the ? onwards and load the page again. If the shortened URL works, the query string was the problem.
2. Go to the website's home page and navigate to what you wanted from there, instead of using the long link.
3. Re-copy the link from wherever it came from. A copy-paste that picked up a duplicated fragment or a doubled query string is a common cause.
4. Did it start right after signing in? Clear that website's cookies and try again. A login redirect that keeps nesting the return URL inside itself is a redirect loop, and clearing the cookies breaks the cycle.
5. Try a different browser or a private window to rule out an extension that rewrites or appends to URLs.
6. If you did not build the URL, there is nothing further for you to fix. Report the broken link to the website owner, and include the full URL so they can measure it.

If you run the website

1. Move the parameters into a request body. Switching the endpoint from GET to POST (or PUT) with a JSON or form body removes the ceiling entirely and is the only fix that survives the next CDN, gateway, or framework you put in front of the app.
2. Where the URL has to stay shareable, persist the payload server-side and put a short opaque key in the URL. The link stays a link, and the request line stays small.
3. If a redirect loop is inflating the URL, fix the loop first. Raising the buffer only lets the loop run one or two hops longer before failing.
4. Only then raise the limit, and raise it on every hop. In nginx set the size in large_client_header_buffers; in Apache set LimitRequestLine; in IIS set maxUrl and maxQueryString under request filtering. Note that nginx's client_header_buffer_size is only the first small buffer and does not lift the ceiling on its own.
5. On Windows, check the layers above IIS as well: ASP.NET's maxUrlLength defaults to 260 characters, and http.sys enforces MaxFieldLength in the kernel before IIS is involved.
6. Check the edge too. Cloudflare documents a 16 KB URL limit, and other CDNs and load balancers have their own, so an origin that now accepts the URL can still be shielded by something that does not.
7. Keep any URL a human might share, bookmark, or paste under about 2,000 characters. That is well inside every default limit and inside the historical Internet Explorer ceiling that a lot of middleware was written around.
8. Alert on 414 in your logs. It is rare enough that a sudden run of them is always worth a look, and it usually points at a deploy that changed a limit or a client that started sending more data.

Still not fixed? Next steps

• Test the origin directly, bypassing the CDN, with the same long URL. Cloudflare documents a 16 KB URL limit, and other edges and load balancers set their own, so the request can be refused before your origin ever gets a chance to accept it.
• On Windows, read C:\Windows\System32\LogFiles\HTTPERR\httperr.log. A FieldLength reason (a single field, the URL included, over MaxFieldLength) or a RequestLength reason (request line plus headers over MaxRequestBytes) means http.sys rejected the request in the kernel with a 400, before IIS ran, and no IIS or ASP.NET setting will change that.
• When only some users hit it, look at what their client is appending. Anything sized by the account, a SAML message or an auth token that grows with group membership being the classic case, will break for your largest accounts and nobody else.
• Building the client? Measure the URL length before the request leaves and fail loudly above a threshold you choose, say 2 KB, instead of shipping a URL that works on your data and breaks on production data.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

nginx: raise the request line ceiling

# The request line must fit inside ONE large buffer, so the size
# (the second number) is the ceiling, not the count.
http {
    client_header_buffer_size   1k;      # default: the first, small buffer
    large_client_header_buffers 4 16k;   # default: 4 8k

    # Buffers are allocated on demand, so this allows up to 64k per
    # connection that actually sends a long request line or headers.
}

# Test the config, then reload:
#   nginx -t && nginx -s reload

Apache httpd: raise LimitRequestLine

# Bytes allowed on the whole request line: method + URI + HTTP version.
# Default is 8190, so a GET leaves 13 bytes fewer for the URL itself.
LimitRequestLine 16384

# Header fields have a separate limit. Exceeding this one returns 400,
# not 414, which is why the two errors get mixed up.
LimitRequestFieldSize 16384

# Both are server config / virtual host only. Neither works in .htaccess.
# Under name-based vhosts the value comes from the first-listed vhost
# matching the IP and port, so set it there.
#
# Check and reload:
#   apachectl configtest && apachectl graceful

curl: reproduce a 414 and find the real ceiling

# Build a 20,000 character query string and send it
LONG=$(printf "a%.0s" $(seq 1 20000))
curl -sI "https://example.com/search?q=$LONG"

# Typical nginx response:
#   HTTP/1.1 414 Request-URI Too Large
#   Server: nginx
#   Connection: close

# Binary-search the limit: print just the status code per length
for n in 1000 2000 4000 8000 16000; do
  Q=$(printf "a%.0s" $(seq 1 $n))
  printf "%6s -> " "$n"
  curl -so /dev/null -w "%{http_code}\n" "https://example.com/search?q=$Q"
done
# The length where the code flips tells you which layer set the limit.

How to prevent 414 Request-URI Too Large

Keeping URLs short is a design decision, not a monitoring one: parameters that belong in a body should go in a body, and anything a person will share should stay well under a couple of thousand characters. What monitoring adds is the catch when a limit changes underneath you, since a lowered buffer or a new WAF rule breaks long URLs while the home page keeps returning 200. Pulsetic checks the URLs you choose from multiple locations as often as every 30 seconds and alerts you by email, SMS, voice call, Slack, Discord, or webhook when one starts returning 414 instead of the page, so point a check at a representative long URL as well as the short ones. It measures availability from the outside, the way a visitor experiences it, and does not read your server's buffers or config.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.