414 - URI Too Long
HTTP 414 URI Too Long means the target URI is longer than the server is willing or able to interpret.
Last reviewed: February 21, 2026|Editorial standard: source-backed technical guidance
What Does URI Too Long Mean?
The request target became too long for the server path parser or policy, so routing fails before endpoint logic can run.
Common Causes
- -SPA serializes large filter state into query string with hundreds of IDs, exceeding proxy URL length limit.
- -Redirect loop appends returnUrl repeatedly on each hop, causing URI growth until gateway rejects request target.
- -Legacy client places JWT in query parameter instead of Authorization header, pushing URI beyond server threshold.
How to Fix URI Too Long
- 1Move large query payloads to request body (for example POST with filter object) instead of expanding URI.
- 2Break redirect loops and eliminate repeated query-appending logic.
- 3Align URI length limits across edge and origin, then enforce client-side query-size guards.
Step-by-Step Diagnosis for URI Too Long
- 1Capture the full request target and measure exact URI length at rejection point.
- 2Inspect redirect chain behavior for repeated path or query growth.
- 3Audit client URL builders for unbounded filters, nested state, or duplicated parameters.
- 4Retest with compact query representation and confirm endpoint behavior stays equivalent.
Request Target Growth Analysis
- -Trace URI expansion from client builders (example: dynamic filter UI serializes entire app state into query string).
- -Inspect encoded size inflation effects (example: repeated percent-encoding and long token parameters exceed parser limits).
Redirect and Routing Hygiene
- -Audit redirection loops that keep appending path/query segments (example:
/searchredirects to itself with cumulativenextparam). - -Compare maximum request-target settings between CDN, proxy, and app server (example: edge allows 16 KB, origin allows 8 KB).
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 414 URI Too Long
# {"error":"URI Too Long","code":"414"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 414) {
console.error('Handle 414 URI Too Long');
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'}
)
if response.status_code == 414:
print('Handle 414 URI Too Long')How to Verify the Fix
- -Resubmit representative long-filter requests and confirm they route without 414.
- -Run URI boundary tests at documented maximum lengths across all environments.
- -Verify redirects no longer expand request targets over successive hops.
How to Prevent Recurrence
- -Set explicit request-target length budgets and enforce them in client builders.
- -Add redirect-loop detection and query-growth safeguards in edge routing rules.
- -Prefer compact identifiers over serialized objects in query parameters.
Pro Tip
- -log request-target length histograms by route and alert when p99 approaches infrastructure limits to catch regressions early.
Decision Support
Compare Guide
HTTP 400 vs 422: Bad Request vs Unprocessable Content
Fix API payload issues faster by using 400 for malformed syntax and 422 for semantic validation failures, so clients correct format before business rules.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Playbook
Validation Failure Playbook (400 / 422 / INVALID_ARGUMENT)
Use this playbook to separate malformed-request failures from semantic validation failures, then fix request contracts without broad server-side bypasses.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.