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 about an address. This article uses one clearly marked hypothetical address to show how each part of a web address works, so you can read and record your own addresses with confidence before launch.
What Questions Do Domain Names and URLs Each Answer?
Consider the following address: https://example.org/notes/first-page?view=compact#intro. This is a hypothetical string created purely for dissection in this article. It does not point to a real page, and no server is expected to respond to it. We will use it only to practice reading the structure of a web address, which is the same skill you will need when working with your own project.
A domain name answers the question “which server 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 numeric IP addresses, but people find those numbers hard to remember and they may change over time. A domain name solves that problem by giving a stable, readable label to a server.1
A URL answers a broader question: “which specific resource on that server do I want?” A URL (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, CSS documents, and images. The domain name is one component inside a URL, but the URL also includes a scheme, a path, and optionally a query string and a fragment. In our example, example.org is the domain name, while the entire string from https to #intro is the URL.2
Reading the Example Address Part by Part
The first part of our example is https. This is the scheme, which indicates the protocol that the browser must use to request the resource. For websites the protocol is usually HTTPS or HTTP. The scheme tells the browser how to communicate with the server, and it is always followed by the characters :// which separate it from the next part of the address.2
After the scheme comes the domain: example.org. In a domain name, the parts are separated by dots and read from right to left. The rightmost part, org, is the top-level domain (TLD), which tells users the general purpose of the service behind the domain name. The label to its left, example, is the second-level domain. Together they form the host portion of our URL, identifying which web server is being requested.12
Following the domain is the path: /notes/first-page. The path represents the location of a resource on the web server. In the early days of the web, a path like this represented a physical file location, but nowadays it is mostly an abstraction handled by web servers without any physical reality. For our reading exercise, we simply note that the path narrows down which resource on the server we are pointing to.2
Query Strings and Fragments: What the Question Mark and Hash Sign Do
After the path in our example comes ?view=compact. The question mark signals the start of the query string. Query parameters are extra parameters provided to the web server, formatted as a list of key/value pairs separated by the ampersand symbol. Here there is only one pair: the key is view and the value is compact. The web server can use those parameters to do extra processing before returning the resource.2
The final part is #intro. The hash sign, also called the number sign, introduces the fragment identifier. 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 sign is never sent to the server with the request; it is used only by the browser to position the view within the already-loaded document.2
Summarizing the punctuation rules for our example: the question mark always introduces the query section, and the hash sign always introduces the fragment. These two characters serve as clear boundaries when you read any URL. If you see a question mark, everything after it up to a hash sign (or the end of the string) belongs to the query. If you see a hash sign, everything after it is the fragment.2
Same Host, Different Paths and Queries
Now keep the host portion fixed at example.org and imagine two different addresses: https://example.org/notes/first-page?view=compact#intro and https://example.org/gallery/summer?sort=date. The domain and scheme are identical in both, but the paths differ. The first points to a path called /notes/first-page while the second points to /gallery/summer. From the string alone, we can observe that these are different resource locations within the same domain. We cannot determine from the string what content each path actually serves; that depends entirely on how the server is configured.2
The query strings also differ. The first uses view=compact and the second uses sort=date. Each web server has its own rules regarding parameters, and the only reliable way to know if a specific web server is handling parameters is by asking the web server owner. This means that when you read a URL belonging to someone else’s site, you can identify the query section and its key-value structure, but you cannot assume what effect those parameters have without additional information from the site owner.2
This observation leads to a practical habit: when you encounter an unfamiliar address, you can label its parts confidently, but you should avoid guessing what the server does with them. The structure tells you where boundaries are and what type of information each section carries. The behavior behind those sections is a separate question that only the server’s configuration can answer.
Making an Address Description Card
Record a short description card for any address you plan to use or share. For our hypothetical project, the card might contain four fields: purpose, full address, host, and path with query. The purpose field states in plain language what the page is for, such as “a compact reading view of the first notes page.” The full address field holds the complete URL exactly as you intend to write it. The host field isolates the domain. The path and query field lists everything after the domain.
Writing these fields down serves two goals. First, it forces you to identify each part of the address rather than treating the whole string as an opaque block. Second, it gives you a reference you can share with collaborators or revisit later when you need to update links, write documentation, or troubleshoot a broken address. The format of the card is up to you; a simple text file, a spreadsheet row, or a note in your project management tool all work equally well.
Choose the level of detail that matches your project size. A single-page personal site might only need one card. A project with multiple sections, filter views, or anchored subsections will benefit from one card per distinct address you expect to share or link to. The important thing is consistency: once you pick a format, use it for every address in the project so that future you can scan the list quickly.
Verifying Your Card by Hand
Manual verification is a simple habit that catches typos, missing slashes, and misplaced punctuation before they cause confusion. The process does not require any special tool; a text editor and a few minutes of attention are enough.
Check the punctuation boundaries after labeling each segment. Confirm that the question mark appears exactly once and comes after the path, and that the hash sign, if present, comes after the query. A misplaced question mark or an extra slash can change the meaning of the address or produce an error when someone tries to use it.
Repeat this check any time you edit the address or copy it into a new context such as a link in your content, a social media profile, or a README file. Each copy is an opportunity for a small error to creep in, so treating verification as a routine step rather than a one-time task keeps your addresses reliable.
Step 1
Copy the full URL from your description card and paste it into a plain text editor. Do not rely on a browser address bar for this step, because browsers may auto-complete or hide parts of the string.
Step 2
Label each segment directly in the text. Write “scheme” above https, “host” above example.org, “path” above /notes/first-page, “query” above view=compact, and “fragment” above intro. Use a new line or a comment character to keep labels visually separate from the address itself.
Step 3
Compare your labeled version against the card fields one by one. If every field matches, the card is accurate. If any field differs, correct the card and repeat the labeling step until they agree.
Frequently asked questions
Is the fragment part of a URL sent to the web server?
No. The fragment identifier, which is everything after the hash sign, is never sent to the server with the request. It is used only by the browser to scroll or jump to a specific spot within the already-loaded document.2
Can I tell what a query parameter does just by reading the URL?
You can identify the key and value of each parameter from the string, but you cannot determine what effect they have on the server’s behavior. Each web server has its own rules regarding parameters, and the only reliable way to know how they are handled is by asking the web server owner.2
Do I need a description card for every URL in my project?
That depends on the size of your project. A single-page site may need only one card, while a project with multiple sections or filter views benefits from one card per distinct address you plan to share or link to. The key is consistency so that you can scan your list quickly later.