What's the difference between 414, 413, and 431?

They're the three 'too big' codes for three different parts of a request. 414 URI Too Long means the URL — technically the request line — is too long. 413 Content Too Large means the request body exceeded a limit (a big upload). 431 Request Header Fields Too Large means the headers, usually cookies, are too big. Same shape, different part of the request. The fix is always to shrink that part or, only when it's legitimately large, raise that specific limit.

Why does my server return 400 or 431 for a long URL instead of 414?

Because the status code is the server's choice and not every stack maps it cleanly. nginx returns 414 when the request line overflows one of its large_client_header_buffers, but returns 400 when a single header field overflows. Go's net/http currently returns 431 for an over-long request line because it counts the request line against the same MaxHeaderBytes budget as the headers (golang/go issue 79162). The underlying cause and the fix are identical — only the number the server emits differs.

Is 414 a client problem or a server problem?

Both, which is why it's confusing. The client sent a URL longer than the server chose to accept — but the server picked that limit. The durable fix is usually to shorten the URL rather than raise the ceiling, because very long request lines are a parsing and memory-exhaustion risk. That's exactly why servers cap the request line in the first place, and why 'just set the limit huge' is the wrong first move.

Views: 103

414 Request-URI Too Large: Fix

414 Request-URI Too Large: the URL exceeded the server's request-line limit. Check query bloat, redirect loops, server config. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

The server rejects the request with 414 Request-URI Too Large (or 414 URI Too Long). It typically hits a specific URL with a long query string, or a redirect that has spiralled, while shorter URLs on the same site work fine.

Symptoms

A page returns 414 Request-URI Too Large / 414 URI Too Long while the rest of the site loads.
The failing URL has a very long query string — encoded state, tokens, or many repeated parameters.
It appears after a redirect, especially a login or “return to” flow that keeps growing the URL.
The same request works when you trim the query string down.
A CDN or reverse proxy returns it even though the origin might have accepted the request.

What This Error Actually Means

414 is defined in RFC 9110 §15.5.15, which renamed it from the older “Request-URI Too Long” to simply “URI Too Long.” It means the request line — the GET /very/long/path?...= HTTP/1.1 at the very top of the request — was longer than the server is willing to parse. There is no maximum defined by the spec; every server picks its own limit.

The detail that trips people up is where the URI lives. It’s in the request line, not in a header and not in the body — which is what separates 414 from its two neighbours. 413 is the body being too large; 431 is the headers being too large; 414 is the URL being too long. Same failure shape, three different parts of the request.

Server limits are lower than people expect. In nginx, the request line has to fit in a single one of the large_client_header_buffers — default 4 8k, so 8 KB — and overflowing it returns 414 (while an oversized single header returns 400 instead). Apache defaults LimitRequestLine to 8190 bytes. These caps exist on purpose: an unbounded request line is a parsing and memory-exhaustion risk, which is why raising the limit should be a last resort, not the first fix.

Top 3 Causes

Query-string bloat - A GET request is carrying data that belongs in a POST body: serialized form state, a base64 blob, a full JWT or token, or dozens of filter and tracking parameters. The URL quietly grows past the limit as more state gets shoved into it.
A redirect loop that appends parameters - An auth or “return to” flow nests the return URL on every hop — ?returnUrl=...%3FreturnUrl%3D... — until the URL blows past the limit. This is the classic “sudden 414 on login” pattern, and it’s a bug in the redirect logic, not a size you should accommodate.
A limit set below what the app needs - The application legitimately builds long URLs (some SSO and reporting tools do), but a server, framework, or an edge proxy in front enforces a smaller request-line limit than the origin.

Diagnose with DechoNet

HTTP Check to see the exact status the server returns for the URL and to follow the redirect chain via the Location headers — the fastest way to catch a flow that appends a parameter on every hop and eventually trips 414.
DNS Lookup to confirm you’re hitting the intended host, so you’re not chasing a 414 coming from a stale endpoint or the wrong environment.

Resolution Checklist

Reproduce with the exact failing URL, then measure its length. If it’s tens of KB, that’s the smoking gun.
Look at what’s in the query string. Encoded state, a token, or the same parameter repeated many times means data that should move into a POST body or a server-side reference.
Follow the redirect chain. If each hop appends a returnUrl / next / redirect parameter onto the previous one, you have a loop — fix the redirect logic so it stops nesting.
Only if the URL is legitimately long by design, raise the limit deliberately: nginx large_client_header_buffers, Apache LimitRequestLine, and any CDN or reverse proxy in front. Match the app’s real need, not infinity.
Re-run HTTP Check to confirm the request now succeeds end to end.

When to Escalate

If a CDN or reverse proxy sits in front and enforces its own (lower) request-line limit, the 414 comes from the edge even when your origin would have accepted the request. Check the edge’s limit, not just the origin’s.
If an identity provider or third-party service is the one building the over-long return URL, the fix is on their side — the URL needs to carry a short reference instead of the whole state, and that’s a change you may not control.