URL Anatomy: Parts of a URL

URL Anatomy

Every URL you type, click, or share is made up of distinct components, each carrying a specific piece of information the browser needs to locate and retrieve a resource. Understanding URL anatomy helps you build better web applications, write cleaner APIs, debug network issues faster, and work more effectively with links in any context.

What Is URL Anatomy

URL stands for Uniform Resource Locator. The word "locator" is the key: a URL does not just name a resource, it provides everything needed to locate and access it. Each part of a URL plays a defined role in that process, from specifying the communication protocol to identifying a specific section within a page. Knowing what each part does and when it is required turns URLs from opaque strings into readable, predictable addresses you can construct and interpret confidently.

The structure of a URL is defined by RFC 3986, an internet standard that specifies which characters are allowed in each component, how components are delimited, and how relative references are resolved. Most developers never need to read the specification directly, but understanding the rules it establishes explains why URLs behave the way they do and why certain characters must be encoded before they can safely appear in a URL.

The Complete URL Structure

Here is a fully annotated URL containing every possible component. In practice, most URLs contain only a subset of these parts, but understanding the complete structure makes it easy to identify any component you encounter.

https://username:password@www.example.com:8080/path/to/page?key1=value1&key2=value2#section

┌─────────┐  ┌──────────────────┐  ┌───────────────────┐  ┌──────────────┐  ┌──────────────────────────┐  ┌──────────┐
│ Protocol│  │   Credentials    │  │      Host         │  │    Path      │  │       Query String       │  │ Fragment │
│ https:// │  │ username:password│  │www.example.com:8080│  │/path/to/page │  │?key1=value1&key2=value2  │  │ #section │
└─────────┘  └──────────────────┘  └───────────────────┘  └──────────────┘  └──────────────────────────┘  └──────────┘

The Scheme (Protocol)

The scheme is the first component of every URL and is followed by a colon and two forward slashes. It tells the browser which protocol to use when communicating with the server. The scheme is not optional and must appear at the start of every absolute URL.

The Authority: Host, Subdomain, and Port

After the scheme, the authority section identifies the server to connect to. It consists of the host, which includes any subdomain and the domain name, and optionally a port number. Together these components tell the browser exactly which machine to connect to and on which port.

Subdomain

A subdomain is a prefix to the main domain, separated from it by a dot. It allows a single domain to host multiple distinct services at different addresses without requiring separate domain registrations. Subdomains are configured through DNS records and can point to entirely different servers from the main domain.

www.example.com       → Main website (traditional web prefix)
api.example.com       → API server
blog.example.com      → Blog, often on a separate CMS
docs.example.com      → Documentation site
mail.example.com      → Email server
staging.example.com   → Staging or test environment
cdn.example.com       → Content delivery or static assets

Domain Name and TLD

The domain name is the human-readable identifier for the server. DNS resolves it into a numeric IP address so the browser knows which machine to connect to. The domain consists of a second-level domain, which is the name you register such as example, and a top-level domain (TLD) such as .com, .org, or a country code like .uk.

blog.example.co.uk

blog          → Subdomain
example       → Second-level domain (SLD) — the registered name
co.uk         → Top-level domain (TLD) — country code + category
example.co.uk → The registered domain (what you own)

Port

The port number follows the hostname, separated by a colon. It identifies which service on the server should receive the connection. Every internet service listens on a specific port, and the scheme implies a default port that browsers use automatically. You only need to include a port in a URL when using a non-default port.

The Path

The path follows the host and port and identifies the specific resource being requested on the server. It is structured like a file system path with forward slashes separating segments. The path begins immediately after the authority section and extends until the query string, fragment, or end of the URL.

The path does not have to correspond to an actual file or directory on the server's disk. Modern web servers and frameworks use routing systems that map URL paths to handler functions, database queries, or template renders regardless of whether any corresponding files exist.

/ → Root path, the home page or API root

/about → Static page or route for an about section

/blog/how-dns-works → Dynamic route where "how-dns-works" is a slug parameter

/api/v1/users → Versioned REST API endpoint for a users collection

/api/v1/users/42 → REST API endpoint for a specific user with ID 42

/api/v1/users/42/posts → Nested resource: posts belonging to user 42

/files/report-2024.pdf → Path that may correspond to an actual file on disk

The Query String

The query string begins with a question mark and contains one or more key-value pairs separated by ampersands. It passes additional parameters to the server that modify what is returned for a given path. The server reads these parameters and uses them to filter, sort, paginate, or otherwise customise the response.

https://example.com/search?q=dns&type=tutorial&page=2&sort=date

?         → Start of the query string
q=dns     → First key-value pair (search term)
&         → Separator between pairs
type=tutorial → Second key-value pair (filter by type)
&         → Separator
page=2    → Third key-value pair (pagination)
&         → Separator
sort=date → Fourth key-value pair (sort order)

Query string keys and values that contain special characters or spaces must be percent-encoded. A space becomes %20, an ampersand within a value becomes %26, and a plus sign can also represent a space in some contexts. In JavaScript, encodeURIComponent() handles this encoding correctly for individual parameter values.

The Fragment (Hash)

The fragment identifier begins with a hash symbol and appears at the very end of a URL, after the query string if one is present. It identifies a specific location within the document rather than a separate resource. The fragment is the only URL component that is never sent to the server. The browser strips it from the request and uses it locally to scroll the page to the matching element or to drive client-side routing in single-page applications.

<!-- The HTML element that the fragment targets -->
<h2 id="query-string">The Query String</h2>

<!-- URL with fragment pointing to that element -->
https://example.com/tutorial/url-anatomy#query-string

<!-- When the browser loads this URL it:
  1. Fetches /tutorial/url-anatomy from the server (no #query-string in request)
  2. Renders the page
  3. Scrolls to the element with id="query-string" -->

<!-- Single-page application client-side routing -->
https://app.example.com/#/dashboard
https://app.example.com/#/users/42

In single-page applications built before the HTML5 History API became widely available, the hash was used as the routing mechanism. The server always served the same page, and client-side JavaScript read the fragment to determine which view to render. Modern SPAs use the History API instead, which allows clean paths without the hash, but legacy applications still commonly use hash-based routing.

Embedded Credentials in URLs

The URL specification allows a username and password to be embedded between the scheme and the host, in the format username:password@host. This is called the userinfo component. While technically valid, embedding credentials directly in URLs is strongly discouraged in modern applications for several reasons.

• URLs are logged by servers, proxies, browsers, and operating systems. Credentials in a URL end up in log files in plain text.
• URLs are visible in the browser address bar, in browser history, and in the Referer header when navigating away from the page.
• Sharing a URL with embedded credentials gives the recipient full authentication access.
• Most modern browsers display a security warning or strip the credentials when they encounter a URL with embedded authentication.

The primary legitimate use of userinfo in URLs today is in database connection strings and service configuration files where the URL is used programmatically and never displayed to users, such as postgres://user:password@localhost:5432/mydb.

URL Encoding in Each Component

Different parts of a URL have different rules about which characters are allowed without encoding. Characters with special meaning in URL syntax must be encoded when they appear as data values to prevent them from being misinterpreted as structural delimiters.

Why Clean URLs Matter

Real-world URLs frequently accumulate extra parameters added by analytics platforms, advertising networks, and affiliate systems. A URL shared from a social media post or email campaign might carry a dozen tracking parameters that serve no purpose for the reader but expose behavioural data to anyone who receives the link.

Before:
https://example.com/article/what-is-dns
  ?utm_source=twitter&utm_medium=social&utm_campaign=spring
  &fbclid=IwAR2xK9mP3nQs&gclid=Cj0KCQjw
  &ref=homepage&sessionid=abc123xyz

After:
https://example.com/article/what-is-dns

Stripping tracking parameters before sharing or saving a URL produces a cleaner, shorter, and more private link that contains only what is needed to reach the resource. Common tracking parameters that are safe to remove include utm_source, utm_medium, utm_campaign, utm_content, utm_term, fbclid, gclid, msclkid, and various session and affiliate identifiers.

Advanced URL Cleaner

Advanced URL Cleaner is a browser extension that automatically removes tracking parameters, affiliate tags, and unnecessary query strings from URLs as you browse. It works locally in your browser without sending your data to any external server, integrates directly into the browser toolbar, and is available for both Chrome and Firefox.

• Removes UTM parameters added by Google Analytics, Mailchimp, HubSpot, and other marketing platforms automatically
• Strips click identifiers including fbclid, gclid, and msclkid that expose your browsing source to anyone you forward the link to
• Cleans affiliate and referral tags appended by e-commerce and content platforms to track revenue attribution
• Processes all URLs locally with a minimal permission scope, meaning your browsing activity is never sent to a remote server
• Available for all Chromium-based browsers including Chrome, Edge, Brave, and Opera, as well as Firefox

Frequently Asked Questions

1. Which parts of a URL are sent to the server?
   The scheme, host, port, path, and query string are all included in the HTTP request the browser sends to the server. The fragment identifier, the part after the hash symbol, is never sent to the server. The browser strips it from the request and handles it locally. This is why you cannot read a fragment on the server side without JavaScript sending it separately. Credentials embedded in the URL are also sent to the server as part of the HTTP basic authentication mechanism if present.
2. What is the difference between the path and the query string?
   The path identifies the resource itself and is part of the resource's stable identity. Changing the path typically means you are requesting a completely different resource. The query string provides parameters that modify how the server responds to a request for the resource at a given path, such as filtering, sorting, or paginating its content. In REST API design, the path identifies what you are accessing such as /users/42 and the query string controls how the response is shaped such as ?fields=name,email. For public pages, paths form the primary navigation structure and query strings handle dynamic variations of the same content.
3. Why must some characters be encoded in URLs?
   URLs use certain characters as structural delimiters: ? begins the query string, & separates query parameters, # begins the fragment, and / separates path segments. If any of these characters appear as part of the actual data in a URL rather than as structure, the browser cannot tell them apart from the delimiters. Percent-encoding replaces these characters with their ASCII byte value expressed as a percentage sign followed by two hex digits. This ensures the browser can always correctly identify the boundaries between URL components regardless of what data values contain.
4. What is the difference between a URL and a URI?
   A URI (Uniform Resource Identifier) is the broader category that encompasses any string that identifies a resource. A URL is a specific type of URI that not only identifies a resource but also specifies how to locate and access it, including the protocol and server address. A URN (Uniform Resource Name) is another type of URI that names a resource persistently without specifying how to find it, such as an ISBN for a book. In everyday web development, URL is the term used almost exclusively, and URI appears mainly in technical specifications and HTTP header names such as Content-URI.
5. What are tracking parameters and is it safe to remove them?
   Tracking parameters are query string key-value pairs appended to URLs by analytics platforms, advertising networks, and affiliate systems to attribute traffic to specific campaigns, channels, or referring links. Common examples include utm_source and utm_campaign from Google Analytics, fbclid from Facebook, and gclid from Google Ads. These parameters have no effect on which page is displayed to the user. Removing them before sharing or bookmarking a URL produces a shorter, cleaner address that reaches the same content. The tracking data is only useful to the platform that added it and has no benefit to the person receiving the link. Tools like Advanced URL Cleaner handle this automatically as you browse.

Conclusion

URL anatomy is the foundation of how the web addresses its resources. Every component, from the scheme that selects the protocol to the fragment that targets a section within a page, plays a precise role in directing browsers to the right server, the right resource, and the right location within that resource. Understanding these components in depth helps you design clean and predictable URL structures for websites and APIs, debug connection and routing issues accurately, encode parameters correctly to avoid malformed requests, and recognise and remove the tracking noise that accumulates on URLs shared across the web. For automatic tracking parameter removal while you browse, Advanced URL Cleaner is available for Chrome and Firefox. Continue learning with URLs, domain names, HTTP methods, and REST APIs to build a complete understanding of how the web locates and accesses its resources.