414 URI Too Long

The request target is longer than the server is willing to interpret, often from excessive or misused query parameters.

Defined in RFC 9110 §15.5.15

What 414 means

414, named URI Too Long in RFC 9110, means the request target is longer than the server is willing to interpret. Servers enforce this limit both as a practical resource guard, since a very long URI can indicate an infinite redirect loop, a broken URL generator, or a client mistake, and, historically, as a defense against buffer-overflow-style attacks that tried to exploit fixed-size URL buffers in older server software.

The classic client-side trigger is turning what should be a POST with a body into a GET with a large query string: state, filters, or a search payload serialized directly into the URL instead of the request body. Redirect loops that append a parameter at each hop, such as a return_to or next URL nested inside itself repeatedly, are a slower-burning version of the same problem, growing the URL until some layer finally rejects it.

Limits differ by layer: browsers commonly cap practical URL length somewhere between about 2,000 and 8,000 characters depending on the browser, while servers and proxies set their own independent limits, such as nginx's large_client_header_buffers, so a URL that a browser will happily send can still be rejected by the server behind it, and vice versa for API clients that don't share the browser's lower practical ceiling.

Common causes

A query string carries an excessive number of parameters or a very large serialized value.
The client encodes large state, such as a filter set or search payload, directly in the URL instead of a POST body.
A redirect loop appends parameters at each hop, growing the URL unbounded.
The server or proxy's URL length limit is configured unusually low for the application's needs.
Client-side code generates URLs without any length bound, for example building deep-linkable state entirely into query parameters.

How to fix a 414

If you are the client (browser user or API caller)

Move large data into the request body via POST instead of encoding it into the query string.
Shorten or paginate query parameters rather than sending the full state in one URL.
Check for a redirect loop that keeps appending to the same URL parameter.

If you run the server

Raise the URL length limit, such as nginx's large_client_header_buffers, only as far as legitimately needed.
Redesign endpoints that require large parameter sets to accept POST with a body instead of a long query string.
Add safeguards against redirect loops or link generators that can grow a URL without bound.

Example

GET /search?q=widget&filter=color:red&filter=size:large&...(4000 more characters) HTTP/1.1
Host: shop.example.com

HTTP/1.1 414 URI Too Long
Content-Type: application/json

{"error": "uri_too_long", "message": "Request URI exceeds 8192 bytes"}

Serializing a large filter set directly into the query string pushes the URL past the server's length limit.

Try it live

Our free status responder returns a real HTTP 414 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/414