If you are preparing a personal website or a small project site for the first time, you will encounter two related terms that are easy to confuse: domain name and URL. This article uses one hypothetical address to show what each term covers, how the parts of a full URL differ from one another, and how a short reference card can help you keep track of your own addresses as you build.
What Question Does Each Term Answer?
Consider this hypothetical address used purely as a string-reading exercise: https://example.org/notes/first-page?view=compact#intro. This page does not need to exist anywhere on the internet; we are only using it to practice identifying the parts of a web address. The string contains a domain name embedded inside a longer URL, and understanding the difference between those two layers is the first step toward reading any address confidently.
A domain name answers the question "which server on the internet am I 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 hard for people to remember and may change over time. In our example, example.org is the domain name. It tells a browser which server to contact, without specifying any particular page or file on that server.1
A full URL answers a more specific question: "which unique resource on that server do I want?" A URL is the address of a unique resource on the internet, and it is one of the key mechanisms browsers use to retrieve published resources such as HTML pages, images, or stylesheets. In our example, the entire string from https through #intro is the URL. It includes the domain name but adds several more parts that narrow the request down to one particular resource and even one particular spot within it.2
Labeling Every Part of the Example Address
Let us walk through the hypothetical string piece by piece. The segment https is the scheme, which indicates the protocol the browser must use to request the resource. For websites the protocol is usually HTTPS or its unsecured version HTTP. The characters :// separate the scheme from the next part of the URL, called the authority.2
The authority in our example is example.org. This is the domain name, and it indicates which web server is being requested. After the authority comes the path, which in our example is /notes/first-page. The path points to a resource on the web 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 without any physical reality. We can read the path as a series of segments separated by slashes: notes is one segment, and first-page is the next.2
After the path, the question mark introduces the query string. In our example the query is view=compact, which is a key-value pair. Parameters are extra information provided to the web server, formatted as key-value pairs separated by the ampersand symbol when there are multiple pairs. Finally, the hash character introduces the fragment identifier, which in our example is intro. An anchor represents a sort of bookmark inside the resource, giving the browser directions to show the content located at that bookmarked spot. It is worth noting that the fragment identifier is never sent to the server with the request.2
Same Host, Different Paths and Queries
Now keep the host part of our example unchanged and vary only the path. If we change /notes/first-page to /notes/second-page, the domain name and scheme stay identical, but the string points to a different resource location on the same server. The path is what distinguishes one page from another within the same site. We are not claiming that either page actually exists; we are only observing how the string changes.
Next, keep the path the same but change the query string from view=compact to view=full. The domain, scheme, path, and fragment all remain identical in the string. Only the value after the equals sign differs. This shows that the query string is a separate layer of information from the path. Each part of the URL occupies its own position in the string and is introduced by its own delimiter: the question mark opens the query, and the hash opens the fragment.2
You can also remove the fragment entirely and the address still points to the same resource on the server, because the fragment is never sent to the server with the request. Removing it only changes where the browser scrolls within the document once the resource is loaded. This observation helps clarify a common confusion: the fragment affects the reader's view of a page, not which page is fetched. Each part of the string serves a distinct role, and recognizing those roles makes it easier to troubleshoot or describe an address to someone else.2
Building an Address Description Card
Write down a short card for each address your project will use. For our hypothetical example, the card might contain four lines: the purpose of the page, the full URL string, the domain name extracted from it, and a brief note about what the path and query are expected to represent. This is a personal organizational habit, not a technical requirement, but it gives you a single place to look when you need to share or verify an address.
For the purpose line, describe in plain language what a visitor should find at that address. For our example you might write "a compact reading view of the first notes page, scrolled to the introduction section." This description is your own interpretation of what the string parts suggest; it does not come from the server and it does not guarantee what actually appears. The point is to give yourself a human-readable summary next to the technical string.
Record the full URL exactly as you intend to use it, including the scheme, and then list each part separately beneath it: scheme is https, host is example.org, path is /notes/first-page, query is view=compact, fragment is intro. Having each part on its own line makes it easy to spot a typo or a missing delimiter later, especially if you copy the address into different contexts such as a link in an email or a reference in a document.
Verifying the Card by Hand
Check your description card by copying the full URL into a plain-text editor and manually inserting spaces or line breaks at each delimiter. Place a break after ://, before the first / of the path, before the ?, and before the #. This gives you a visual stack that matches the labeled lines on your card. If any segment does not line up with what you recorded, you have found a discrepancy worth correcting before the address goes into production.
Compare the host segment on your card against the domain name you plan to use for the project. A common early mistake is mixing up www and non-www versions, or accidentally including a trailing slash as part of the domain when it actually belongs to the path. In our example the host is example.org with no www prefix and no trailing slash; the first slash belongs to the path. Noting this distinction on your card prevents confusion when you later configure links or share the address with collaborators.
Repeat the labeling exercise for any other addresses your project will use, such as a contact page or an image asset. Each card follows the same format: purpose, full string, then labeled parts. Over time this builds a small reference sheet that you can consult without re-deriving the structure from memory. The effort is minimal, but it reduces the chance of pasting a broken or incomplete address into your site's content.
Keeping the Record for Future Use
Store your address cards in whatever format you already use for project notes: a text file, a spreadsheet, or a page in a wiki. The format matters less than consistency. Choose one location and update it whenever you add, rename, or remove a page. If you later hand the project to a collaborator, the cards give them a quick orientation without requiring them to reverse-engineer every URL from the site's navigation.
When you write documentation, share links in messages, or embed addresses in templates, copy from your card rather than retyping from memory. This is a simple habit, but it catches errors that are invisible when you type quickly, such as a missing question mark that turns a query string into part of the path, or a hash placed before the query instead of after it. The card acts as a single source of truth for the string itself.
You do not need to document every possible URL your site could ever produce. Focus on the addresses you actively reference: the pages you link to from other sites, the assets you embed, and any address you share publicly. For our hypothetical project, the one card for the notes page is enough to demonstrate the method. As your site grows, add cards only when an address becomes important enough that a mistake would cost you time to track down.
Frequently asked questions
Is the domain name the same thing as the URL?
No. A domain name identifies which server to contact, while a URL is the full address that also includes the scheme, path, and optionally a query string and fragment. The domain name is one part inside the URL.12
Does the fragment after the hash get sent to the server?
No. The fragment identifier, which is the part after the hash character, is never sent to the server with the request. It only tells the browser where to scroll within the already-loaded document.2
Do I need to include the scheme when I write an address on my card?
Including the scheme is a good habit for your reference card because it makes the string complete and unambiguous. In a browser's address bar you can often omit it, but in documentation or shared notes the full form avoids confusion with other protocols.