When you prepare a list of page addresses for a collaborator or a future reference document, the difference between a domain name and a full URL matters. This article walks through one hypothetical address, labels each part, and shows how to build a simple description card you can reuse.
What Domain Names and Full URLs Each Answer
Suppose you are planning a small project site and you need to hand a colleague a list of pages to review. You write down example.org and then a longer string: https://example.org/notes/first-page?view=compact#intro. These two strings answer different questions. A domain name is a human-readable address for a web server available on the Internet; it tells you which server to reach but not which specific resource on that server you want. A full URL, by contrast, is the address of a unique resource on the internet and includes enough detail for a browser to retrieve one particular page, image, or document. In our hypothetical exercise, example.org is the domain name, and the entire string starting with https is the full URL. Neither page nor address actually exists on a live server; we are using them purely to practice reading and recording address strings.12
This distinction becomes practical the moment you hand off a link list. If you record only the domain, your collaborator knows which site to visit but must guess which page you meant. If you record the full URL, they can paste it directly into a browser address bar and arrive at the exact resource you intended. For a handoff checklist, recording the full URL alongside a short human-readable page name gives your recipient both context and a working address.
The hypothetical address we will use throughout this article is https://example.org/notes/first-page?view=compact#intro. Treat it as a string to dissect. We are not claiming this page is published or accessible. The exercise is about recognizing each component so that when you encounter real project addresses, you can label and record them with the same confidence.
Labeling Each Part of the Example Address
A URL is composed of different parts, some mandatory and others optional. In our example, the scheme is https, which indicates the protocol the browser must use to request the resource. The authority is example.org, which indicates which web server is being requested. The path is /notes/first-page, representing the location of the resource on that server. After the path comes a question mark followed by view=compact; the question mark introduces the query parameters, which are extra key-value pairs provided to the web server. Finally, a hash sign introduces the fragment intro, which acts as a bookmark inside the resource itself, pointing the browser to a specific spot within the page.2
Writing these labels beside the address string is the core of the handoff exercise. The question mark always signals the start of query parameters, and the hash sign always signals the start of the fragment identifier. These two delimiters are fixed rules of URL structure, not choices made by the site author. When you record an address for a colleague, marking where the question mark and hash appear helps them understand which portion is the page location and which portion is supplementary information.2
In our hypothetical string, the fragment intro is never sent to the server with the request; it only instructs the browser where to scroll or focus once the page loads. This means that if your collaborator removes the fragment portion, they will still reach the same page, just without the automatic scroll position. Noting this on your description card can prevent confusion when someone reports that a link “didn’t work” simply because they stripped the trailing fragment during copy-paste.2
Comparing Paths and Queries While Keeping the Host the Same
Now keep the host portion example.org unchanged and vary the rest. Consider https://example.org/notes/second-page?view=compact#intro. The only difference is the path segment second-page instead of first-page. The scheme, host, query, and fragment are identical. This illustrates that the path is the part that distinguishes one page from another on the same server. When you build your handoff list, the path is often the field where you will see the most variation between entries.
Next, change only the query: https://example.org/notes/first-page?view=expanded#intro. The page location is the same, but the query parameter now carries a different value. We are not inferring what the server actually does with this parameter; we are simply observing that the string differs after the question mark. Recording the query string on your card lets your collaborator know that this address may present a different view or state than the version without the parameter.
Finally, remove the fragment entirely: https://example.org/notes/first-page?view=compact. The page and its query remain the same, but there is no bookmark directing the browser to a particular section. Comparing these three variants side by side shows that each portion of the string serves a distinct role. The path locates the resource, the query passes additional information, and the fragment positions the reader within the loaded content. Noting which parts changed between two addresses is a straightforward way to explain differences to a teammate without needing to discuss server-side behavior.
Building an Address Description Card
Record a short description card for each address in your handoff list. A useful card contains four fields: a human-readable page name you choose yourself, the full address string, a labeled breakdown of each component, and a one-sentence note explaining why this page matters in the project. For our hypothetical example, the page name might be “First notes page, compact view.” The full address is https://example.org/notes/first-page?view=compact#intro. The breakdown lists scheme, host, path, query, and fragment separately. The note might read: “This is the landing page for the notes section in compact display mode.”
The purpose of the card is to make handoff conversations faster. Instead of pasting a raw string and asking a colleague to figure out what it points to, you hand them a structured summary. If you maintain several pages, each card follows the same format, so the reader can scan a list and spot differences at a glance. This is a formatting choice, not a technical requirement; you can adapt the fields to whatever makes sense for your project.
When you write the note field, keep it brief and factual. Describe the page’s role in the project rather than speculating about server configuration or implementation details you cannot verify. A note like “Compact view of the first notes entry, used for quick scanning” is clear and actionable. Avoid notes that promise specific behavior unless you have confirmed it yourself.
Checking the Card by Hand
Copy the full address from your description card into a plain-text editor and label each part manually. Start from the left: write “scheme” above https, then “host” above example.org, then “path” above /notes/first-page, then “query” above view=compact, and “fragment” above intro. This takes only a moment and catches common transcription errors such as a missing slash, a swapped question mark and hash, or a typo in the host.
Check the delimiters next. Verify that the colon and two slashes appear between the scheme and the host, that the question mark appears exactly once before the query, and that the hash appears exactly once before the fragment. If any delimiter is missing or duplicated, the address will not behave as intended when pasted into a browser. This manual check is a simple habit that prevents back-and-forth messages with your collaborator about broken links.
After labeling, compare your breakdown against the fields on the description card. If the card says the path is /notes/first-page but your manual labeling shows /notes/first_page with an underscore, you have found a discrepancy before it reaches your teammate. Repeat this process for every entry in your handoff list. It scales well because each card is short, and the labeling steps are identical regardless of how complex the address is.
Keeping the Description for Future Use
Store your completed description cards in a single document or note file that you can reference during future writing, design reviews, or communication with collaborators. The cards serve as a shared vocabulary: when someone mentions the “compact notes page,” everyone can look up the card and confirm which full address that shorthand refers to. This reduces ambiguity in conversations, especially when a project has several similar pages.
Write a brief note at the top of your card collection explaining your naming choices. For instance, you might state that page names use the section title followed by the view mode, and that fragments are included only when they point to a meaningful heading. Documenting your own conventions is optional but helpful when another person joins the project later and needs to add new entries without guessing your format.
Update the cards whenever a page address changes. If a path is renamed or a query parameter is added, revise the corresponding card and note the date of the change. This keeps the handoff list accurate over time and prevents outdated addresses from circulating in team messages. The maintenance effort is small because each card is only a few lines, and the habit of keeping them current pays off whenever you onboard a new collaborator or revisit the project after a break.
Frequently asked questions
Do I need to include the fragment when sharing an address with a collaborator?
It depends on whether the specific scroll position matters for your conversation. The fragment only tells the browser where to focus within the page; the page itself loads without it. Include the fragment when you want your collaborator to see a particular section immediately, and omit it when the whole page is relevant.2
What is the difference between the query part and the fragment part of a URL?
The query, introduced by a question mark, passes extra parameters to the web server and can influence what content is returned. The fragment, introduced by a hash sign, is a bookmark within the resource and is never sent to the server; it only affects where the browser scrolls or focuses after the page loads.2
Can I record just the domain name instead of the full URL on my handoff checklist?
You can, but it gives your collaborator less information. A domain name identifies the server but not the specific page. Recording the full URL ensures the recipient can reach the exact resource you intended without additional instructions.12