Before you publish a website, you will encounter two related but distinct concepts: the domain name and the full URL. Understanding what each one tells you helps you read, write, and share addresses with confidence. This article uses a single hypothetical address to show how the pieces fit together and how you can keep a clear record of them.
What Domain Names and Full URLs Each Answer
A domain name answers one specific question: which server on the Internet are you trying to reach? Domain names provide a human-readable address for any web server available on the Internet, because the numeric IP addresses that computers actually use are difficult for people to remember and may change over time. In our running example, the domain name is example.org. It identifies the host without specifying anything about which page, file, or section you want on that host.1
A full URL answers a broader question: which specific resource on that server, and how should the browser request it? A URL is the address of a unique resource on the internet, and it is one of the key mechanisms used by browsers to retrieve published resources such as HTML pages, CSS documents, and images. The same domain name can appear in many different URLs, each pointing to a different resource. So while the domain name tells you where to go, the complete URL tells you what to ask for once you arrive.2
For the rest of this article, we will work with one hypothetical address: https://example.org/notes/first-page?view=compact#intro. This address is constructed purely for the purpose of labeling its parts. It does not represent a live page, and no server is expected to respond to it. Treat it as a string to be read and annotated, not as something to type into a browser.
Labeling Each Part of the Example Address
The scheme in our example is https, which appears before the :// separator. The scheme indicates the protocol that the browser must use to request the resource. For websites, the protocol is usually HTTPS or its unsecured version HTTP. In this example, https tells the browser to use a secure connection when it contacts the server.2
After the :// separator comes the authority section, which in our example is simply example.org. This is the domain name, and it indicates which web server is being requested. The port is omitted here because HTTPS uses a standard port by default, so the browser does not need it spelled out. Everything before the first forward slash after the authority belongs to this host identification.2
The path in our example is /notes/first-page. It follows the domain name and points to a resource on the server. In the early days of the web, a path like this represented a physical file location, but nowadays it is mostly an abstraction handled by web servers. The question mark that follows introduces the query component: view=compact. The query provides extra parameters to the web server as a list of key and value pairs. Finally, the hash sign introduces the fragment: intro. The fragment represents a bookmark inside the resource itself, giving the browser directions to show content at that specific spot. Notably, the fragment is never sent to the server with the request.2
Comparing Strings With the Same Host
Now keep the host part of our example unchanged and swap only the path. Compare https://example.org/notes/first-page?view=compact#intro with https://example.org/notes/second-page?view=compact#intro. The domain, scheme, query, and fragment are identical; only the path differs. As strings, these two addresses are distinct, and they would point to different resources if a server were serving them. The observation here is purely about the text: changing the path changes the address, even when everything else stays the same.
Next, keep the path the same but change the query. Compare https://example.org/notes/first-page?view=compact#intro with https://example.org/notes/first-page?view=full#intro. Again the host is unchanged, and the path is unchanged. The only difference is the value after the equals sign in the query. This shows that the query is a separate component from the path, and altering it produces a different URL string without touching the host or path portions.
You can also remove the fragment entirely. The address https://example.org/notes/first-page?view=compact is still a valid URL, just one without a bookmark inside the document. Each component—scheme, host, path, query, and fragment—can be present or absent independently. When you are reading or constructing an address, identifying which components are present and which are missing helps you understand what the address is asking for and what it is leaving unspecified.
Building an Address Description Card
For a hypothetical project, you can create a simple description card that records what each address is for. Start with the purpose: why does this address exist? In our example, the purpose might be "a reading view of the first note in a compact layout, bookmarked to the introduction section." Writing the purpose in plain language forces you to think about what each component contributes before you move on to labeling.
Below the purpose statement, write the full address exactly as you intend it to appear. Then list each component on its own line: scheme, host, path, query, and fragment. For our example, that gives you five lines, each naming one part and showing its value. This layout makes it easy to spot a missing component or a typo in any single part without re-reading the entire string.
You do not need any special tool for this card. A plain text file, a note in a document, or even a handwritten index card works. The key is that the card lives somewhere you can find again when you need to share the address, embed it in another document, or explain it to a collaborator. Keeping the format consistent across multiple addresses in the same project makes comparison straightforward later.
Verifying the Card by Hand
Copy the full address from your description card into a blank line of text, character by character, without using paste. This slow manual process catches transposition errors and missing characters that a quick glance would skip. If the copied string does not match the original exactly, you have found a mistake worth correcting before the address goes anywhere else.
Mark each boundary on your copied string with a visible separator. Place a vertical bar after the scheme and the :// pair, another after the host, another after the path, and another after the query. For our example, the marked version reads https:// | example.org | /notes/first-page | ?view=compact | #intro. Each boundary should fall exactly where the corresponding component ends according to the rules you labeled on your card.
Check the card against the marked string one component at a time. Confirm that the scheme matches, that the host matches, that the path matches including its leading slash, that the query key and value match, and that the fragment matches. If any component differs, correct the card or the address and repeat the marking step. This loop of copy, mark, and compare is a simple habit that prevents small errors from propagating into links, documentation, or shared messages.
Keeping the Record for Future Use
Store the description card alongside your other project notes. If your project has multiple addresses—for a homepage, a blog section, or a contact page—give each one its own card so you can look up any of them without scrolling through a long list. A consistent naming convention for the files or entries, such as including the page name in the card title, makes retrieval faster as the project grows.
When you share an address with a collaborator or include it in written instructions, refer back to the card rather than retyping from memory. This habit reduces the chance of introducing a typo at the moment of sharing. If the address changes later, update the card at the same time you update the live reference so the two stay in sync.
Over time, these cards become a lightweight reference for your project's address structure. You can use them when writing documentation, when explaining your site layout to someone new, or when deciding whether a planned new page fits the existing path pattern. The effort to build and maintain them is small, and the payoff is a clear, verifiable record that you control.
Frequently asked questions
Is the domain name the same thing as the URL?
No. The domain name identifies the server, while the full URL identifies a specific resource on that server and includes additional components such as the scheme, path, query, and fragment.12
What does the question mark in a URL indicate?
The question mark introduces the query component, which provides extra parameters to the web server as key and value pairs. In our example, ?view=compact is the query.2
Is the fragment part of the URL sent to the server?
No. The fragment, which follows the hash sign, is never sent to the server with the request. It acts as a bookmark inside the resource for the browser to use locally.2