Before you publish a website, you need to understand the difference between a domain name and a full URL. This article uses one hypothetical address to show how each part of a website address works, so you can read, plan, and document your own project addresses with confidence.
What Question Does Each Part Answer?
Suppose you are planning a small personal project and you sketch out a hypothetical address: https://example.org/notes/first-page?view=compact#intro. This address does not point to a real, live page. It is a constructed string we will use only to practice reading the structure of a website address. Before we take it apart, it helps to understand two different questions that this string answers at different levels of specificity.
A domain name answers the question: which server on the Internet should I contact? 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 sequences hard to remember and they can change over time. A domain name like example.org gives you a stable, readable label for the machine you want to reach.1
A full URL answers a more detailed question: which specific resource on that server do I want, and how should I ask for it? A URL 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, and stylesheets. So while the domain name gets you to the right building, the rest of the URL tells you which room to enter and which shelf to look at.2
Reading the Example Address Piece by Piece
Let us now label every visible part of our hypothetical string. The first segment, https, is the scheme. It indicates the protocol the browser must use to request the resource. For websites this is usually HTTPS or its unsecured predecessor HTTP. The next segment, example.org, is the authority. It contains the domain name and tells the browser which web server to contact. In our example there is no port number, which means the browser will use the standard port for HTTPS.2
After the authority comes the path: /notes/first-page. The path points to a specific resource on that server. In the early days of the web, a path like this represented a physical file location, but today it is mostly an abstraction handled by web servers without any physical reality. Following the path, the question mark introduces the query string: view=compact. Parameters are extra key-value pairs provided to the web server, and the web server can use them to do additional processing before returning the resource. Finally, the hash sign introduces the fragment: intro. An anchor represents a sort of bookmark inside the resource itself, giving the browser directions to show the content located at that bookmarked spot.2
Two punctuation marks deserve special attention because they control the boundary between sections. The question mark signals that everything after it belongs to the query string, not to the path. The hash sign signals that everything after it is a fragment identifier, which is never sent to the server with the request. If you misplace either symbol, the browser will interpret the string differently than you intended. For our hypothetical address, the full breakdown is: scheme equals https, authority equals example.org, path equals /notes/first-page, query equals view=compact, and fragment equals intro.2
Comparing Variations While Keeping the Host Fixed
Now keep the scheme and authority exactly the same and change only the path. Imagine a second hypothetical address: https://example.org/notes/second-page?view=compact#intro. The server being contacted is identical, and the query and fragment are identical. The only difference is that the browser is asking for a different resource on that server. This illustrates that the path is the part of the URL that distinguishes one page or file from another on the same host.
Next, keep the path the same but change the query. Consider https://example.org/notes/first-page?view=full#intro. The server, the resource, and the fragment are all unchanged. Only the parameter value differs. This means the same resource is being requested, but with a different instruction attached. What the server actually does with that instruction depends entirely on how it is configured. We cannot infer from the URL string alone whether the server will honor, ignore, or reject a given parameter.
Finally, remove the fragment entirely: https://example.org/notes/first-page?view=compact. The server receives the same request as before because fragments are never sent to the server. The only practical difference is that the browser will not attempt to scroll to a bookmarked position within the returned document. This observation reinforces a useful rule: changes to the fragment affect only what the browser displays after receiving the resource, not what the server returns.
Making an Address Description Card
Write a short description card for any address you plan to use in a project. The card does not need to be elaborate. A plain text note or a row in a spreadsheet works well. The purpose is to capture, in one place, what the address is for, what the full string looks like, and what each part means in the context of your project.
For our hypothetical project, the card might read as follows. Purpose: the landing page for a personal notes section. Full address: https://example.org/notes/first-page?view=compact#intro. Scheme: https, meaning the connection should be encrypted. Authority: example.org, the domain name of the project host. Path: /notes/first-page, pointing to the first page inside the notes directory. Query: view=compact, a display preference parameter. Fragment: intro, a bookmark to the introduction section of that page.
Record the reasoning behind each choice as well. For instance, you might note that you chose the path /notes/first-page because you want a predictable naming pattern for future pages like /notes/second-page. You might note that the query parameter is optional and only affects presentation. These notes become valuable later when you or a collaborator need to understand why a particular address was chosen without having to guess.
Verifying Your Card by Hand
Before you rely on your description card in documentation or communication, verify it against the actual string. The following steps are author suggestions based on ordinary careful practice, not requirements from any external specification.
Check that the punctuation boundaries match your labels. Confirm that the question mark appears exactly where you expect the query to begin, and that the hash sign appears exactly where you expect the fragment to begin. A misplaced symbol is one of the most common sources of address errors in hand-written documentation.
Use a second copy of the address, typed independently rather than pasted, and compare it character by character against your card. If the two match, your card is consistent. If they differ, you have found a transcription error that would otherwise cause confusion later. This simple duplication step catches typos that are easy to overlook when you are reading a string you wrote yourself.
Step 1
Copy the full address string from your card into a blank text field. Do not paste from the original source; retype it by hand so that any unconscious corrections are avoided.
Step 2
Label each segment in the retyped copy: mark where the scheme ends, where the authority ends, where the path ends, where the query begins, and where the fragment begins.
Step 3
Compare your labels against the description card. If every boundary matches, the card is verified. If any boundary differs, correct the card and repeat the check.
Keeping Your Record for Future Use
Once your card is verified, store it somewhere you will actually look at it again. A project README file, a shared note, or a simple spreadsheet row all work. The format matters less than the habit of keeping the record current. If you later change the path structure or add new parameters, update the card at the same time so it does not drift out of sync with reality.
This record serves two audiences. The first is your future self. When you return to a project after weeks or months, a clear address card saves you from re-deriving what each part of a URL means in context. The second audience is any collaborator or helper you might ask for assistance. Sharing a labeled breakdown is far more efficient than pasting a raw string and asking someone to figure out what you intended.
You do not need to document every possible variation of an address. Focus on the addresses that matter for your project's public entry points, internal navigation, or any place where a parameter changes the visible result. The goal is a small, trustworthy reference that you can consult quickly, not an exhaustive catalog of every string your server could theoretically handle.
Frequently asked questions
Is the fragment part of a URL sent to the web 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 only by the browser to locate a position within the already-retrieved resource.2
Can I change the query string without affecting which page is loaded?
The query string provides extra parameters to the server, but whether those parameters change the returned content depends entirely on how the server is configured. The path is what identifies the resource; the query gives additional instructions that the server may or may not act on.2
What is the difference between a domain name and a full URL?
A domain name identifies which server to contact. A full URL includes the domain name plus additional parts such as the scheme, path, query, and fragment, and it identifies a specific resource on that server along with how to request it.12