There is no maximum URL length. RFC 3986, the standard that defines URI syntax, never sets one - it describes what characters are legal and how a URL is assembled, and stops there. What you actually run into is a chain of separate, unrelated limits: your browser's address bar, the web server on the other end, the proxy sitting between them, the email client someone opens your link in, or the QR code you're about to print. Each one enforces its own ceiling, and a URL's real maximum length is whichever ceiling is lowest. Ship a 3,000-character URL and it might render fine in Chrome, get rejected by a server on default settings, and arrive in Outlook wrapped across four lines. None of that is a bug. It's the practical consequence of a spec that was deliberately silent on the question.
Four things follow: what the standard does and doesn't say, where the famous 2,083-character number came from and why it still shows up in checklists years after it stopped mattering, the limits that actually bite once a link leaves the browser, and what to do about a URL that's grown too long. For what a shortener does with all of this on the wire, see how URL shorteners work.
What RFC 3986 Actually Says About URL Length
RFC 3986 defines the generic syntax for URIs - scheme, authority, path, query, fragment - and it is silent on how long any of it can run. Not silent by omission; silent by design. The grammar in section 3 builds a URI from a small set of production rules, and nothing in those rules caps how many times a rule can repeat. A path segment can be one character or a hundred thousand, as far as the syntax is concerned. Long URLs are perfectly legal URLs.
The one limit the RFC does impose is indirect: a URL's authority component includes a hostname, and DNS caps a fully-qualified hostname well below what the URI grammar allows - Chromium's engineering documentation puts that ceiling at 253 characters total, 63 per label. Path, query string, and fragment carry no such constraint anywhere in the standard.
That's the whole story from the spec's side. The URL character limit you actually hit in practice comes from the software reading the URL, never from the URL format itself.
Where 2,083 Came From, and What Browsers Do Now
If you've seen a URL length guideline anywhere, it quoted 2,083 characters. That number is real, but it belongs to one browser, one era, and one code path. Internet Explorer's WinINET networking library defined INTERNET_MAX_URL_LENGTH as 2083 characters, and Microsoft's own engineering write-up on the limit notes that the address bar itself was capped one character lower, at 2047. That ceiling governed a huge share of web traffic for over a decade, so it became the number everyone designed to, and the habit outlived the browser it describes.
Modern browsers don't work that way. Chrome's documentation states an internal limit of 2 megabytes, imposed to avoid inter-process communication problems rather than to protect a UI field, with a much smaller constant, around 32 kilobytes on desktop, capping what the omnibox will actually display. Firefox and Safari are similarly generous - neither chokes on a URL anywhere near the length you're likely to construct by hand. I have never once debugged a real production issue caused by a modern browser refusing a long URL. Every long-URL bug I've traced started downstream of the browser.
The Real-World Limits That Actually Bite
Line up where a URL actually travels and a pattern shows up fast: the tightest limit is rarely the one in the browser.
- The server request line reads the URL as part of the first line of an HTTP request, and that line has its own buffer. Blow past it and the server never parses your route - it refuses the connection before your application code runs at all.
- Email clients handle overflow differently. Outlook wraps a long plain-text URL across several lines rather than truncating it, which is ugly but still clickable; some webmail clients and forwarding gateways are less forgiving and cut the link outright.
- A link inside a text message competes with the message body for the same character budget, and SMS marketing links live inside a 160-character segment - a long URL alone can push a one-segment text into two, which carriers bill and filter differently.
- A QR code doesn't truncate a long URL; it just gets denser. How big a QR code needs to be depends directly on how much you ask it to encode, and a URL loaded with tracking parameters can push a code up a version or two, shrinking the distance it will still scan from.
- Spreadsheet hyperlink functions enforce their own hard character limit on the link argument, well short of a typical tagged URL, and a link that exceeds it fails silently - the cell displays fine, the link itself doesn't work.
- Ad platforms cap the destination-URL field at a fixed length of their own choosing, a platform rule rather than a technical one, and a campaign manager finds out only when the save button rejects what a browser would open without complaint.
None of these limits talk to each other. A URL can clear your server's request line and still die in a spreadsheet three departments later.
Server and Proxy Request-Line Limits
The server case deserves its own look, because it's the one that produces a real error code instead of a cosmetic glitch. 414 Request-URI Too Long is the response a server sends when it declines to process a request because the URI is longer than it's willing to interpret - a URL size limit enforced one hop at a time, by whichever software is reading the request line that second.
Every server and proxy in the chain enforces its own version of this. Apache's LimitRequestLine directive defaults to 8,190 bytes for the entire request line, which includes the method and protocol version, not just the URL itself. nginx reads request headers into a fixed buffer controlled by large_client_header_buffers, 8 kilobytes by default, and a request line that doesn't fit gets a 414 before your route ever matches. Load balancers and CDNs in front of either one often apply a third, separate limit, so a URL can clear your origin server's setting and still get rejected one hop earlier.
If you don't control every hop, and past a certain company size nobody does, the safe move is to design for the tightest common default rather than the most generous one you found in a config file.
Building the redirect layer yourself instead of hand-rolling request parsing is the boring fix here. Elido's API accepts a destination of any reasonable length and hands back a short link that never changes size, so a server's request-line ceiling becomes something you configure once at the edge instead of something every integration has to handle on its own.
How to Measure the Real Length of a URL Before You Ship It
Character count is the whole measurement, and it's worth checking before a URL goes into a campaign rather than after a bounce report comes in.
printf '%s' "https://example.com/path?utm_source=newsletter&utm_campaign=spring-sale-2026" | wc -c
That gives you the byte length of the URL exactly as written. Two things complicate it. First, percent-encoded characters cost more than they look like: an accented letter or an emoji inside a query value can expand to six characters or more once encoded, so measure the URL after encoding, not before. Second, UTM parameters are usually the fastest-growing part of a URL - a handful of campaign, source, medium, and content tags can add several hundred characters to what started as a short path, and they're the first place to look when a URL has quietly grown too long.
If a link that used to work suddenly doesn't, run the same trace you'd use for any dead link: short link not working walks through checking the destination directly, which is exactly how you'd catch a URL that grew past a server's limit one tracking parameter at a time.
What to Do When a URL Is Too Long
Two fixes actually work, and they're the same two regardless of which limit you tripped.
The first is to shorten the URL. A short link is a fixed-length pointer - the slug stays the same length no matter how much the destination or its tracking parameters grow, because all of that lives on the server side and gets looked up on each click rather than carried inside the link itself. That solves the QR code density problem, the SMS segment problem, and the spreadsheet problem in one move, since all three care about the character count of the link, not the length of wherever it eventually points.
The second is to move state out of the query string entirely. If what's making your URL long is session data, a cart contents blob, or a long list of filters rather than genuine tracking parameters, that data usually belongs server-side behind an opaque ID, not spelled out in the address bar. A URL that reads /checkout?session=a1b2c3d4 ages better than one that reads /checkout?items=... with every SKU and quantity written out in full, and it sidesteps every limit in this article at once, because there's nothing long left to measure.
Both fixes point the same direction: treat a URL's length as a design decision, not an accident of how many parameters happened to accumulate on it.
Read the Cornerstone Series
This post sits in the engineering cluster. For what happens on the other end of a short link, how URL shorteners work covers the lookup itself, and types of URL redirects covers the status codes involved once the destination is found.
Related on the Blog
Frequently asked questions
What is the maximum length of a URL?
There isn't one defined by the web's own standard. RFC 3986 sets the syntax for a URL but never caps its length, so the real ceiling is whichever system in the chain enforces the tightest limit: a browser, a server, an email client, or a QR code. Keeping a URL under roughly 2,000 characters clears almost every one of those systems at once, which is why that number keeps showing up as a safe target even though no single spec requires it.
Why do people say a URL can only be 2,083 characters?
That number comes from Internet Explorer's WinINET networking library, which defined INTERNET_MAX_URL_LENGTH as 2083 characters, with the browser's own address bar capped one character lower at 2047. It governed a large share of web traffic for years, so it became the default safe assumption, and the habit of quoting it outlived the browser it described.
What is the maximum URL length in Chrome and other modern browsers?
Chrome's own documentation states an internal limit of 2 megabytes, set to avoid inter-process communication problems rather than to protect the address bar, and a separate constant caps what the omnibox will actually display, around 32 kilobytes on desktop platforms. Firefox and Safari are similarly permissive. In practice, no current browser is the limit you will hit first.
What happens if a URL is too long?
The failure depends entirely on which system rejected it. A server or proxy typically returns a 414 Request-URI Too Long response and never runs your application code; an email client wraps or truncates the link across lines; a QR code just gets denser and harder to scan from a distance; a spreadsheet cell can display fine while the underlying link silently stops working.
How long should a URL be for SEO?
Length by itself is not a ranking factor, but a URL loaded with unnecessary parameters is often a symptom of something search engines do care about, like duplicate content or unclear site structure. Practically, keeping URLs well under 2,000 characters avoids the compatibility problems above, and keeping the path short and descriptive is a usability decision more than an SEO one.
How can I check how long a URL is?
Count the characters after encoding, not before, since anything outside plain ASCII expands once it is percent-encoded. A one-line terminal command, printf '%s' "your-url" | wc -c, gives you the exact byte length you are about to ship, which is the same number your server, email client, or QR code generator will see.
Try Elido
Paste a URL, get a working short link
No signup. Link lives for 30 days. Sign up to keep it forever.
Free, no signup required · 2 per day