When you prepare a website for the first time, two terms appear constantly: domain name and URL. They are closely related but answer different questions. This article uses one hypothetical address to show how each part of the string works and how you can record it clearly.
What Domain Names and Full URLs Each Answer
Suppose you are planning a small personal project site and want to understand the address you will eventually share with visitors. A domain name is a human-readable address for a web server available on the Internet. Computers reach servers through numeric IP addresses, but people find those difficult to remember and they may change over time, so domain names solve that problem by giving each server a name that humans can read and recall.1
A URL is the address of a unique resource on the internet. While a domain name identifies the server itself, a URL goes further and specifies exactly which resource on that server you want. That resource might be a particular page, an image, or a stylesheet. In theory, each valid URL points to a unique resource.2
For a first-time site builder, the practical distinction is straightforward: the domain name answers the question “which site?” and the full URL answers “which specific thing on that site?” Knowing this difference helps you plan your pages, describe your address to others, and troubleshoot when something does not load as expected.12
Labeling Each Part of Our Example Address
To make these definitions concrete, we will work through a single hypothetical address: https://example.org/notes/first-page?view=compact#intro — This address does not point to a real page and has not been published anywhere. It exists solely so we can label its parts and practice reading a URL string.2
Reading from left to right, the scheme is https, which indicates the protocol the browser must use to request the resource. The domain, or host, is example.org, identifying the web server. The path is /notes/first-page, pointing to a specific resource on that server. The query string begins with the question mark: ?view=compact provides extra parameters. The fragment begins with the hash sign: #intro acts as a bookmark within the resource itself, giving the browser directions to show content at that spot.2
Two punctuation marks serve as reliable boundaries. The question mark always introduces the query portion of a URL, and the hash sign always introduces the fragment. Everything between the question mark and the hash sign belongs to the query; everything after the hash sign is the fragment. If either the query or the fragment is absent, the corresponding punctuation mark simply does not appear.2
Same Host, Different Paths and Queries
Now keep the host part fixed as example.org and change only the path. If the path were /notes/second-page instead of /notes/first-page, the URL string would point to a different location within the same server’s structure. The domain has not changed at all; only the portion after the domain differs. This shows that the path is what distinguishes one resource from another on the same site.
You can also change the query string while keeping everything else identical. Replacing view=compact with view=full produces a different URL string. Here we are observing how the text changes, not making claims about what any particular server would actually do with these parameters. Each web server has its own rules for handling parameters, and the only reliable way to know whether a specific server is handling them is by asking the server owner.
Finally, you can remove the fragment entirely. Without #intro, the URL still points to the same resource on the server because the fragment is never sent to the server with the request. It only tells the browser where to scroll within the document once it arrives. This observation comes from reading the string structure, not from testing any live server.
Building an Address Description Card
Record the purpose of your hypothetical project in one sentence at the top of a note or document. For our exercise, the purpose might be: “A simple notes page with a compact reading view.” Writing this first gives anyone who reads the card later an immediate sense of context without needing to reverse-engineer the address.
Write the full address on the next line: https://example.org/notes/first-page?view=compact#intro — Then list each labeled part below it: scheme (https), host (example.org), path (/notes/first-page), query (view=compact), and fragment (intro). This breakdown separates the whole string into understandable pieces and makes it easier to spot errors if you ever need to type the address manually.
Adding a short note about which parts you chose deliberately and which are placeholders helps your future self. For instance, you might write that “example.org is a placeholder host” or that “view=compact is the default display mode I plan to use.” These annotations turn a raw string into a small piece of project documentation that you can revisit months later without confusion.
Verifying the Card by Hand
Check your description card against the original address character by character. Copy the full URL into a plain text editor, then place a space or line break before each punctuation boundary: before the first slash pair after the scheme, before the first single slash of the path, before the question mark, and before the hash sign. This visual separation makes it obvious whether any part is missing or misplaced.
Label each segment directly in your text editor by adding a comment or a parenthetical note beside it. For example, write “scheme” next to https, “host” next to example.org, and so on. If a segment does not match one of the five parts you expect, you may have a typo or an extra character that needs attention.
Use this verification step each time you add a new page address to your project notes. The habit takes only a moment, but it catches common mistakes such as a missing slash between the host and the path, a question mark placed after the fragment, or a fragment identifier that was accidentally included in the query string.
Keeping the Record for Future Use
Store your address description card somewhere you will naturally look when writing content or explaining your project to a collaborator. A simple text file inside your project folder works well because it travels with the rest of your notes and does not depend on any particular tool or service.
You do not need to update this card every time you add a new page. Its main value is that it captures the structural logic of your address in one place. When you eventually add more pages, you can extend the card with additional rows following the same format: purpose, full address, and labeled parts.
This approach is a personal organizational choice rather than a technical requirement. Some people prefer to keep address notes in a spreadsheet, others in a wiki page, and others simply rely on their browser history. The key point is that having a written breakdown of your URL’s parts makes communication clearer and reduces the chance of sharing a broken or incomplete address.
Frequently asked questions
Is a domain name the same thing as a URL?
No. A domain name identifies the web server, while a full URL identifies a specific resource on that server. The domain is one component within the larger URL string.12
What does the question mark in a URL indicate?
The question mark introduces the query portion of a URL. Everything between the question mark and the hash sign (or the end of the string if there is no fragment) consists of key-value parameters provided to the web server.2
Does the fragment after the hash sign get sent to the server?
No. The fragment identifier is never sent to the server with the request. It only tells the browser where to scroll or jump within the document after the resource has been loaded.2