Before launching a personal website or small project, you will encounter two related but distinct concepts: the domain name and the full URL. Confusing them can lead to miscommunication with collaborators or errors when setting up your site. This article uses a single hypothetical address to show how each part works and how to record your findings for future reference.12
What Question Does Each Part Answer?
Suppose you are planning a small personal project and you write down a sample address to test your understanding: https://example.org/notes/first-page?view=compact#intro. This address is purely hypothetical and is used only as a string to take apart; it does not point to a real page. Looking at it for the first time, you might wonder what each segment is doing and why some parts seem optional while others feel essential.
A domain name answers the question “which server on the Internet am I trying to reach?” Domain names are a key part of the Internet infrastructure because they provide a human-readable address for any web server available on the Internet. Computers communicate through IP addresses, which are difficult for people to remember and may change over time, so domain names solve that problem by giving us a stable, readable label.1
A full URL answers a broader question: “which specific resource on that server do I want, and under what conditions?” 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 other words, the domain name identifies the building, while the full URL specifies the exact room, the floor, and even the particular shelf you are looking for.2
Reading the Example Address Piece by Piece
Now take the same hypothetical string and mark each segment. The opening portion, https, is the scheme. It tells the browser which protocol to use when requesting the resource. For websites the scheme is usually HTTPS or its unsecured version HTTP. The separator between the scheme and the next part is the character pattern ://, where the colon divides the scheme from what follows and the double slash signals that an authority section comes next.2
The authority section in our example is example.org. This is the domain name, and it indicates which web server is being requested. According to MDN, the domain name is usually a human-readable name, though an IP address could also appear here; in practice, IP addresses are rare in this position because they are much less convenient for people.2
After the authority comes the path: /notes/first-page. The path points to a resource on the web server. In the early days of the web this represented a physical file location, but today it is mostly an abstraction handled by web servers without any physical reality. Following the path is a question mark, which introduces the query string view=compact. Query parameters are extra key-value pairs provided to the web server, and the server can use them to do additional processing before returning the resource. Finally, the hash symbol introduces the fragment identifier intro. An anchor represents a sort of bookmark inside the resource itself, 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
Keep the host portion of the example unchanged and imagine three variations. The first is https://example.org/notes/first-page with no query and no fragment. The second is https://example.org/notes/second-page?view=compact, which changes only the path. The third is https://example.org/notes/first-page?view=full#summary, which keeps the same path but changes the query value and the fragment. All three share the same domain name, so they would all direct a browser to the same server.
The differences among these three strings lie entirely in the path, query, and fragment portions. A different path points to a different resource on that server. A different query value passes different parameters, which the server may or may not use depending on its own rules. A different fragment tells the browser to scroll to a different bookmark within whatever resource is returned. None of these observations tell you what the server actually does with each variation; they only describe what the string communicates to the browser.
This distinction matters when you are planning your own site. You might assume that changing a query parameter will always produce a visibly different page, but that depends entirely on how the server is configured. Similarly, two URLs that differ only in their fragment will typically load the same resource and then scroll to different positions. Recognizing which parts of a URL affect the request sent to the server and which parts are handled locally by the browser helps you avoid confusion when testing or sharing links.
Building an Address Description Card
Write down a short description card for your hypothetical project before you begin building anything. The card should contain four fields: the purpose of the page, the full address, a breakdown of each component, and a note about anything you find uncertain. For the example used here, the purpose might read “a practice note displayed in a compact reading mode, anchored to the introduction section.” The full address is the string itself. The breakdown lists scheme, domain, path, query, and fragment separately.
Record the purpose in plain language rather than technical jargon. If you later share this card with a collaborator who has no web development background, they should be able to understand what the page is for without needing to parse the URL themselves. This habit pays off when you are writing documentation, filing a bug report, or simply trying to remember why you chose a particular structure months later.
Include a short note about any part you are unsure of. For instance, you might write “I am not certain whether the server ignores the view parameter or uses it to switch layouts.” Flagging uncertainty explicitly prevents you from making assumptions that could cause errors later. The card is a working document, not a final specification, so it is perfectly fine to leave questions open.
Verifying Your Card by Hand
Check your description card against the original string character by character. Copy the full URL into a plain text editor and place a space before each boundary: one space before the ://, one before the first / after the domain, one before the ?, and one before the #. This visual separation makes it easy to see whether your breakdown matches the actual string.
Label each segment directly above or below the spaced-out string. Write “scheme” under https, “domain” under example.org, “path” under /notes/first-page, “query” under view=compact, and “fragment” under intro. If any label does not line up cleanly with a segment, go back and re-examine where you placed the spaces.
Compare your labeled version with the description card you wrote in the previous section. Confirm that the purpose statement still matches what the string actually says. If you discover a mismatch, update the card rather than the string, since the string is the fixed reference point for this exercise. Once everything aligns, save both the spaced-out string and the card in the same file so you can revisit them together.
Step 1
Copy the full hypothetical URL into a plain text editor.
Step 2
Insert spaces before each structural boundary: before ://, before the first path slash, before the question mark, and before the hash symbol.
Step 3
Write a label above each segment identifying it as scheme, domain, path, query, or fragment.
Step 4
Compare the labeled segments against your description card and correct any mismatch on the card.
Keeping Your Notes for Future Work
Store the completed description card somewhere you will naturally encounter it again when you start writing content or configuring your site. A simple text file in your project folder works well, but a note in whatever tool you already use for project planning is equally fine. The goal is not the format but the habit of having a written reference you can check rather than relying on memory.
When you eventually move from the hypothetical example to your real project, repeat the same exercise with your actual address. Write the real URL into the same card format, break it apart, and label each piece. You will likely find that the process takes less time the second round because the structure is already familiar. If your real project uses a different scheme, a subdomain, or additional query parameters, the same labeling approach still applies.
Sharing the card with a collaborator or keeping it in a shared project space can also reduce miscommunication. When someone asks “what does this URL do?” you can point to the breakdown instead of explaining from scratch. Over time, these small records accumulate into a useful reference library for your project, especially if you manage multiple pages or environments.
Frequently asked questions
Is the fragment part of a URL sent to the server?
No. According to MDN, the fragment identifier, which is the part after the hash symbol, is never sent to the server with the request. The browser uses it locally to scroll to the bookmarked position within the returned resource.2
Can a domain name appear without a path in a URL?
Yes. A URL like https://example.org contains a scheme and a domain but no path, query, or fragment. The path and everything after it are optional components. The domain alone is enough to direct the browser to the server.2
Does changing the query string always change what the user sees?
Not necessarily. The query parameters are provided to the web server, and each server has its own rules regarding how it handles them. Whether a different query value produces a visibly different result depends entirely on the server configuration, not on the URL string itself.2