Anatomy of a URL: Scheme, Host, Path and Query

You type and click URLs all day, but a web address hides more structure than it seems. There is a part the server never sees, a part that must be encoded, and a part that can carry a username. When code mishandles any of them, you get broken redirects, lost tracking parameters or security bugs. This explainer takes a URL apart piece by piece and finishes with a checklist of edge cases worth testing.

The parts of a URL

Consider https://www.example.com:8443/blog/post?q=tunnel&page=2#comments:

• Scheme — https, the protocol to use, followed by ://.
• Host — www.example.com, made of a subdomain (www), a second-level name (example) and a top-level domain (com).
• Port — 8443. Usually omitted, because https defaults to 443 and http to 80.
• Path — /blog/post, segments separated by slashes.
• Query string — ?q=tunnel&page=2, key–value pairs joined by ampersands.
• Fragment — #comments, a location inside the page.

Less common but legal is a userinfo part before the host, as in user@host, which is a classic trick in misleading links.

What the server sees — and what it does not

The fragment is handled entirely by the browser: it is not sent in the HTTP request. That is why single-page apps once used #/ routes, and why analytics tools cannot read anchors on the server side. The host travels in the Host header, and the path and query make up the request line. Knowing this split helps you debug why a parameter “disappears” between the browser and your logs.

Encoding: the source of many bugs

Only a limited set of characters may appear raw in a URL. Everything else is percent-encoded as bytes in hexadecimal: a space becomes %20, an ampersand inside a value becomes %26, and non-Latin letters become several encoded bytes. In HTML form submissions, a space in the query is often written as + instead.

Common mistakes include encoding twice (turning %20 into %2520), forgetting to encode values that contain & or =, and building URLs by gluing strings together instead of using the URL tools your language provides.

How to generate test URLs with the tool

The generator above produces well-formed sample addresses for forms, seed files and test suites:

1. Choose the Protocol: https or plain http.
2. Switch on Include query string to append parameters such as ?q=tunnel or ?utm_source=6721 — useful for parser and tracking-parameter tests.
3. Generate up to 100 URLs per batch. Each combines a brandable domain, sometimes with a www subdomain, and one or more path segments.
4. Export the list as JSON or CSV and feed it to a table-driven test.

Because the domains are built from random words, one might happen to exist, so treat the output as data and avoid clicking or crawling it.

Edge cases worth testing

• Uppercase schemes and hosts (HTTPS://Example.COM), which should be treated as equal to lowercase.
• Trailing slashes: /blog and /blog/ may be different resources.
• Repeated parameters such as ?tag=a&tag=b.
• Empty values (?q=) and keys without values (?debug).
• Very long URLs; many systems set practical limits of a few thousand characters.
• Internationalized domain names, stored in an ASCII form that begins with xn--.

For documentation, use the reserved names example.com, example.org or the .test extension, which are set aside so they never point to a real site.

Relative and absolute URLs

Inside a web page, links do not always spell out every part. An absolute URL includes the scheme and host. A root-relative link such as /blog/post keeps the current scheme and host and replaces the path. A relative link such as ../images/logo.png is resolved against the current page’s directory, while ?page=3 changes only the query.

Relative links make sites portable between staging and production, but they behave differently depending on trailing slashes, so test them on nested pages as well as the home page.

Pro tips

• Always parse URLs with a proper library instead of splitting strings by hand.
• Decode exactly once, at the boundary where the URL enters your code.
• Strip tracking parameters before you compare or store canonical URLs.
• Use example.com in docs and screenshots so nobody follows a real link by accident.

Frequently asked questions