URL parser that shows what it changed

Because 443 is the default port for https, and the URL parser removes a default port during normalisation. The same happens to :80 on http and :21 on ftp. Read url.port and you get an empty string; read url.host and the port is absent there too. When you need a number to open a socket with, fall back to the scheme default yourself — the effective port row in the table above does exactly that.

No. Everything from the # onwards is stripped before the request goes out, which is why it is safe for client-side state and unsafe for anything you want in a server log. It is also why single-page routers built on hashes never showed up in analytics without JavaScript, and why an OAuth implicit flow that returns a token in the fragment keeps that token out of the server's access log — the one genuine security property of the design.

Only in the query string, and only because form encoding says so. RFC 3986 treats + as an ordinary sub-delimiter with no special meaning anywhere, but HTML form submission defined application/x-www-form-urlencoded to write a space as +, and query strings inherited that convention. So URLSearchParams decodes q=blue+suede as blue suede, while the same + in a path segment stays a plus sign. If a value can legitimately contain a plus — a phone number, a base64 payload — encode it as %2B or watch it turn into a space.

Because DNS carries ASCII only, so an internationalised domain is converted to Punycode before the lookup. münchen.de becomes xn--mnchen-3ya.de, and that ASCII form is what appears in the DNS query, the TLS SNI extension and the Host header. The parser above shows both. It matters for more than curiosity: a certificate is issued for the ASCII name, log analysis has to match on it, and the gap between what a user reads and what resolves is exactly the space homograph attacks live in — which is why browsers display Punycode rather than Unicode when a label mixes scripts.

Because a URL without a scheme is a reference, not a URL, and the constructor refuses to guess. Pass a base as the second argument — new URL("/api/users", location.href) — and it resolves. The rules are worth knowing: a leading slash replaces the whole path, a leading ../ walks up from the base's directory, a bare query like ?page=2 keeps the path, and a protocol-relative //cdn.example.com/x inherits only the scheme. Use URL.canParse(input, base) when you want a boolean instead of a try/catch; it has been in every current browser since 2023.

Longer than the 2,048 characters everyone quotes, but the limit that bites is not the browser's. Chrome and Firefox handle well over 100,000 characters in the address bar; Internet Explorer's 2,083 is where the number came from and it stopped mattering years ago. What breaks first is infrastructure: nginx allows 8 KB for the whole request line by default, Apache 8,190 bytes, and many CDNs, WAFs and analytics pipelines truncate or reject sooner. A 414 URI Too Long is the server telling you which one you hit.

Yes, and nothing in any specification forbids it — but the receiver decides what it means. searchParams.getAll("tag") returns both values in the browser; PHP keeps only the last unless the name ends in [], Rails needs the same suffix to build an array, Express and Go both give you a list, and ASP.NET joins them with a comma. That disagreement is a genuine source of bugs when a URL crosses stacks, so the parameter table above marks repeated names rather than quietly folding them together.