Domain Names and URLs: Understanding Website Addresses Before Launch

If you are preparing your first website, you will encounter two related but distinct concepts: the domain name and the full URL. Confusing them can lead to miscommunication with collaborators or mistakes when setting up pages. This article uses a single hypothetical address to show what each concept covers and how to keep a clear record of your own.

What Question Does Each One Answer?

Suppose you are planning a small personal site where you will publish short reading notes. You want visitors to reach the site easily, and you also want each individual note to have its own address. These two needs correspond to two different concepts. A domain name provides a human-readable address for a web server on the Internet. As MDN explains, domain names exist because IP addresses are hard for people to remember and may change over time, so a stable, readable name solves that problem.¹

A full URL goes further. It is the address of a unique resource on the internet, and it tells the browser not only which server to contact but also which specific page, image, or document to retrieve from that server. In other words, the domain name answers the question “which site?” while the full URL answers “which exact resource on that site?”²

For the rest of this article we will work with one hypothetical address: https://example.org/notes/first-page?view=compact#intro. This address does not point to a real page; it exists purely as a string we can take apart and label. Keeping a single example in front of you makes it easier to see how each piece contributes to the whole.

Labeling Every Part of the Example Address

Let us walk through the example from left to right. The string begins with https, which is the scheme. The scheme indicates the protocol the browser must use to request the resource. Next comes example.org, which is the domain name and identifies the web server. After the domain, the path /notes/first-page tells the server which resource is being requested. The question mark introduces the query string view=compact, which provides extra parameters to the server. Finally, the hash symbol introduces the fragment intro, which acts as a bookmark inside the resource itself.²

Two punctuation marks deserve special attention because they signal transitions between parts. The question mark always introduces the query portion of a URL; everything between the question mark and the hash (or the end of the string) consists of key-value pairs that the server can use. The hash symbol always introduces the fragment identifier; the fragment is never sent to the server with the request but instead tells the browser where to scroll or jump within the loaded document.²

Writing these labels next to the string on paper or in a text file is a useful habit. When you can point to each segment and name it, you reduce the chance of confusing the domain with the full address or mistaking a query parameter for part of the path.

Same Host, Different Paths and Queries

Now keep the host portion, example.org, exactly the same and change only what follows it. If the path becomes /notes/second-page instead of /notes/first-page, the domain and scheme are unchanged; only the resource being requested differs. If you add a second parameter so the query reads view=compact&sort=date, you have extended the query string without touching the path or the fragment.

These variations illustrate an important point: the domain name stays constant across many pages on the same site, while the path, query, and fragment change to locate different resources or adjust how they are displayed. Observing the string alone tells you which parts changed. You do not need to know how the server processes each request in order to read and compare the addresses.

When you review a list of addresses for your own project, look for the host first. If the host is identical across entries, you are looking at different resources on the same site. If the host differs, you are looking at entirely different servers. This simple check helps you organize links and spot copy-paste errors before publishing.

Building an Address Description Card

Record the purpose of each address you plan to use. For the hypothetical reading-notes project, you might write: “This address displays the first reading note in a compact layout, scrolled to the introduction section.” Stating the purpose in plain language forces you to confirm what each part of the URL is doing.

Below the purpose statement, list the full address and then break it into labeled parts: scheme (https), domain (example.org), path (/notes/first-page), query (view=compact), and fragment (intro). This card becomes a quick reference you can share with a collaborator or revisit months later without re-deriving the structure from memory.

If your project will have several pages, create one card per address or group them in a single table with columns for purpose, full URL, and notes. The format is up to you; the goal is to have a written record that separates each component rather than treating the address as an opaque string.

Verifying the Card by Hand

A description card is only useful if it matches the actual address string. The following steps are author suggestions for a simple manual check you can perform in any text editor.

Check the punctuation boundaries carefully. Confirm that the question mark appears exactly where the query begins and that the hash appears exactly where the fragment begins. A misplaced question mark or hash changes which part of the string belongs to which component, even if the address still looks plausible at a glance.

Record any discrepancies you find directly on the card. If the path on the card says /notes/first-page but the copied string shows /notes/first_page with an underscore, note the difference and decide which version is correct. Keeping a visible correction trail helps you avoid repeating the same mistake in links you publish later.

Step 1

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

Step 2

Label each segment on the pasted line: mark where the scheme ends, where the domain ends, where the path begins, where the question mark introduces the query, and where the hash introduces the fragment.

Step 3

Compare your labels against the card entry. Every part should match in spelling, order, and punctuation.

Keeping the Record for Future Use

Once your cards are verified, store them somewhere you will actually look. A plain text file in your project folder, a note in your preferred writing app, or a row in a spreadsheet all work. The important choice is consistency: pick one location and keep every address card there so you do not have to search across multiple tools.

When you write content that links to these addresses, refer back to the card rather than retyping from memory. This habit reduces transposition errors, especially for query strings and fragments that are easy to misremember. If you collaborate with others, sharing the card gives them the same structured view you have, which cuts down on back-and-forth clarification.

Over time you may decide to simplify your cards, drop parts you never use, or add a column for the date you last verified each address. Those are personal workflow choices. The underlying principle stays the same: a written, labeled record of your addresses is more reliable than memory, and it costs only a few minutes to create.

Frequently asked questions

Is the domain name the same thing as the URL?

No. The domain name identifies the web server, while the full URL identifies a specific resource on that server. The domain is one component within the larger URL string.¹²

What does the question mark in a URL mean?

The question mark introduces the query string, which contains key-value pairs of extra parameters provided to the web server. Everything between the question mark and the hash symbol (or the end of the address) belongs to the query.²

Does the fragment after the hash get sent to the server?

No. The fragment identifier, which follows 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 document.²