Domain Names and URLs: Understanding Website Addresses Before Launch

If you are preparing your first website, you will encounter two closely related terms: domain name and URL. They look similar in a browser address bar, but they answer different questions. This article uses one hypothetical address to show exactly how the pieces fit together.

What Question Does Each Part Answer?

Suppose you are planning a small personal project and you write down the address https://example.org/notes/first-page?view=compact#intro as a placeholder for a page you hope to publish someday. This address is purely hypothetical; it does not point to a real page that exists right now. Even so, it contains every structural element you will need to understand before your own site goes live.

A domain name answers the question: which server on the Internet should I reach? Domain names provide a human-readable address for any web server available on the Internet, because the numeric IP addresses that computers use are difficult for people to remember and may change over time. In our example, example.org is the domain name. It tells a browser which machine to contact, but it says nothing about which specific page or file you want from that machine.¹²

A full URL answers a more specific question: which exact resource on that server do I need? A URL is the address of a unique resource on the internet, and it is one of the key mechanisms browsers use to retrieve published resources such as HTML pages, images, or stylesheets. In our example, the complete string from https all the way to #intro is the URL. The domain name is just one component inside it.³

Labeling Every Part of the Example Address

Let us walk through the hypothetical address piece by piece. The scheme is https, which indicates the protocol the browser must use to request the resource. For websites the protocol is typically HTTPS or its unsecured version HTTP. After the scheme comes the authority section, separated by the characters ://. In this example the authority is simply example.org, the domain name that identifies the target web server.³

After the domain comes the path: /notes/first-page. The path tells the server which resource you are requesting. A question mark then introduces the query string: ?view=compact. Query parameters are extra key-value pairs provided to the web server, and the question mark is the delimiter that signals their start. Finally, the hash symbol introduces the fragment: #intro. The fragment acts as a bookmark inside the resource itself, giving the browser directions to show content at that specific spot. It is worth noting that the fragment identifier is never sent to the server with the request.³

To summarize the labels for our single example: https is the scheme, example.org is the domain (host), /notes/first-page is the path, ?view=compact is the query string introduced by a question mark, and #intro is the fragment introduced by a hash symbol. Each delimiter plays a specific role. The colon and double slashes separate scheme from authority, the forward slashes within the path separate directory-like segments, the question mark marks the boundary between path and query, and the hash marks the boundary between query and fragment.³

Same Host, Different Paths and Queries

Now keep the host portion fixed at example.org and change only the path. Compare https://example.org/notes/first-page with https://example.org/notes/second-page. The domain and scheme are identical in both strings, but the path differs in its final segment. From the structure alone you can observe that these two URLs point to different resources on the same server. You cannot determine from the string what those resources contain or how the server handles them; the address only tells you where the request is directed.

Next, keep the path fixed and 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 the same in both, so the browser is requesting the same resource location. The query string differs, which means additional information is being passed along. Each web server has its own rules regarding parameters, and the only reliable way to know whether a specific server handles a given parameter is by asking the server owner. The URL string itself does not reveal what the server will do with view=compact versus view=full.³

This comparison illustrates a useful principle: each part of a URL string carries a distinct role, and changing one part does not automatically change the others. The domain identifies the server, the path identifies the resource location, and the query provides optional extra information. When you plan your own site, you can reason about these parts independently. You do not need to understand server-side logic to read and organize the address string itself.

Building an Address Description Card

Record a short description card for each address you plan to use in your project. For our hypothetical example, the card might look like this: Purpose: the introduction section of my first notes page. Full address: https://example.org/notes/first-page?view=compact#intro. Scheme: https. Host: example.org. Path: /notes/first-page. Query: view=compact. Fragment: intro. Writing these fields down forces you to think about what each part is doing before you start building.

The card serves two practical purposes. First, it gives you a single reference you can check later when you are writing content, setting up links, or explaining your site structure to a collaborator. Second, it makes mismatches visible. If you later decide the page should live at /notes/welcome instead of /notes/first-page, you can update the card first and then adjust your files or configuration to match, rather than discovering the inconsistency after the site is already live.

You do not need any special tool for this. A plain text file, a spreadsheet row, or even a sticky note works fine. The important choice is consistency: pick one format and use it for every address in the project. If your project will have five pages, make five cards. If it will have twenty, make twenty. The effort scales linearly, and each card takes only a minute once you know the pattern.

Verifying the Card by Hand

Once your card is written, verify it by copying the full address into a blank line and labeling each segment manually. This is a simple proofreading step that catches typos, missing slashes, or misplaced question marks before they cause confusion later.

If any label does not match the card, correct the card or the address string until both agree. The goal is not to test whether the page loads; it is to confirm that your written record accurately describes the string you intend to use.

After verification, store the card in a place you will revisit during the project. Many people keep address cards in the same file where they draft their site outline, so the two documents stay in sync.

Step 1

Copy the full address string from your card and paste it into a new blank line in your text editor or notebook.

Step 2

Starting from the left, mark the scheme (everything before ://), then the host (everything between :// and the next slash or question mark), then the path (from the first slash after the host to the question mark or hash), then the query (from ? to # or the end), and finally the fragment (from # to the end).

Step 3

Compare each labeled segment against the corresponding field on your card. If every field matches, your card is accurate. If any field differs, decide which version is correct and update the other.

Keeping Your Records Useful Over Time

Write down why you chose each part of the address, not just what it says. For example, on the card for our hypothetical page you might note: the path uses /notes/ because all journal entries will live under that directory, and the fragment is #intro because the page begins with a heading that carries that identifier. These short rationale notes help you remember your own logic months later, when the original context has faded.

When your project grows, resist the urge to rewrite cards from memory. Instead, open the original card, read what you recorded, and make deliberate edits. This habit prevents small drift between your documentation and your actual file structure. If you rename a page or reorganize a directory, update the card in the same session so the two never fall out of step.

Finally, treat these cards as communication tools as well as personal references. If you ever ask someone for help with your site, handing them a clear list of addresses with labeled parts is far more efficient than describing them verbally. The same card that helped you plan the structure can help a collaborator understand it without guessing.

Frequently asked questions

In the example address, what is the difference between the query string and the fragment?

The query string (?view=compact) provides extra parameters that are sent to the web server along with the request. The fragment (#intro) is a bookmark within the resource itself and is never sent to the server; it only tells the browser where to scroll or focus once the page has loaded.³

Can I change the path in my address without affecting the domain?

Yes. The domain (host) and the path are independent parts of the URL string. Changing the path from /notes/first-page to /notes/welcome does not alter the domain example.org. However, whether the new path actually serves a resource depends on how the web server is configured, which is not something the URL string itself reveals.

Do I need to create a description card for every single page on my site?

That is the author's recommendation for keeping your records consistent, but the level of detail is your choice. At minimum, document the pages you plan to link to from other sites or share publicly, since those addresses are hardest to change later without breaking existing links.