URL Parser & Encoder.

What the parser actually does

Everything above runs through the same WHATWG URL parser your address bar uses — new URL(input) — so what you see is what a browser will really send, not a regex approximation. That matters, because the parser normalizes as it goes: the scheme and host get lowercased, bücher.de becomes xn--bcher-kva.de, :443 disappears from an https URL because it is the default port, /a/b/../c collapses to /a/c, and tabs and newlines are stripped outright. If the parsed href does not match the string you pasted, that is the gap between the text you have and the request that goes on the wire.

Two things it does not do. It does not check that the host resolves or that the path exists. And it is not a validator — javascript:alert(1) and data:text/html,… parse perfectly. Before you render a user-supplied URL into an href, allowlist url.protocol against https: and whatever else you actually intend to support.

encodeURI vs encodeURIComponent

encodeURI encodes a whole URL, so it deliberately leaves the delimiters intact. encodeURIComponent encodes one piece that sits inside a URL, so it escapes those same delimiters. Here is the entire difference, character by character:

The classic bug is reaching for encodeURI on a value. "/checkout?next=" + encodeURI("/a?b=1&c=2") produces /checkout?next=/a?b=1&c=2, so the server reads next=/a?b=1 and a bonus parameter c=2. A # in the value is worse: the fragment is never sent, so everything after it silently vanishes before the request leaves the browser. Rule of thumb — value in, encodeURIComponent; whole URL, encodeURI; and if you can, skip both and let URL plus URLSearchParams do the escaping.

Why + is a space in a query but not in a path

+ meaning space comes from application/x-www-form-urlencoded, the HTML form serialization, and it applies to the query string only. In a path a + is a literal plus: /a+b is a file called a+b, not a b. Same byte, two meanings, decided by which side of the ? it lands on.

The trap is decodeURIComponent, which knows nothing about form encoding: decodeURIComponent("a+b") returns "a+b". Hand-roll query parsing with split("&") and decodeURIComponent and every space arrives as a plus. Use URLSearchParams, which applies form rules in both directions. And a literal plus in a value has to travel as %2B — which is exactly what the parameter table above emits.

Repeated keys are legal, and every stack disagrees

?tag=rag&tag=agents is a perfectly valid URL, and no spec says what it means. URLSearchParams.get("tag") returns the first value; getAll("tag") returns both. PHP keeps the last one, so $_GET['tag'] is agents unless you write tag[]=. Go's r.URL.Query().Get("tag") returns the first. Express hands you an array. ASP.NET keeps both and joins them with a comma if you stringify it.

One URL, three different meanings, depending on who receives it. If repeated keys are load-bearing in your API, document the semantics and validate the count server-side. If they are not, put a delimiter inside a single value and stop thinking about it.

How long can a URL be, in practice

HTTP sets no limit. The limits live in the software along the path, and they are lower than people expect. Apache's LimitRequestLine defaults to 8190 bytes. nginx returns 414 Request-URI Too Large when the request line does not fit one of its large_client_header_buffers (8 KB each by default). Node caps total headers at 16 KB. The famous 2,000-character rule is really Internet Explorer's old 2,083-character cap, and it survives because that is roughly where links start breaking in chat clients, email templates and CDN configs.

Practical version: stay under ~2,000 characters for anything a human will share, under 8,000 for anything a server will parse, and move the payload into a POST body past that. Remember too that every byte of a query string lands in access logs, browser history and the Referer header of outbound links — which is why session tokens and signed URLs do not belong there.