Before you publish a website, you will need to understand the difference between a domain name and a full URL. This article walks through one hypothetical address, labels every part, and shows how to build a simple reference card you can reuse when writing content or sharing links.
What Question Does a Domain Name Answer, and What Question Does a Full URL Answer?
Imagine you are planning a small personal site for sharing reading notes. You have heard people talk about “getting a domain” and “sharing a link,” but the two phrases seem to point at the same thing. They do not. A domain name answers the question “which server or organization am I reaching?” while a full URL answers “which specific resource on that server do I want, and how should I ask for it?” The distinction matters because you will use the domain name when you describe your site in general conversation, but you will work with full URLs every time you create a page, insert a link, or tell someone where to find a particular document.12
Domain names exist because the underlying network identifies machines by numerical IP addresses, which are difficult for people to remember and may change over time. A domain name provides a stable, human-readable label that maps to whichever address the server currently uses. A URL builds on that label by adding directions: which protocol to use, which path to follow once you arrive, and optionally which parameters or bookmark to apply. In other words, the domain is the destination, and the URL is the complete set of travel instructions.12
For the rest of this article we will use a single hypothetical address to make these ideas concrete. The address is https://example.org/notes/first-page?view=compact#intro. This is not a live page; it exists purely so we can practice reading the structure of a URL. Every observation below refers only to what the string itself tells us, not to what any particular server might do with it.
Labeling Each Part of the Example Address
Take the string https://example.org/notes/first-page?view=compact#intro and split it at the natural boundaries. The scheme is https, which tells the browser to use the secure HTTP protocol when requesting the resource. The authority section begins after the characters :// and contains the domain name example.org. The path is /notes/first-page, which points to a specific resource on that server. Everything after the question mark is the query string, here view=compact. Everything after the hash symbol is the fragment identifier, here intro. The question mark introduces the query; the hash introduces the fragment.2
The domain name itself has internal structure. In example.org, the label org is the top-level domain, which gives a general hint about the purpose or category of the service. The label example is the second-level domain, the part that most people think of as “the name.” Top-level domains are managed by organizations designated by ICANN, and the full list is maintained centrally. Some TLDs like .com, .org, and .net are generic and do not impose particular eligibility criteria, while others carry restrictions.13
Notice that the path, query, and fragment are all optional components. A URL like https://example.org/ is perfectly valid and points to whatever resource the server designates as its default. Our example simply includes all three optional parts so that we have something to label. When you build your own site, you will decide which paths and parameters your pages actually need; not every page requires a query string or a fragment.2
Same Host, Different Paths and Queries
Now keep the host portion example.org fixed and imagine two other addresses: https://example.org/notes/second-page and https://example.org/notes/first-page?view=full. The first shares the same domain and the same top-level directory but points to a different path. The second shares the exact same path as our original example but carries a different query parameter value. These three strings all reach the same server, yet each one identifies a distinct resource or a distinct way of presenting that resource.2
This observation is useful when you plan a site structure. If two pages live under the same domain but have different paths, they are separate resources with separate URLs. If a single page can be displayed with different query parameters, those variations produce different URLs even though the underlying path has not changed. You do not need to know how a particular server will handle these variations; the point is that the URL string itself encodes the distinction, and anyone reading the string can see where one address ends and another begins.2
The fragment identifier behaves slightly differently. Unlike the path and the query, the fragment is never sent to the server with the request. It tells the browser where to scroll or focus within the already-retrieved document. So https://example.org/notes/first-page#intro and https://example.org/notes/first-page#summary would request the same resource from the server but direct the browser to display different sections of it.2
Building an Address Card for Your Hypothetical Project
Write down a short card that records the purpose of each part of your address. For our hypothetical reading-notes project the card might look like this: the purpose of the site is to share annotated reading notes; the full example address is https://example.org/notes/first-page?view=compact#intro; the domain is example.org; the TLD is org; the path is /notes/first-page; the query is view=compact; and the fragment is intro. Having all of this on one card means you never need to re-derive the structure from memory.
Record the reason you chose each value, even if the reason is simply “placeholder for now.” For instance, you might note that the path /notes/first-page reflects a folder structure you plan to mirror in your file organization, or that the query view=compact represents a display mode you want to offer visitors. These notes are for your own reference; they do not need to follow any external standard. The goal is to make future decisions easier by capturing the reasoning you had at the start.
If your project will eventually have more than one page, sketch a few additional addresses on the same card using the same domain but different paths. This gives you a quick visual sense of how your URL structure will grow. You are not committing to anything; you are simply practicing the habit of reading and writing full addresses before the site goes live.
Verifying the Address Card by Hand
Once your card is written, verify it against the actual string using a simple manual process. This catches typos, missing slashes, and misplaced punctuation marks that are easy to overlook when you are reading quickly.
Check that every label on your card matches the corresponding substring exactly. Copy the full address into a plain-text editor, then place a cursor before each boundary character (the colon-slash-slash, the first single slash after the domain, the question mark, and the hash) and confirm that the segment between boundaries matches what your card says. If any segment differs, correct the card rather than the address, because the address string is the fixed reference for this exercise.
Record any discrepancies you find, even minor ones such as a missing trailing slash or a capitalization difference. Domain names are case-insensitive, but paths can be case-sensitive depending on the server, so noting the exact casing you intend is worthwhile. This habit of precise copying and labeling will serve you well when you later configure real links or troubleshoot a broken URL.
Step 1
Copy the full example address into a plain-text document so you have a clean reference without any surrounding formatting.
Step 2
Place your cursor at each boundary character and label the segment to its left or right with the corresponding part name: scheme, domain, path, query, or fragment.
Step 3
Compare each labeled segment against your address card entry. Note any mismatch, no matter how small, and update the card to match the string.
Keeping the Record for Future Use
Store your verified address card in whatever tool you already use for project notes. A simple text file, a note-taking application, or even a bookmark with a descriptive title all work. The important thing is that the card is easy to find later, because you will refer back to it when you write page content, create navigation links, or explain your site structure to someone else.
As your project evolves, update the card whenever you add a new page or change a path. Treat the card as a living document rather than a one-time exercise. If you decide that /notes/first-page should become /notes/2024/first-page, make that change on the card first and then apply it consistently wherever the address appears. This single-source-of-truth approach reduces the chance of ending up with inconsistent links across different parts of your site.
You may also find the card useful when you communicate with collaborators or ask for help in a forum. Instead of pasting a long URL and hoping the other person can parse it, you can share the broken-down version that shows each part separately. This makes it easier for others to spot a mistake or suggest an improvement, and it reinforces your own understanding of how the pieces fit together.
Frequently asked questions
Is a domain name the same thing as a URL?
No. A domain name identifies the server or organization you are reaching, while a URL is the complete address that includes the protocol, domain, path, and optionally a query string and fragment. Every URL contains a domain name, but a domain name alone does not specify which resource on that server you want.12
Does the fragment part of a URL get sent to the server?
No. The fragment identifier, which comes after the hash symbol, is used by the browser to navigate within the already-loaded document. It is never included in the request sent to the server.2
Can two different URLs point to the same domain?
Yes. A single domain can host many different resources, each with its own path. Different query parameters or fragments can further distinguish URLs that share the same domain and path. The domain tells you which server to contact; the rest of the URL tells you which specific resource to retrieve.2