When you prepare a personal website or a small project site, you will encounter two related but distinct concepts: the domain name and the full URL. Understanding what each one tells you, and how the parts of a URL fit together, helps you read, write, and communicate web addresses with confidence before launch.12
What Questions Do a Domain Name and a Full URL Each Answer?
Suppose you are planning a small notes site and you write down the address https://example.org/notes/first-page?view=compact#intro as a working example. This address is entirely hypothetical; it exists only so we can take it apart and look at each piece. Before dissecting it, it helps to understand the two different questions that a domain name and a full URL each answer.
A domain name answers the question “which server or site am I looking for?” Domain names provide a human-readable address for any web server available on the internet. Computers locate servers using IP addresses, which are numeric and difficult for people to remember, so domain names serve as a memorable substitute. In our example, example.org is the domain name. It points to a particular server without specifying any particular page or file on that server.1
A full URL answers a more specific question: “which exact resource on that server do I want?” A URL is the address of a unique resource on the internet, and it is one of the key mechanisms browsers use to retrieve published resources such as HTML pages, images, or stylesheets. The full string https://example.org/notes/first-page?view=compact#intro does more than name the server; it also describes a path, a query, and a fragment that narrow down what the browser should request.2
Labeling Each Part of the Example Address
Let us walk through the example address from left to right. The first segment, https, is the scheme. It tells the browser which protocol to use when requesting the resource. For websites, the scheme is typically HTTPS or its unsecured version HTTP. After the scheme comes the authority section, separated by the characters ://. In our example, the authority is simply example.org, which is the domain name identifying the web server.2
Following the domain is the path: /notes/first-page. The path represents the location of the resource on the web server. In the early days of the web, a path like this corresponded to a physical file location, but nowadays it is mostly an abstraction handled by web servers without any physical reality. After the path comes the query string, introduced by a question mark: ?view=compact. Parameters are extra key-value pairs provided to the web server, and the question mark is the character that signals the start of this section.2
Finally, the hash symbol introduces the fragment: #intro. 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 part after the hash, also known as the fragment identifier, is never sent to the server with the request. So in summary, the question mark guides the query and the hash symbol guides the fragment; each marks a distinct boundary in the address string.2
Same Host, Different Paths and Queries
Now keep the host portion of our example fixed at example.org and change only the path and query. Consider https://example.org/notes/second-page?view=full. The domain name has not changed, so the browser still targets the same server. What differs is the path, which now points to a different location label, and the query value, which reads full instead of compact. These are purely string-level observations; we are not claiming anything about how a particular server would respond to each variation.
Consider another variation: https://example.org/archive/2024?sort=date. Here the path has shifted to a completely different directory label, and the query key itself has changed from view to sort. The domain remains the same anchor point. This illustrates that the domain name stays constant as a reference to the server, while paths and queries can vary widely to describe different resources or different instructions for the same server. Each combination of path and query produces a distinct URL string.
You can also remove the query entirely. The address https://example.org/notes/first-page contains a scheme, a domain, and a path but no question mark and no parameters. The fragment can likewise be dropped. These optional parts do not change which server is being addressed; they refine what is requested from that server. Recognizing which parts are fixed and which parts vary is a useful habit when you plan the structure of your own site.
Building an Address Description Card
Record the purpose of your hypothetical project in one sentence at the top of a card or note file. For instance, you might write: “This is a personal notes site for collecting short writing drafts.” This sentence reminds you why the address exists and what it is meant to serve. Keeping the purpose next to the address prevents confusion later if you manage more than one project.
Write the full address on the next line: https://example.org/notes/first-page?view=compact#intro. Below it, list each part with a short label. Scheme: https. Domain: example.org. Path: /notes/first-page. Query: view=compact. Fragment: intro. This breakdown makes it easy to see at a glance which portion of the string serves which role.
Add a final line noting any choices you made deliberately. For example, you might note that you chose the path segment notes because it matches the folder name you plan to use in your project files, or that you selected compact as the default view because it suits your reading preference. These are your own decisions, not rules imposed by any standard, and recording them helps you explain your address to collaborators or to your future self.
Verifying the Card by Hand
Once your description card is written, verify it by copying the full address into a plain text editor. This manual step catches typos that your eye might skip over when reading from a formatted document. Paste the address on its own line so nothing else competes for your attention.
Work through each segment one at a time. Start from the left and confirm the scheme matches what you recorded. Then check the domain, the path, the query, and the fragment in order. If any segment does not match your card, correct the card or the address before moving on.
After all segments check out, read the full address aloud or share it with a colleague. Hearing or seeing it in a fresh context often reveals small errors such as a missing slash or a swapped character. This final read-through is a simple quality habit that costs almost nothing and prevents embarrassing mistakes in published links.
Step 1
Copy the full address from your description card into a plain text editor, placing it on its own line with no surrounding text.
Step 2
Starting from the left, underline or highlight each segment in sequence: scheme, domain, path, query, and fragment. Compare each highlighted segment against the label on your card.
Step 3
If every segment matches, read the complete address aloud once. If any segment differs, correct the mismatch and repeat the check from the beginning.
Keeping Your Description for Later Use
Store your completed description card somewhere you will naturally revisit, such as a project readme file, a shared document, or a dedicated notes folder. The goal is not to follow a particular tool recommendation but simply to keep the information close to the context where you will need it. If you later write documentation, share the address with a designer, or debug a link, having the breakdown already written saves you from re-deriving it each time.
You may find that your recording choices evolve as the project grows. Perhaps you add more pages and want to note a naming pattern for paths, or you introduce new query parameters and want to document what each one controls. Updating the card as you go keeps it accurate without requiring a large rewrite at the end.
The practice of writing down what each part of an address means is not limited to this one example. Any time you encounter an unfamiliar URL, you can apply the same breakdown: identify the scheme, the domain, the path, and any query or fragment. Over time this becomes a quick mental habit, but having a written reference for your own project addresses remains valuable because it captures your specific decisions and reasoning, not just the generic structure.
Frequently asked questions
In the example address, what is the difference between the query and the fragment?
The query, introduced by a question mark, provides extra key-value parameters to the web server. The fragment, introduced by a hash symbol, acts as a bookmark within the resource itself and is never sent to the server with the request.2
If I change only the path but keep the domain the same, am I pointing to a different server?
No. The domain identifies the server. Changing the path, query, or fragment produces a different URL that targets a different resource or instruction on the same server, but the server itself remains the one identified by the domain name.12
Do I need to include the fragment when I share my page address with someone?
Not necessarily. The fragment directs the browser to a specific spot within the page. If you want someone to land at a particular section, include it. If you simply want them to reach the page, the address without the fragment is sufficient.2