Before you publish a website, you will encounter two related but distinct concepts: the domain name and the full URL. Confusing them can lead to miscommunication with collaborators or errors when setting up links. This article uses a single hypothetical address to show exactly what each part means and how to record it clearly.
What Question Does Each Part of an Address Answer?
Imagine you are preparing a small personal project site and you want to share a specific page with a friend. You type something into the browser address bar, but what exactly is each piece doing? A domain name answers one question: which server on the internet should the browser contact? It provides a human-readable label for what would otherwise be a numeric IP address that computers handle easily but people find hard to remember. A full URL answers a broader question: which specific resource on that server should be retrieved, and under what conditions?12
To make this concrete, consider the following hypothetical address: https://example.org/notes/first-page?view=compact#intro. This address does not point to a real page that exists or has been published anywhere. It is constructed purely so we can label each segment and understand its role. Treat it as a practice string for the rest of this article.
With that example in mind, the domain name portion is example.org. It tells the browser which server to reach. Everything else in the string narrows down what to ask that server for and how to present the result. The distinction matters because you might control a domain name while the paths, queries, and fragments on it change frequently as you add or reorganize content.12
Labeling Each Segment of the Example Address
The first segment, https, is the scheme. It indicates the protocol the browser must use to request the resource. For websites the protocol is typically HTTPS or its unsecured version HTTP. The scheme is always followed by the character pattern :// which separates it from the next part of the address.2
The next segment, example.org, is the host. In this case it is a domain name that identifies the web server. The dot separates the label example from the top-level domain org. The top-level domain is the final component of a domain name and often serves as a clue to the purpose or category of the service behind it.13
After the host comes the path: /notes/first-page. The path represents the location of a resource on the web server. In the early days of the web a path corresponded to a physical file location, but today it is mostly an abstraction handled by web servers without any physical reality. The question mark that follows introduces the query string: ?view=compact. Query parameters are extra key-value pairs provided to the web server, and the server can use them to adjust what it returns. Finally, the hash symbol introduces the fragment: #intro. The fragment is an anchor to a specific spot inside the resource itself. It is worth noting that the part after the hash is never sent to the server with the request.2
Same Host, Different Paths and Queries
Now keep the host portion fixed at example.org and change only the path. Compare https://example.org/notes/first-page with https://example.org/gallery/summer-2024. The host is identical, meaning the browser contacts the same server, but the path points to a different resource location. This is how a single domain can serve many distinct pages without needing a separate domain for each one.2
Next, keep both the host and path the same but change the query string. Compare https://example.org/notes/first-page?view=compact with https://example.org/notes/first-page?view=full. The path is unchanged, so the browser still requests the same resource location, but the query parameter suggests a different presentation or filtering option. What the server actually does with that parameter depends entirely on how the server is configured; the URL string alone does not guarantee any particular behavior.2
Finally, changing only the fragment from #intro to #summary does not alter what the browser requests from the server at all, because fragments are not sent with the request. Instead, the fragment tells the browser where to scroll or focus once the resource has loaded. Observing these differences in the string helps you understand what each part controls without needing to test against a live server.2
Building an Address Description Card
Record the purpose of the address in one short sentence. For our hypothetical example, you might write: “This is the compact reading view of my first notes page, scrolled to the introduction section.” Keeping the purpose plain helps you verify later whether the address still matches what you intended.
Write the full address on its own line exactly as it should appear: https://example.org/notes/first-page?view=compact#intro. Below it, list each part with a brief label. Scheme: https. Host: example.org. Path: /notes/first-page. Query: view=compact. Fragment: intro. This card format gives you a quick reference you can share with a collaborator or revisit months later without re-deriving the breakdown.
If your project will eventually have multiple pages, create one card per address. Over time the collection becomes a simple inventory that shows which paths you have planned, which queries you rely on, and which fragments you use for internal navigation. The format is entirely up to you; the key is that each card separates the parts rather than presenting only the raw string.
Verifying the Card by Hand
Check each segment of your written address against the card by copying the full string into a plain-text editor and manually inserting a line break after each boundary. Place one break after ://, one after the host, one before the question mark, and one before the hash. You should end up with five lines corresponding to scheme, host, path, query, and fragment.
Label each line with its part name and compare the labels to your card. If a segment is missing or misplaced, the line breaks will reveal the gap immediately. For instance, if you accidentally omit the question mark, the query string will appear attached to the path, and the mismatch becomes visible at a glance.
Use this manual check any time you copy an address from a document, a chat message, or a design mockup. Copying introduces risks of extra spaces, missing slashes, or swapped characters. A quick line-break verification catches these before the address reaches a live environment. This is a personal workflow suggestion, not a requirement from any specification.
Keeping the Record for Future Use
Store your address cards in a place you already consult regularly, such as a project readme, a notes application, or a simple text file in your site repository. The goal is to reduce the friction of looking them up when you need to write a link in a new page, share a URL with a collaborator, or debug why a link is not working as expected.
When your project grows, you may find that some addresses change. A path might be reorganized, a query parameter renamed, or a fragment removed. Because each card records the purpose alongside the string, you can quickly identify which cards need updating and which remain valid. This is simpler than searching through a long list of raw URLs with no context.
The recording choices described here are author suggestions based on general organizational practice. You are free to adapt the format, add fields like a last-checked date, or group cards by section of your site. What matters most is that the breakdown into parts remains visible, so that the next time you or someone else reads the address, each segment is immediately identifiable.
Frequently asked questions
Is the domain name the same thing as the URL?
No. The domain name identifies the server, while the full URL includes the domain name plus additional parts such as the scheme, path, query, and fragment that specify exactly which resource to retrieve and how to present it.12
Does changing the fragment in a URL send a different request to the server?
No. The fragment, which is the part after the hash symbol, is never sent to the server with the request. It only tells the browser where to focus within the already-loaded resource.2
Can one domain name serve many different pages?
Yes. The path portion of a URL allows a single domain to point to many distinct resources. You do not need a separate domain name for each page on your site.2