Web Development – Practical URL Limits

Earlier in the year I was involved in a project where the question of “What is the maximum length of a URL?” — Usually this kind of question means you’re doing something fundamentally wrong — but that aside it’s good to keep an open mind and know that you have multiple options, this question came up while checking the feasibility of one such option (which we ended up not using, but the following is information I found interesting none the less.)

There is one important thing to keep in my before we go on: Per the RFC for HTTP (RFC 2616, “Hypertext Transfer Protocol — HTTP/1.1”) there is NO specified maximum limit for URLs;  therefore, in practice, the maximum limit is left up to the individual implementations of both HTTP client (i.e. your web browser…) and the HTTP Server (IIS, Apache/httpd, etc… – if a URL is too long for a server it should return a 414 “Request-URI too long” error.)

Obviously, it goes without saying, then, that to get the practical URL limit of any possible client/server combination you must take the minimum of all limits (if one is imposed by any of the products you are considering.)

In my proof of concept tests and research, I attempted to consider the lowest common denominator of popular web browsers and servers; The lowest was Internet Explorer (Version 6 and higher) which is limited to 2083 characters per URL.  So the short answer is to just keep your URLs under 2000 characters and you will safely remain, for the most part, browser and technology independent — However if you are working with a legacy application you may want to double check its specific documentation as many legacy/hobby/example-code web servers hard code the URL to be limited to fewer than 300 characters.

Client

Limit (chars)

Server

Limit (chars)

Firefox

100,000+

IIS

16,384 (configurable*)

Safari / WebKit

80,000+

Apache

4,000

Opera

190,000+

Perl HTTP::Daemon

8,000 (configurable*)

Internet Explorer

2,083

Nginx

4,000
(depends on other factors, configurable*.)

Chrome / Chromium / WebKit

Unknown** (Presumably same as other WebKit.)

Lighttpd

Up to 65,535 (depends on other factors.)

(*Keep in mind, configuring your web server to accept extremely long URLs and/or header fields can leave it vulnerable to denial of service attacks.)
(** This chart is far from complete, but if you have information you would like to contribute, please let me know in the comments and I will update this table. Thanks.)

So, if you’re reading this, and you’re looking at developing a solution that uses extremely long URLs, I highly recommend rethinking your approach, but if you must use them, then I recommend using them in conjunction with “vanity URL” redirection.  If you’re using ASP.NET, or SharePoint this can be done in a highly scalable fashion using an HttpModule (or SharePoint specific: Alternate Access Mappings) both discussed here: Stack Overflow – Best practice for SharePoint 2007 Vanity URL/Redirection?

One final closing note, some of you (assuming the number of readers I have is plural) may be asking “But if there is no limit by spec then why would anyone make an implementation that enforced some seemingly random or arbitrary limit?” — My only opinion here is that in many aging languages like C it was common practice to use a statically sized character array for a string, and developers would often just throw in a magic number that they thought was big enough.  And there are still a lot of legacy applications written and maintained (for reasons beyond reason) in those languages.

Leave a Reply

Your email address will not be published. Required fields are marked *