When you prepare a website for the first time, the address bar string can look like one undifferentiated block of characters. This article uses a single hypothetical address to separate the domain name from the full URL, label every visible part, and build a small reference card you can reuse later.
What a Domain Name and a Full URL Each Tell You
Suppose you are planning a small personal project and you want to give it a public address. You might start by choosing a domain name, such as example.org. A domain name provides a human-readable address for a web server available on the Internet. Computers locate servers through numeric IP addresses, but people find those sequences difficult to remember and hard to associate with a particular site or service. Domain names solve that problem by offering a readable label that stays stable even when the underlying IP address changes.1
A full URL answers a different question. Where the domain name identifies the server, the URL points to one specific resource on that server. A URL is the address of a unique resource on the internet and is one of the key mechanisms browsers use to retrieve published resources such as HTML pages, images, or stylesheets. In theory each valid URL points to a unique resource, so two URLs that differ in any part can lead to different content.2
For this exercise we will work with one hypothetical address: https://example.org/notes/first-page?view=compact#intro. This string is invented purely for the purpose of taking apart its components. It does not claim to point to a real page or a live server. Everything below treats it as a reading exercise so you can see how each segment contributes to the whole.
Reading the Example Address Part by Part
The first segment, https, is the scheme. It indicates the protocol the browser must use to request the resource. For websites the protocol is usually HTTPS or its unsecured version HTTP. In our example the scheme tells the browser to use a secure connection when reaching the server.2
The next segment, example.org, is the domain name sitting inside the authority portion of the URL. The authority is separated from the scheme by the character pattern ://. Within the authority, the domain indicates which web server is being requested. The structure of a domain name is read from right to left: the rightmost part is the top-level domain, here org, which tells users the general purpose of the service. The label to its left, example, is the second-level domain that you would choose when registering. Together these labels form the host that identifies the server.12
After the domain comes 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 corresponded to a physical file location, but nowadays it is mostly an abstraction handled by web servers without any physical reality. In our hypothetical string, /notes/first-page simply tells us which resource on example.org we are asking for.2
Comparing Paths and Queries on the Same Host
The question mark in our example introduces the query string. Everything after ? and before any # sign is a set of parameters provided to the web server. In https://example.org/notes/first-page?view=compact the parameter is view=compact, a key-value pair that the server can use to adjust what it returns. Each web server has its own rules regarding parameters, and the only reliable way to know whether a specific server is handling parameters is by asking the server owner.2
The hash sign introduces the fragment, also called the anchor. In our example, #intro is 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 # is never sent to the server with the request, which means the fragment only affects what the browser displays locally.2
Now keep the host part, example.org, fixed and imagine two variations. The first is https://example.org/notes/second-page?view=full#summary. The second is https://example.org/about?view=compact. Both share the same domain and scheme, but their paths differ, and the first carries both a query and a fragment while the second carries only a query. Observing the string alone tells you these are distinct resources; it does not tell you what the server actually does with them. That distinction matters because the structure of the address is something you can read and record, while server behavior depends on configuration you may not control.
Building an Address Description Card
Record the purpose of your hypothetical project in one sentence. For instance, you might write: “A personal notes page with a compact reading view.” This sentence is not a technical requirement; it simply gives future-you a reason to remember why this address exists.
Write the full address on the next line of your card: 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 mirrors the structure you observed in the previous sections and gives you a quick reference without needing to re-read the entire string every time.
Add a final line noting what the card does not tell you. It does not confirm that the page exists, that the server responds, or that the query parameter changes anything visible. The card is a reading aid, not a test result. Keeping that boundary clear helps you avoid assuming that a well-formed address guarantees a working page.
Verifying Your Card by Hand
Once your card is written, a short manual check can catch transcription errors before you share the address with anyone or paste it into a link.
These steps are author suggestions for building a personal habit of accuracy. They do not come from any external specification and you can adapt them to whatever tool you prefer, whether that is a plain text file, a notebook, or a spreadsheet cell.
If any label disagrees with the original string, correct the card and repeat the comparison from the beginning. The goal is not speed but confidence that every character you recorded matches the source you intend to reference.
Step 1
Copy the full address from your card into a blank text editor. Do not retype it from memory; use copy and paste so that the string you are checking is exactly what you wrote.
Step 2
Starting from the left, mark each boundary character: the colon and double slash after the scheme, the first slash that begins the path, the question mark that begins the query, and the hash sign that begins the fragment. Write the label next to each segment.
Step 3
Compare your labeled segments against the card entries one by one. Check the scheme spelling, the domain spelling including the dot before the TLD, each path segment, the parameter key and value, and the fragment identifier.
Keeping Your Record for Future Use
Store the finished card somewhere you will actually look when you next write content, share a link, or explain your project to a collaborator. A plain text file inside your project folder works well because it travels with the rest of your files and does not depend on any particular application.
When you later add more pages to the same project, you can extend the card with additional lines. Each new address gets its own entry with the same set of labels. Over time the card becomes a small map of your site's address space, and you can spot inconsistencies such as a page that uses a different query convention or a fragment name that does not follow your chosen pattern.
The value of this practice is not in the format itself but in the habit of writing down what you chose and why. If you later decide to rename a path segment or drop a query parameter, the card gives you a before-and-after record. You do not need any special software or a particular notation; the only requirement is that the record is clear enough for you to read weeks later without re-deriving every decision from scratch.
Frequently asked questions
Is the fragment part of the URL sent to the server?
No. The part after the hash sign, also called the fragment identifier, is never sent to the server with the request. It only tells the browser where to scroll or jump within the already-loaded resource.2
Can two URLs with the same domain point to different resources?
Yes. In theory each valid URL points to a unique resource, so changing the path, query parameters, or both produces a different address even when the domain stays the same.2
Do I need to know every URL rule before launching a simple site?
No. There are extra parts and rules regarding URLs, but they are not relevant for regular users or web developers building fully functional sites. Understanding the scheme, domain, path, query, and fragment covers the parts you will encounter in everyday work.2