Domain Names and URLs: Understanding Website Addresses Before Launch

Before you share or publish any page, you need to know what each part of a website address actually does. This article uses one hypothetical URL to show how a domain name, a path, a query string, and a fragment each answer a different question, and how you can record those answers for your own project.

What a Domain Name Answers and What a Full URL Answers

Suppose you are planning a small personal project and you want to share one specific page with a collaborator. The address you would type or paste into a browser looks like this: https://example.org/notes/first-page?view=compact#intro. This is a hypothetical address used only for breaking down the string into its parts; it does not claim that this page actually exists or is live anywhere. Treating it as a pure text sample lets us focus on structure without worrying about what a real server might return.

A domain name answers the question “which server should the browser 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 IP addresses, but people find those hard to remember, so domain names exist as a readable alternative. In our example, example.org is the domain name. It tells the browser which server to reach, and nothing more specific than that.¹

A full URL answers a narrower question: “which specific resource on that server?” 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, or documents. The complete address above does more than name the server; it also specifies a path, a query, and a fragment. Each of those additional parts narrows down what the browser should request or where it should scroll once the resource loads.²

Reading the Example Address Part by Part

Let us mark each component of the hypothetical address. The scheme is https, which indicates the protocol the browser must use to request the resource. The domain is example.org. The path is /notes/first-page. The query string is view=compact, and it begins immediately after the question mark. The fragment is intro, and it begins immediately after the hash symbol. Writing these labels next to the string is the first step toward understanding how the address works as a whole.²

The question mark signals the start of the query portion. Parameters are extra key-value pairs provided to the web server, and when there are multiple parameters they are separated by the ampersand symbol. In our example there is only one parameter: view=compact. The hash symbol signals the start of the fragment, which acts as a sort of bookmark inside the resource itself. On an HTML document the browser would scroll to the point where the anchor is defined. It is worth noting that the fragment identifier is never sent to the server with the request.²

The domain portion itself has internal structure. A TLD is the most generic domain in the hierarchical DNS and is the final component of a domain name; in example.org the TLD is org. The label immediately before it, example, is the second-level domain. Together they form the host portion of the URL. ICANN designates organizations to manage each TLD, and depending on how strict the administrating organization is, the TLD can serve as a clue to the purpose or ownership of a website.³

Same Host, Different Paths and Queries

Now keep the host part fixed at example.org and change only the path. If the address were https://example.org/about, the browser would still contact the same server, but the path portion would be different. The string /about replaces /notes/first-page. We are only observing how the text changes from one address to another; we are not making claims about what a server would actually return for either path. The point is that the path is an independent segment you can swap without touching the domain.

Similarly, if the query changes from view=compact to view=full, the string after the question mark is different while the domain and path stay the same. This illustrates that the query portion carries additional information separate from the path. You could also remove the query entirely, leaving https://example.org/notes/first-page, and the address would still be structurally valid. Each optional part can be present or absent without breaking the overall format.

You can combine these observations to see how a single domain can appear in many different URLs. The domain stays constant while the path, query, and fragment vary. When you are planning pages for your own project, thinking of the address as a set of independent slots helps you predict how changes to one part leave the others untouched. This is a string-level observation about the address format, not a statement about how any particular server would handle the requests.

Building an Address Description Card for Your Project

Record the purpose of the page in one short sentence before you write down the address itself. For our hypothetical project, the purpose might be: “A compact reading view of the first note in my project notebook.” Stating the purpose first gives you a reference point when you later need to explain the address to someone else or check whether it still matches what the page actually contains.

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 its label. Scheme: https. Domain: example.org. Path: /notes/first-page. Query: view=compact. Fragment: intro. This layout keeps every piece visible at a glance and makes it easy to spot a missing or misplaced character when you compare the card against the live address later.

Add a brief note about which parts you chose deliberately and which parts you might change. For instance, you might note that the path reflects a folder-like naming decision you made for readability, while the query parameter was added by a tool you are using and could change if the tool updates. Distinguishing your own choices from externally generated strings helps you decide which parts to protect and which parts you can safely update without breaking links you have already shared.

Verifying the Card by Manual Copying and Labeling

This verification process is a set of author suggestions, not rules from any specification. The goal is simply to catch typos or missing characters before you share the address publicly.

The whole check takes only a minute or two, but it builds a habit that prevents confusing mistakes later, especially when addresses grow longer with more parameters or deeper paths.

If you find a mismatch, correct the card first and then repeat the check from the beginning. Do not patch a single character in isolation, because one correction can shift your reading of the segments that follow.

Step 1

Copy the full address from your card into a plain text editor. Do not paste it into a browser or a rich text field, because those environments may hide or alter characters. A plain text view shows you exactly what is in the string.

Step 2

Label each segment directly in the text. Place a bracket or a comment after the scheme, after the domain, after the path, after the question mark, and after the hash. For example, you might write “scheme: https” on one line and “domain: example.org” on the next, working through the address from left to right.

Step 3

Compare your labeled segments against the card you built in the previous section. Check that the path matches, that the query key and value are spelled identically, and that the fragment text is the same. If anything differs, note which segment is wrong and correct it before moving on.

Keeping Your Description for Future Writing and Communication

Store the completed card somewhere you will naturally look when you write about your project. A simple text file in your project folder, a note in your preferred note-taking tool, or even a comment at the top of a configuration file all work. The format matters less than the habit of keeping the card close to the work it describes, so that you can glance at it whenever you need to paste an address into documentation, an email, or a chat message.

When your project grows, you can extend the same card format to additional pages. Each new page gets its own line with the full address and a one-sentence purpose. Over time this becomes a small address inventory that tells you at a glance which paths exist, which queries you have used, and which fragments you have defined. You do not need a special tool for this; a plain list is enough for a personal or small-team project.

If you later decide to change a path or remove a query parameter, update the card at the same time. This keeps your written records consistent with the addresses you actually share. The card is your own reference, so you choose what level of detail to include. Some people record only the full address and the purpose; others also note the date they created the page or the reason they chose a particular path name. Pick the fields that help you avoid confusion and skip the rest.

Frequently asked questions

Is the domain name the same thing as the URL?

No. A domain name identifies the server, while a URL is the complete address of a specific resource. The domain is one part inside the URL; the URL also includes a scheme, a path, and optionally a query and a fragment.¹²

What does the question mark do in a URL?

The question mark signals the start of the query portion. Everything after it consists of key-value pairs that provide extra parameters to the web server. In our example, view=compact is the query.²

Does the fragment part get sent to the server?

No. The fragment identifier, which appears after the hash symbol, is never sent to the server with the request. It tells the browser where to scroll or jump within the already-loaded resource.²