When you plan pages for a new website, you will eventually need to write down each page's full address so that collaborators, designers, or your future self can find the right spot. This article walks through one hypothetical address step by step, showing how to identify every part, record it clearly, and verify your notes before sharing them.
What a Domain Name Answers and What a Full URL Answers
Suppose you are sketching out a small personal project that will eventually live at example.org. Before any page is built, you already know the domain name: example.org. A domain name identifies which web server you want to reach. According to MDN, the domain indicates which web server is being requested, and it is usually written as a domain name rather than a raw IP address because that is far more convenient for people to remember and type.1
A full URL answers a more specific question: which exact resource on that server do you want? MDN defines a URL as the address of a unique resource on the internet, one of the key mechanisms browsers use to retrieve published resources such as HTML pages, CSS documents, and images. Wikipedia describes a URL as a reference that specifies both the location of a resource on a computer network and a mechanism for retrieving it. So the domain gets you to the right building, while the full URL tells you which room, which shelf, and which book you are looking for.12
For our hypothetical project, imagine you have a page that displays a compact view of your first set of notes, and you want the browser to scroll to an introduction section. The domain alone cannot express all of that. You need the complete address, including a path, a query parameter, and a fragment identifier. The rest of this article uses one made-up address to show how each piece fits together and how you can record it on a simple reference card.
Labeling Every Part of the Example Address
Here is the hypothetical address we will work with throughout this article: https://example.org/notes/first-page?view=compact#intro — this string is invented purely for the purpose of practicing how to read and label URL components; it does not point to a real page that exists or is published anywhere.
The first segment, https, is the scheme. MDN explains that the scheme indicates the protocol the browser must use to request the resource, and for websites this is usually HTTPS or its unsecured version HTTP. The scheme is followed by the separator :// which signals that the authority component comes next.1
The authority in our example is example.org. This is the domain name that identifies the web server. After the domain comes the path, which in our example is /notes/first-page. MDN notes that a path like this represents a location on the web server, and although in the early days of the web it corresponded to a physical file, nowadays it is mostly an abstraction handled by web servers without any physical reality.1
Same Host, Different Paths and Queries
After the path comes the question mark, which introduces the query component. In our example, ?view=compact is the query string. MDN describes query parameters as extra information provided to the web server, formatted as key-value pairs. The key here is view and the value is compact. The web server can use those parameters to do extra processing before returning the resource, though each server has its own rules about how parameters are handled.1
Finally, the hash sign introduces the fragment identifier: #intro. MDN explains that 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; it only affects what the browser displays after the page loads.1
Now consider what happens if we keep the host part unchanged but swap other pieces. The address https://example.org/notes/first-page?view=full#intro would request the same page but with a different view parameter. The address https://example.org/notes/second-page?view=compact#intro would point to a different path entirely while keeping the same query and fragment. These are three distinct URLs that share the same domain but reach different resources or display states. When you record addresses for a project, paying attention to which part changed helps you describe the difference precisely to a collaborator.1
Building an Address Description Card
Write down the purpose of the page in one short sentence before you record the address itself. For our hypothetical example, you might write: "Displays the first set of project notes in a compact layout, scrolled to the introduction section." This sentence captures the intent so that anyone reading your card later can quickly confirm whether this is the address they need.
Record the full address on its own line, exactly as it should appear in a browser's address bar. Then add a breakdown listing each component with a short label: scheme is https, domain is example.org, path is /notes/first-page, query is view=compact, and fragment is intro. Keeping the breakdown separate from the full string means you can spot a missing slash or a misspelled parameter without re-reading the entire address character by character.
If your project has multiple pages, make one card per page. Each card should include the page name you use internally, the full address, and any notes about why a particular query parameter or fragment exists. This habit prevents the common situation where a team member copies an address from memory and accidentally drops the query string or uses an outdated path.
Verifying the Card by Hand
Check each labeled part against the full address string one segment at a time. Start from the left: confirm the scheme and the :// separator are present. Then confirm the domain matches what you wrote on the card. Move to the path and verify that every slash and segment name is spelled correctly. Finally, look at the query and fragment to make sure the question mark and hash sign are in the right positions.
Record any discrepancies you find directly on the card rather than trying to remember them. If the path on your card says /notes/first-page but the address string shows /notes/firstpage without the hyphen, note that difference immediately. Small inconsistencies like a missing hyphen or a swapped parameter value are among the most frequent causes of broken links during early project handoffs.
Use a second pass to confirm that your purpose sentence still matches the address. If the sentence says "compact layout" but the query reads view=full, one of them is wrong. This cross-check between the plain-language description and the technical string catches errors that a character-by-character scan might miss, because you are comparing meaning rather than just spelling.
Keeping the Record for Future Use
Store your completed cards in a place that everyone on the project can access, such as a shared document or a dedicated section of your project wiki. The goal is to have a single source of truth so that no one needs to reconstruct an address from memory or dig through chat history to find the correct version.
When you add a new page or change an existing address, update the corresponding card at the same time. Treating the card as a living document rather than a one-time exercise keeps it reliable. If you decide to remove a query parameter or rename a path segment, the card should reflect that change before you share the address with anyone else.
Over time, this collection of cards becomes a lightweight reference that answers questions like "Which URL shows the compact view?" or "What fragment scrolls to the introduction?" without requiring anyone to open a browser and experiment. The investment of a few minutes per page during planning saves considerably more time during reviews, handoffs, and troubleshooting later in the project.
Frequently asked questions
Do I need to include the scheme when I write down an address for my project notes?
Yes, including the scheme (such as https) makes the address complete and unambiguous. MDN notes that in a browser's address bar you can omit the protocol because the browser fills it in by default, but when you are recording addresses for other people or for your own future reference, writing the full scheme avoids confusion.1
Is the fragment part of the address sent to the server?
No. MDN states that the part after the hash sign, also known as the fragment identifier, is never sent to the server with the request. It only tells the browser where to scroll or jump within the already-loaded page.1
What is the difference between a query string and a fragment in a URL?
A query string begins with a question mark and passes extra key-value data to the web server, which may use it to customize the response. A fragment begins with a hash sign and points to a specific spot within the resource itself; it is handled entirely by the browser and never reaches the server.12