URL length limits by browser and server

There’s no universal maximum length for URLs in any standard — RFC 3986 doesn’t set one. In practice, however, browsers, web servers, proxies, and CDNs all impose their own limits. Hitting them produces errors that range from "URL Too Long" to silent truncation to mysterious 414 responses.

This article covers what the practical limits are in 2026, what to do when you hit them, and the lesser-known cases where shorter limits apply.

The practical limits in 2026

System	Max URL length	Configurable
Chrome / Edge	~32,768 chars (display)	No
Firefox	~65,000 chars	No
Safari	~80,000 chars	No
Internet Explorer (legacy)	2,083 chars	No
Apache	8,190 bytes	Yes (LimitRequestLine)
Nginx	4,096 bytes	Yes (large_client_header_buffers)
IIS	16,384 bytes	Yes (maxUrl)
Cloudflare	~16,384 bytes	No (free tier)
AWS API Gateway	8,192 bytes	No
SEO best practice	~2,000 chars	N/A

The weakest link in the chain sets the actual limit for your application. Browser support 30,000+ chars, but if a CDN or proxy in front of your server caps at 4,096, that’s your real limit.

What the limits include

The byte counts include the entire request line: HTTP method, full URL with all encoded characters, HTTP version, and any cookies / headers that travel with the URL. A "small" URL plus many cookies can blow the limit.

GET /search?q=hello%20world&lang=en HTTP/1.1
[Followed by headers including:]
Cookie: session_id=abc123; user_pref=...

The whole request-line + headers blob has to fit in the server’s header buffer (typically 4-16 KB). Some servers count the URL separately, some count the total — check your specific docs.

What goes wrong when you exceed the limit

414 Request-URI Too Long

The friendly case. Apache and IIS return this status code when the URL exceeds LimitRequestLine / maxUrl. Client can handle it gracefully.

400 Bad Request

Nginx and some CDNs return generic 400 errors with no specific message about URL length. Harder to debug.

Silent truncation

The worst case. Some older proxies and HTTP libraries silently truncate URLs at a buffer boundary. The server receives a request with a chopped URL and returns a 404 or 500 — but it’s not obvious that truncation happened.

Browser refuses to send

Modern browsers usually don’t enforce a URL limit, but Chrome historically had a 2 MB cap on the address bar (mostly to prevent UI breakage). Very long URLs would just not navigate.

How URL encoding inflates length

The encoded form is always at least as long as the decoded form, often much longer. Non-ASCII data has the largest inflation:

Original	Encoded length	Inflation
ASCII letters/digits	Same	0%
ASCII punctuation	3× (each char → %XX)	200%
Latin Extended (é, ñ)	6× (2 bytes → 2×%XX)	500%
CJK (你好)	9× (3 bytes → 3×%XX)	800%
Emoji (😀)	12× (4 bytes → 4×%XX)	1100%

A search query with a few emoji can be 10× longer encoded than displayed. Plan accordingly.

What to do when you hit the limit

1. Move data from URL to request body (POST)

The biggest single fix. POST requests have no practical body size limit (servers configure their own — often megabytes). If your payload is bigger than a few KB, it shouldn’t be in a URL.

// Bad — long search query in URL
GET /search?q=very+long+query...&filter=...

// Good — search query in POST body
POST /search
Content-Type: application/json
{"q": "very long query...", "filter": {...}}

GET is cacheable and bookmarkable, POST isn’t — there’s a tradeoff. But for data over ~2 KB, POST is usually the right choice.

2. Use a URL shortener

For sharing URLs in constrained channels (Twitter, SMS, print), a URL shortener replaces your long URL with a short redirect. Some platforms (Bitly, Rebrandly) preserve UTM parameters through the redirect.

3. Server-side state instead of URL state

For complex filters or search states, save the state on the server with an ID. URL just carries the ID:

// Long URL with full filter state
/search?q=...&filters=...&sort=...&categories=...

// Short URL with stored state
/search?session=abc123def

4. Compress the data before encoding

For non-trivial JSON or text payloads, gzip + Base64URL can be more compact than plain URL encoding. Decompress on the server side.

// Pseudo-code
const compressed = gzip(JSON.stringify(filters));
const url = `/search?d=${base64UrlEncode(compressed)}`;

Adds complexity but useful when you need URL state and the payload is large.

5. Increase server limits

If you control the server stack, you can raise the limits. Be aware that this also raises memory consumption per request:

Apache:

# httpd.conf
LimitRequestLine 65536
LimitRequestFieldSize 32768

Nginx:

# nginx.conf
http {
  large_client_header_buffers 4 16k;
}

IIS: Configure via web.config or applicationHost.config under system.webServer/security/requestFiltering.

SEO consideration

Google’s John Mueller has confirmed that Google handles URLs up to ~2,000 characters. Beyond that, indexing reliability degrades. For URLs that need to rank in search, keep them well under 2,000 chars — ideally under 100 for clean ranking signals.

Quick reference

Need	Max URL
Universal compatibility (incl. old IE)	~2,000 chars
SEO-friendly (Google indexable)	~2,000 chars
Modern browser only	~8,000 chars (with server config)
Anything larger	Switch to POST

The robust default: design URLs to stay under 2,000 chars. Beyond that, use POST.

---

Found this useful? Try the URL decoder, the URL encoder, or browse all tools.