Before you publish your first website, you will need to share its address with others. That address is a URL, and understanding how its parts work helps you describe your site accurately and spot simple mistakes on your own.
What question does a domain name answer, and what question does a full URL answer
When you prepare a new website, the first address-related term you will encounter is the domain name. 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 reach servers through numeric IP addresses, but people find those numbers hard to remember, and the numbers can change over time. A domain name solves that problem by giving the server a readable label such as example.org.1
A URL goes further. A URL, short for Uniform Resource Locator, is the address of a unique resource on the internet. It is one of the key mechanisms used by browsers to retrieve published resources such as HTML pages, images, or documents. Where a domain name identifies the server, a URL identifies a specific resource on that server. Think of it this way: the domain name tells you the building, and the full URL tells you the exact room inside that building.2
This distinction matters before launch because you will often need to share a specific page address, not just your domain. If you only give someone your domain name, they will land on your homepage. If you want them to see a particular article or settings page, you need the complete URL. Recognizing which part of an address does what gives you a practical foundation for the rest of this article.
Reading the example address part by part
To make these ideas concrete, we will use a hypothetical address for the rest of this article: https://example.org/notes/first-page?view=compact#intro. This address is constructed purely for the purpose of breaking down a string into its components. It does not point to a real page, and you should not expect it to load in a browser.
The first part, https, is the scheme. It indicates the protocol that the browser must use to request the resource. For websites the protocol is usually HTTPS or its unsecured version HTTP. The scheme tells the browser how to communicate with the server before any content is fetched. The next part, example.org, is the domain name within the authority section. It identifies which web server is being requested. The authority is separated from the scheme by the character pattern ://.2
After the domain comes the path, which in our example is /notes/first-page. The path points to a resource on the web server. Following the path, the question mark introduces the query string. In our example, view=compact is a parameter provided to the web server as a key-value pair. The web server can use parameters to do extra processing before returning the resource. Finally, the hash sign introduces the fragment identifier, which in our example is intro. An anchor represents a sort of bookmark inside the resource, giving the browser directions to show content located at that bookmarked spot. The fragment is never sent to the server with the request.2
Same host, different paths and queries
Now that each part has a label, we can see how changing one part while keeping the rest the same produces a different address string. Keep the scheme and domain exactly as they are: https://example.org. Change only the path from /notes/first-page to /notes/second-page. The result is a different URL string that points to a different location on the same server, at least as far as the address is concerned. We are observing the string structure here, not making claims about what the server actually returns.
Next, keep the path the same but change the query string. Replace view=compact with view=full. The address becomes https://example.org/notes/first-page?view=full. The domain and path are identical to the original, but the query parameter carries a different value. Again, we are only noting that the strings differ; whether the server treats them differently depends on how that server is configured, which is outside the scope of reading an address.
You can also remove the query and fragment entirely. The address https://example.org/notes/first-page is still a valid URL. The query and fragment are optional parts. This observation is useful when you are comparing addresses in your own notes: two URLs that share the same domain and path but differ only in query or fragment are pointing to the same resource location with potentially different presentation or scroll position. Noticing these differences in the string itself is the skill this exercise builds.
Making an address card for your hypothetical project
Record the purpose, full address, and each labeled part of your hypothetical URL on a single card or note. For our example, the purpose might be “a practice page for learning URL structure.” The full address is https://example.org/notes/first-page?view=compact#intro. Below it, list the scheme as https, the domain as example.org, the path as /notes/first-page, the query as view=compact, and the fragment as intro. Having everything in one place makes it easy to spot a missing part later.
Write a one-line note explaining why you chose each part. For instance, you might write that the path /notes/first-page was chosen because the hypothetical project organizes content under a notes folder. The query view=compact was included to show how a parameter appears in the string. These brief reasons are not technical requirements; they are memory aids that help you recall your own decisions when you revisit the card weeks later.
If your project eventually has more than one address, make a separate card for each. Keeping them in a consistent format means you can compare two addresses side by side and quickly see which parts differ. This habit is especially useful when you are drafting links for a newsletter, a README file, or a message to a collaborator, because you can copy the exact string rather than reconstructing it from memory.
Verifying your address card by hand
Manual verification is a simple way to catch typos before you share an address publicly. The steps below are author suggestions based on the labeling exercise above, not requirements from any specification.
After you finish labeling, read the full address on your card from left to right one more time. Confirm that the scheme, domain, path, query, and fragment appear in that order and that the separators match what you expect: :// between scheme and authority, a question mark before the query, and a hash sign before the fragment. If anything looks out of place, correct it on the card and re-read. This final pass takes only a moment but often catches a misplaced slash or a missing question mark.
Check your card against any message or document where you plan to paste the address. If you are writing a link inside an HTML document, remember that the HTML language uses URLs extensively, for example to create links with the a element or to display images with the img element. Pasting the verified string from your card reduces the chance of introducing a typo during that step.2
Step 1
Open your address card and copy the full URL string into a plain-text editor or a blank note. Do not retype it from memory; use copy and paste so that no accidental character changes slip in.
Step 2
Starting from the left, mark each part with a label. Write “scheme” next to https, “domain” next to example.org, “path” next to /notes/first-page, “query” next to view=compact, and “fragment” next to intro. Use a different color or bracket style for each label if that helps you see the boundaries.
Keeping the record for future use
Once your address card is verified, store it somewhere you will actually look again. A plain-text file in your project folder, a note in your preferred note-taking app, or even a comment at the top of a configuration file all work. The format matters less than the habit of returning to it. When you later write documentation, share a link in an email, or debug a broken link, having the labeled breakdown saves you from re-analyzing the string from scratch.
You may find that your recording preferences change as your project grows. Early on, a single card with one address is enough. Later, you might add columns for the page title, the date you last checked the link, or the context where you shared it. These are organizational choices, not technical rules. The important point is that the card remains a reference you trust because you built it deliberately and verified it by hand.
If you collaborate with others, consider sharing your address card format so everyone labels parts the same way. Consistent labeling makes it easier to discuss a specific segment of a URL without ambiguity. For example, saying “the query parameter on the notes page” is clearer than saying “the part after the question mark thing.” A shared vocabulary built on a simple card can prevent small misunderstandings from turning into wasted troubleshooting time.
Frequently asked questions
Is the fragment part of a URL sent to the server?
No. The fragment identifier, which is the part after the hash sign, is never sent to the server with the request. It is used by the browser to scroll to a bookmarked spot within the resource itself.2
Can a URL be valid without a query string or fragment?
Yes. The query and fragment are optional parts of a URL. An address like https://example.org/notes/first-page is complete and valid without either of them.2
What is the difference between a domain name and a full URL?
A domain name identifies a web server with a human-readable label. A full URL includes the domain name plus additional parts such as the scheme, path, and optional query or fragment, and it points to a specific resource on that server.12