When you hand off a list of page links to a collaborator or record them for your own future reference, a bare domain name alone rarely tells the full story. This article walks through a single hypothetical address, breaks it into labeled parts, and shows how to build a simple description card you can reuse in any project.
What a Domain Name Answers and What a Full URL Answers
Suppose you are planning a small personal project and you write down example.org as the place where your pages will eventually live. That string is a domain name. Domain names provide a human-readable address for a web server available on the Internet, solving the problem that raw IP addresses are hard to remember and might change over time. At this stage, example.org tells you which server you intend to use, but it does not yet point to any specific page or file on that server.1
Now suppose you want to share the exact location of one particular page with a friend. You need more than the domain name. 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. In theory, each valid URL points to a unique resource. So while the domain name answers the question “which server?”, the full URL answers the question “which specific resource on that server?” For our hypothetical project, the full address we will use throughout this article is https://example.org/notes/first-page?view=compact#intro. This address is invented purely to practice reading its parts; we are not claiming that this page exists or has been published anywhere.2
The distinction matters when you hand off links. If you only write down example.org, your collaborator can reach the server but has no way to know which page you meant. If you write the full URL, the recipient can go directly to the intended resource. Keeping both pieces of information—the domain and the complete address—in your notes avoids ambiguity later.
Reading Each Part of the Example Address
Let us look at the hypothetical address piece by piece. The string begins with https, which is the scheme. The scheme indicates the protocol that the browser must use to request the resource. For websites the protocol is usually HTTPS or HTTP. In our example, https tells the browser to use the secure version of the protocol when connecting to the server.2
After the scheme and the separator ://, we find example.org. This is the host portion of the URL, and it identifies which web server is being requested. The host here is our hypothetical domain name. Following the host comes the path, which in this case is /notes/first-page. The path represents the location of the resource on the web server. After the path, a question mark introduces the query string: ?view=compact. The parameters after the question mark are extra key-value pairs provided to the web server. Finally, a hash sign introduces the fragment: #intro. The 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 part after the hash sign is never sent to the server with the request.2
To summarize the labeling for our example: https is the scheme, example.org is the host, /notes/first-page is the path, view=compact is the query parameter, and intro is the fragment identifier. The question mark always signals the start of the query portion, and the hash sign always signals the start of the fragment. Recognizing these two delimiter characters lets you split any URL into its major sections without needing special tools.2
Comparing Paths and Queries on the Same Host
Keep the host example.org unchanged and imagine a second page at /notes/second-page. The scheme and host are identical to our first address, but the path is different. This means the two URLs point to different locations on the same server. From the string alone you can see that the paths differ; you cannot, however, conclude anything about how the server actually organizes its files or what content each path returns. The string tells you the address, not the implementation.
Now change the query string instead. Compare ?view=compact with ?view=expanded. Both addresses share the same scheme, host, and path, but they carry different parameter values. The parameter name is view in both cases; only the value changes. Again, you can observe the textual difference without knowing whether the server treats these two values differently. The query string is simply extra information passed along with the request.
Finally, consider removing the fragment entirely. The address https://example.org/notes/first-page?view=compact is the same request to the server as the version with #intro appended, because the fragment is never sent to the server. The fragment only affects what the browser does after receiving the page—in this hypothetical case, scrolling to a section labeled intro. When you record addresses for a handoff, noting whether a fragment is present helps your collaborator understand whether the link is meant to land on a specific section of the page or on the page as a whole.2
Building an Address Description Card
Write down a short card for each page address you plan to share or reference later. For our hypothetical project, the card might contain three fields: a plain-language purpose note, the full URL, and a labeled breakdown of each part. The purpose note is your own description of what the page is for, such as “first draft of the notes section, compact reading view.” This note is not part of the URL itself; it is context you add for yourself or your collaborator.
Record the full URL exactly as you intend it to appear: https://example.org/notes/first-page?view=compact#intro. Below it, list each component on its own line—scheme, host, path, query, fragment—with a brief label. This labeled breakdown makes it easy to spot which part changed if you later create a variation of the address.
Decide whether to include the fragment in your card. If the purpose of sharing the link is to direct someone to a specific section, keep the fragment and note that it controls the browser’s scroll position. If the purpose is simply to reach the page, you may omit the fragment and add a note saying the fragment was intentionally left out. Either choice is valid; what matters is that you state the choice explicitly so a future reader does not wonder whether the omission was accidental.
Verifying the Card by Hand
Check your description card against the original address string before you share it. A simple manual process catches typos and missing parts without requiring any software. The following steps are author suggestions based on ordinary careful practice, not requirements from any specification.
If you find a mismatch, correct the card and repeat the labeling pass from the beginning. It is easy to fix one character and miss a second error elsewhere, so a fresh pass over the entire string is more reliable than a spot fix. Once every part matches, mark the card as verified with the date you checked it.
This process takes only a minute per address, but it prevents the most common handoff mistakes: a missing slash, a misspelled parameter value, or a fragment that was accidentally deleted. For a project with many pages, you can batch the verification into one session and note the date on each card.
Step 1
Copy the full URL from your card and paste it into a plain-text editor or a blank line in your notes file. Do not rely on a browser address bar that might auto-complete or hide characters.
Step 2
Starting from the left, label the scheme by finding the :// separator. Everything before it is the scheme. Write the label above or beside that portion.
Step 3
Next, identify the host. It runs from just after :// up to the first single slash that follows. In our example, that portion is example.org. Label it.
Step 4
Find the path by reading from that first slash after the host up to the question mark, if one exists. If there is no question mark, the path runs to the hash sign or to the end of the string. Label the path portion.
Keeping the Record for Future Use
Store your address cards in whatever format you already use for project notes—a plain-text file, a spreadsheet, or a dedicated notes application. The format matters less than consistency. If every card follows the same three-field structure of purpose, full URL, and labeled parts, you or a collaborator can scan the list quickly and find the right address without re-deriving it from memory.
When the project grows and you add more pages, resist the urge to shorten older cards by removing the labeled breakdown. The breakdown is most useful precisely when you have many similar addresses and need to see at a glance which path or query differs. A few extra lines per card save considerably more time than they cost during the initial recording.
Finally, treat the card as a living document. If you change a path, update the card on the same day and note the change. If you decide to drop a query parameter from a shared link, record the reason in the purpose field. These small annotations turn a static list of URLs into a lightweight history of your decisions, which is exactly what a handoff checklist should provide to the next person who picks up the project.
Frequently asked questions
Do I need to include the fragment every time I share a URL?
No. The fragment only tells the browser where to scroll within a page and is never sent to the server. Include it when you want the recipient to land on a specific section; omit it when reaching the page itself is enough. Either way, note your choice on the card so the omission looks intentional.2
What is the difference between the query string and the path?
The path identifies the resource location on the server, while the query string carries extra key-value parameters that the server may use before returning the resource. In our example, /notes/first-page is the path and view=compact is the query parameter. They serve different roles in the address string.2
Can I rely on a domain name alone when handing off a page link?
A domain name identifies the server but not the specific page. If your project has more than one page, sharing only the domain leaves the recipient guessing which resource you meant. Record and share the full URL whenever you need to point to a particular page.12