The Anatomy of a URL: Every Part Explained
You use URLs hundreds of times a day and probably haven't dissected one since — well, possibly ever. That's fine right up until you need to debug a tracking parameter, understand why a link broke in an email, explain a phishing attempt to a colleague, or figure out what a shortener can safely strip from a link and what it must preserve.
So let's take one apart. Here is a real-world-shaped URL, the kind marketing emails produce daily, and by the end of this post every piece of it will make sense:
https://shop.example.co.uk:443/products/shoes/running?color=blue&size=10&utm_source=newsletter#reviews
The protocol (scheme): https://
The first component tells the browser how to talk to the server. http is the web's native protocol; https is the same thing wrapped in TLS encryption, so nobody between your device and the server can read or tamper with the traffic. Other schemes you've met without noticing: mailto: (open an email client), tel: (dial a number), ftp: (file transfer, largely retired).
Two practical notes. First, http and https versions of a page are technically different URLs — which is why well-configured sites redirect one to the other rather than serving both. Second, browsers now treat plain http as suspect, flagging it "Not Secure," so effectively all shared links today should be https. Every link created on UrlShorter is served over HTTPS for exactly this reason.
The subdomain: shop.
Reading the host from right to left, anything to the left of the main domain is a subdomain — a named subdivision that the domain owner can point anywhere. shop.example.co.uk might run on completely different servers than www.example.co.uk. Common patterns: www (historical convention, now optional), blog, app, api, mail.
Subdomains matter for two reasons beyond organization. Cookies and some security policies can be scoped to include or exclude subdomains, and branded link domains are usually subdomains — companies serve short links from go.brand.com or link.brand.com precisely because a subdomain inherits the parent brand's recognition while staying operationally separate.
One security note worth internalizing: the registrable domain is what identifies the owner, not the subdomain. yourbank.secure-login.com is owned by whoever registered secure-login.com — the yourbank prefix is decoration anyone can add. Reading hosts right-to-left is the single most useful phishing defense a non-technical person can learn.
The domain and TLD: example.co.uk
The domain is the name someone registered; the top-level domain (TLD) is the suffix it was registered under. TLDs come in flavors: generic (.com, .org, .net, plus newer ones like .dev and .app), country-code (.uk, .de, .jp, and .cc — as in urlshorter.cc — which belongs to the Cocos Islands but is used globally), and sponsored/restricted (.gov, .edu).
Our example shows a wrinkle: .co.uk is effectively a two-part TLD, because the UK registry organizes commercial registrations under .co.uk. So the registrable name — the part that identifies the owner — is example.co.uk, and shop is a subdomain of it. Short domains are prized real estate for link services because every character of the domain appears in every link on it; a compact domain is the foundation the whole product stands on, a story as old as the industry itself (see our history of URL shorteners).
The port: :443
The number after the colon selects which "door" on the server the connection uses. You almost never see it because each protocol has a default — 443 for HTTPS, 80 for HTTP — and browsers omit the default. It shows up in development (localhost:3000) and occasionally on internal tools. If you see an unusual port in a shared link, it usually means someone shared a development URL by mistake.
The path: /products/shoes/running
Everything from the first / up to any ? identifies which resource on the server you want. Paths look like folder hierarchies, and historically they were — early web servers mapped paths directly to directories on disk. Modern applications treat the path as a routing pattern instead: nothing on the server needs to physically match /products/shoes/running; the application interprets it.
Paths are where URL design happens. Readable, hierarchical paths (/blog/anatomy-of-a-url) help users predict where a link goes and help search engines understand site structure. Paths are also where short links live: a shortener's entire product is a tiny path — /x7Kp2 or a custom slug like /spring-sale — mapped to a stored destination. Choosing that slug well is its own skill, covered in our custom short links guide.
Two technicalities worth knowing: paths are case-sensitive by specification (/About and /about may differ, depending on the server), and a trailing slash can also make a technically distinct URL — which is why careful sites pick one form and redirect the other.
The query string: ?color=blue&size=10&utm_source=newsletter
Everything after ? is the query string: key–value pairs separated by &, carrying data about the request rather than identifying the resource. The server (or scripts on the page) can read these parameters and change behavior accordingly — filtering the product list to blue shoes in size 10, in our example.
The query string is where URLs earn their bad reputation, because it accumulates several distinct kinds of cargo:
| Parameter type | Example | Who consumes it |
|---|---|---|
| Page state | color=blue&size=10 | The website itself |
| Campaign tags | utm_source=newsletter | The site's analytics |
| Ad-click IDs | gclid=EAIaIQ..., fbclid=... | Ad platforms measuring conversions |
| Affiliate/referral codes | ref=partner123 | Attribution systems paying commissions |
| Session tokens | sid=8f3a... | Legacy systems tracking a visit |
UTM parameters, specifically
The five utm_* parameters are a convention from Urchin Tracking Monitor, the ancestor of Google Analytics, now supported by virtually every analytics tool: utm_source (where the traffic came from — newsletter, tiktok), utm_medium (the channel type — email, social, cpc), utm_campaign (which push — jan_sale), plus the rarer utm_term and utm_content for keyword and variant detail.
They are enormously useful and visually awful — three UTMs easily add 80 characters. The standard resolution is to hide them inside a short link: the destination keeps its full parameter set, the human sees a clean slug, and both the shortener's click counts and the destination's analytics work. This division of labor is a big part of why shorteners exist, as we discuss in what is URL shortening.
The fragment: #reviews
The part after # is the fragment, and it is unusual in one crucial way: browsers do not send it to the server. It is an instruction to the browser itself — traditionally "scroll to the element with this ID," which is how table-of-contents links jump to sections. Modern text fragments (#:~:text=...) even let a link highlight a specific phrase on the page.
Because fragments never reach the server, they are invisible to server logs and redirects handle them specially: when following a redirect, browsers preserve the original fragment unless the new URL specifies its own. Practical consequence: if you need a short link to land on a page section, put the fragment in the destination URL you shorten, and it will work.
Why URLs get so long — and what encoding does to them
Put the pieces together and the bloat is explicable: a real URL is one string serving four masters — the routing system (path), the application (state parameters), the analytics stack (UTMs), and ad platforms (click IDs). Each addition is individually reasonable; the sum is 300 characters of line noise.
Percent-encoding makes it worse. URLs only permit a limited character set, so anything else — spaces, non-Latin characters, and reserved characters like & appearing inside a value — must be encoded as % plus hex digits. A space becomes %20; a URL passed as a parameter inside another URL (redirect chains do this constantly) has every one of its own special characters encoded, ballooning in size. If you've seen %25 in the wild, that is an encoded percent sign — the telltale sign of a URL that has been encoded twice, a genuinely common bug.
The fix for humans is not to strip the parameters — the systems consuming them are doing real work — but to wrap the whole thing in a short link, which is a one-step process we walk through in how to make a URL short. The same logic applies doubly to QR codes: every character in a URL adds density to the code, so shortening before generating with a QR code generator yields codes that scan more reliably at small sizes.
Frequently asked questions
What's the difference between a URL, a URI, and a domain?
The domain is just the name part (example.com). A URL is the full address that locates a resource, domain included. URI is the broader formal category that includes URLs; outside of standards documents, people say URL and that's fine.
Are URLs case-sensitive?
Partially. The scheme and host are case-insensitive (HTTPS://EXAMPLE.COM works), but the path, query string, and fragment are case-sensitive by specification — whether they differ in practice depends on the server. Safe habit: treat everything after the domain as case-sensitive and share links exactly as given.
Do query parameters survive a short link's redirect?
Parameters in the destination URL are preserved exactly — that's the standard way to hide UTMs behind a clean slug. Parameters appended to the short link itself are handled differently by different services; check the behavior in your provider's documentation before relying on it.
What is the maximum length of a URL?
No formal limit exists in the standard, but practical ceilings do: some browsers and servers cap URLs around 2,000 characters, and older systems lower still. Real URLs approach this more often than you'd think once redirect chains start encoding URLs inside URLs — one more argument for keeping shared links short.
Reading URLs like a native
Once you can name the parts, URLs stop being noise: you can spot the phishing domain hiding behind a friendly subdomain, trim tracking parameters before sharing something privately, debug why an anchor link doesn't scroll, and understand exactly what a shortener preserves when it wraps a long address. And when a URL is too ugly to share, you know precisely which parts are doing work and which are just along for the ride — shorten it at UrlShorter and let the slug do the talking.