HTTP 414 URI Too Long – Free, Online, Private
414 URI Too Long means the request target is longer than the server will parse.
What HTTP 414 means
414 says the URI, almost always the query string, is longer than the server is willing to interpret. Browsers and proxies have their own limits. A GET that filters with a huge list of ids can cross them. The server refuses before the application sees a tidy query object. The fix is a shorter URI, usually by changing GET to POST.
414 URI Too Long belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.
When you see HTTP 414
When you see HTTP 414 URI Too Long, stop on that exact status line. 414 URI Too Long means the request target is longer than the server will parse. The trace that usually produces it: A GET query listed thousands of ids. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.
Return 414 when you reject a target because of length. Do not truncate the query and pretend it was a successful filter. Use POST for a large filter body. Use 413 if the problem is the body of a POST, not the URI. 414 has no body requirement. A short explanation helps.
How to fix HTTP 414
To fix HTTP 414, change the condition that made the server choose URI Too Long. Shorten the URL. Do not retry the identical request. If a browser failed locally, you will not even have a status to read. Split the query. Only with a shorter URI. The same URI will be rejected again. If the log line is a different code, leave this page. The mix-up people make with 414 is this one: 413 is a long body. 431 is large header fields. 400 is a query that parsed and failed validation. 414 is the target's length.
- A redirect loop appended to the query until a proxy stopped it.
- A client hit a browser limit and never sent the request, so the server log does not even contain the 414.
- A server allowed the URI and then failed in the application with 500, which is a worse outcome than 414.
An access log that only stores 414 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.
Example response
HTTP 414 URI Too LongHTTP/1.1 414 URI Too Long
Content-Type: text/plain
The query string is too long.
The client should not retry the same target. Move the parameters into a POST body if the operation is a query that does not belong in a URL. Remember that POST changes caching and idempotency. A huge GET was already a strained design.
What the client should do
Shorten the URL. Do not retry the identical request. If a browser failed locally, you will not even have a status to read. Split the query.
Do not cache 414. The resource is not 'too long'. One target was.
Only with a shorter URI. The same URI will be rejected again.
Codes people confuse with HTTP 414
413 is a long body. 431 is large header fields. 400 is a query that parsed and failed validation. 414 is the target's length.
Frequently asked questions
Is 414 the query string?
Usually. The request target includes the path and the query, and the query is what grows.
What should the API do instead?
Accept a POST body for a large filter, or require the client to split the list.
Will the application see the request?
Often no. The front server rejects it first.
Should the client retry?
Not with the same URI.
What should I do first when I see HTTP 414?
Read the status as 414 URI Too Long specifically. 414 URI Too Long means the request target is longer than the server will parse. Then check the cause that matches the request you sent, starting with: A GET query listed thousands of ids.