Before a personal website or small project goes live, you will need to understand the difference between a domain name and a full URL. This article uses one hypothetical address to walk through each component step by step, so you can read, label, and record web addresses with confidence.
What Question Does Each Part Answer?
Suppose you are planning a small note-taking project and you want to give it a web address. For this exercise we will use the hypothetical address https://example.org/notes/first-page?view=compact#intro. This page does not exist and has never been published; it is a string we constructed purely to practice reading addresses. Looking at it, you can already see that it contains more information than just a name.
A domain name answers one specific question: which server on the Internet should be contacted? Domain names provide a human-readable address for any web server available on the Internet, because people have a hard time remembering numeric IP addresses and those addresses might change over time. In our example, the domain name is example.org. It tells a browser where to send the request, but it says nothing about which particular resource on that server you want.1
A full URL answers a broader question: which unique resource should be retrieved, 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, images, and documents. Our example string is a full URL because it specifies not only the server but also a particular path, a query parameter, and a fragment. Each additional part narrows the request further.2
Labeling Every Part of the Example Address
Let us break the hypothetical string into its components. The scheme is https, which indicates the protocol the browser must use to request the resource. The scheme is always followed by the separator pattern of a colon and two slashes. After the separator comes the authority section, which in our example contains only the domain name example.org. No port number is written because standard HTTPS uses its default port, so the port can be omitted.2
Following the domain comes 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 represented a physical file location, but nowadays it is mostly an abstraction handled by web servers without any physical reality. After the path comes a question mark, which introduces the query string. In our example the query is view=compact. Query parameters are extra key-and-value pairs provided to the web server, and the question mark is the character that signals their start.2
Finally, the hash symbol introduces the fragment. In our example the fragment is 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 leads into the query, and the hash leads into the fragment. These two delimiters are easy to confuse at first, but remembering that question mark comes before hash in the string order helps keep them straight.2
Same Host, Different Paths and Queries
Now keep the host portion fixed at example.org and change only the path. Consider https://example.org/notes/second-page and https://example.org/about/team. Both strings share the same domain name, so they point to the same server. The difference lies entirely in the path segment, which tells the server which resource is being requested. From the string alone you can observe that these are different addresses; whether the server actually serves different content at each path is a question only the server operator can answer.2
Next, keep both the host and the path the same but change the query string. Compare https://example.org/notes/first-page?view=compact with https://example.org/notes/first-page?view=full. The path is identical in both cases, so the resource being requested is the same page. The query parameter differs: one asks for a compact view and the other for a full view. How the server responds to that parameter depends on its own rules. 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.2
This exercise shows that changing one segment of the string produces a different URL, even when the domain name stays the same. The domain identifies the server; the path, query, and fragment each add layers of specificity. When you are planning your own site, noticing these layers helps you understand why two links that look similar might point to different resources, and why a small typo in the path or query can lead somewhere unexpected.
Building an Address Description Card
Record the purpose of your hypothetical project in one sentence. For our note-taking example, the purpose might be: a personal page for collecting reading notes. Write this sentence at the top of your card. Below it, write the full address exactly as you intend it to appear: https://example.org/notes/first-page?view=compact#intro. Keeping the full string in one place prevents accidental truncation or reordering when you later copy it into configuration files or documentation.
Below the full address, list each part on its own line with a label. Scheme: https. Domain: example.org. Path: /notes/first-page. Query: view=compact. Fragment: intro. This line-by-line breakdown makes it easy to spot which segment you would need to change if, for example, you wanted to point to a different page or adjust the display mode. The card is a simple reference you can revisit whenever you need to explain the address to a collaborator or paste it into a new tool.
If your project will eventually have more than one page, you can extend the card with additional rows. Each row would share the same domain but carry a different path or query. Building the card early, even while the project is still hypothetical, gives you a habit of treating addresses as structured strings rather than opaque blocks of text. That habit pays off when you start debugging links or writing documentation.
Verifying the Card by Hand
Once your description card is written, verify it by copying the full address from the card into a plain text editor and labeling each segment manually. This step catches transcription errors that are invisible when you read the address as a whole.
After labeling, compare your manual breakdown against the card line by line. If every segment matches in spelling, order, and delimiter placement, the card is consistent. If anything differs, correct the card before you rely on it for any configuration or communication.
Repeat this check any time you edit the address, add a new page, or change a query parameter. The process takes only a moment, but it builds confidence that the string you share or configure is exactly the one you intended.
Step 1
Copy the full URL from your description card and paste it into a blank line in a plain text editor.
Step 2
Insert a space or line break before each delimiter: after the scheme separator, before the first slash of the path, before the question mark, and before the hash symbol.
Step 3
Write the label for each segment next to it: scheme, domain, path, query, fragment.
Step 4
Compare the labeled segments against the lines on your description card. Confirm that every character matches, including slashes, the question mark, and the hash symbol.
Keeping the Record for Future Use
Store your address description card in a place you will actually revisit, such as a project README file or a dedicated notes document. The value of the card is not in creating it once but in having a reliable reference when you need to explain the address structure to someone else, update a link, or troubleshoot a broken URL. Because the card separates each component, you can quickly identify which part changed without re-reading the entire string character by character.
When your project grows beyond a single page, add new entries to the same card or create a small table. Each entry should repeat the domain, list its unique path, and note any query parameters or fragments it uses. This keeps all your addresses in one view and makes it obvious when two pages accidentally share the same path or when a query parameter has been misspelled.
The choice of format is yours. Some people prefer a simple list; others use a table with columns for purpose, full address, and each part. What matters is consistency: pick one format and stick with it so that future-you can scan the record without relearning the layout. The hypothetical example in this article used a flat list because it had only one address, but a table scales better as pages multiply.
Frequently asked questions
Is the fragment part of a URL sent to the server?
No. The part after the hash symbol, known as the fragment identifier, is never sent to the server with the request. It is used by the browser to locate a specific spot within the already-retrieved resource.2
Can I use the same domain name with different paths to point to different pages?
Yes. The domain name identifies the server, and the path specifies which resource on that server is being requested. Different paths under the same domain can point to different pages, though how the server handles each path is determined by the server owner.2
What is the difference between a domain name and a URL?
A domain name identifies a web server using a human-readable address. A URL is a complete address that includes the domain name plus additional parts such as the scheme, path, query, and fragment, specifying exactly which resource to retrieve.12