Domain Names and URLs: Understanding Website Addresses Before Launch

When you prepare a website for the first time, two related terms come up constantly: domain name and URL. They are not the same thing, and confusing them can make communication with collaborators or future readers harder than it needs to be. This article uses one hypothetical address to show exactly where a domain name ends and a full URL begins, then walks through a practical way to record what you find.

What Question Does a Domain Name Answer, and What Question Does a URL Answer?

Suppose you are planning a small personal site where you will publish reading notes. You need to decide on an address that visitors can type into a browser. Before you pick one, it helps to understand that a domain name and a full URL answer two different questions. A domain name identifies the web server you want to reach. As MDN explains, domain names provide a human-readable address for any web server available on the Internet, because raw IP addresses are hard to remember and might change over time. So when someone types a domain name into a browser, the question being answered is: which server should I contact?¹

A URL goes further. It tells the browser not only which server to contact but also exactly which resource on that server to retrieve. MDN defines a URL as the address of a unique resource on the internet, used by browsers to retrieve published resources such as HTML pages, images, or stylesheets. In other words, a domain name is one component inside a URL. The full URL adds a scheme, a path, and optionally a query string and a fragment, each pointing to something more specific than the server alone.²

For this article we will use a single hypothetical address to make the distinction concrete: https://example.org/notes/first-page?view=compact#intro. This address is invented purely for the exercise. It does not point to a real page, and no server is expected to respond to it. We are only interested in reading the string and understanding what each section means.

Marking Each Part of the Example Address

Write the full address on a blank line and separate it into five visible pieces. The first piece is https, which is the scheme. It tells the browser which protocol to use when requesting the resource. The second piece is example.org, which is the domain name and identifies the target server. The third piece is /notes/first-page, which is the path. It narrows the request to a specific location or resource on that server. The fourth piece starts after the question mark: view=compact. This is the query string, a set of key-value pairs passed to the server as extra parameters. The fifth piece starts after the hash symbol: intro. This is the fragment, which acts like a bookmark inside the resource itself.²

Two punctuation marks deserve special attention because they signal boundaries between parts. The question mark introduces the query section. Everything between the question mark and the hash symbol, if one exists, belongs to the query. The hash symbol introduces the fragment. Everything after the hash is a fragment identifier. As MDN notes, the fragment is never sent to the server with the request; it only tells the browser where to scroll or focus within the returned resource.²

The domain name itself also has internal structure. In example.org, the portion org is the top-level domain, or TLD, which is the final component read from right to left. The portion example is the label that precedes it. MDN describes the TLD as providing general information about the purpose or scope of the service behind the domain name, and notes that the full list of TLDs is maintained by ICANN.¹³

Keeping the Host Fixed and Varying the Path and Query

Now hold the host part of our example constant. The domain example.org and the scheme https stay the same in every variation below. Change only the path and the query. Consider a second address: https://example.org/notes/second-page?view=compact#intro. The path has shifted from /notes/first-page to /notes/second-page. The query and fragment remain identical. From the string alone, you can observe that the path is the part that distinguishes one resource from another on the same server. You are not inferring what the server actually does with these paths; you are only reading what the string communicates.

Next, change the query while keeping the path the same. Compare https://example.org/notes/first-page?view=compact#intro with https://example.org/notes/first-page?view=full#intro. The path and fragment are unchanged. The only difference is the value associated with the key view. This tells you that the query string carries optional parameters that can vary independently of the path. Again, you are describing the structure of the string, not predicting how any particular server would respond to these parameters.

Finally, remove the fragment entirely: https://example.org/notes/first-page?view=compact. The address is still valid. The fragment is optional. What you can observe is that the hash symbol and everything after it simply disappear, and the remaining parts are unaffected. This exercise shows that each section of a URL can change independently of the others, and that reading the string carefully is enough to identify which section changed.

Building an Address Description Card for Your Project

Record a short description card for any address you plan to use. The card does not need to be elaborate. A plain text file or a table in a note-taking app works well. For each address, write three things: the purpose of the page in one sentence, the full address exactly as it will appear, and a labeled breakdown of each part. Using our hypothetical example, the purpose might be: a reading-notes page displayed in a compact layout. The full address is https://example.org/notes/first-page?view=compact#intro. The breakdown lists scheme as https, domain as example.org, path as /notes/first-page, query as view=compact, and fragment as intro.

The value of this card becomes clear when you need to explain your address to someone else. A designer, a content collaborator, or a future version of yourself can look at the card and immediately see which part of the string controls which aspect of the request. You do not need to re-derive the structure from scratch each time. The card also makes it easier to spot mistakes: if the path on the card does not match what you see in the browser, something has drifted.

Keep the card format simple and consistent across all the addresses in your project. If you have five pages, make five cards with the same three fields. Consistency matters more than decoration. A uniform format lets you scan a list quickly and compare addresses side by side without mentally switching between different layouts.

Verifying the Card by Manual Copying and Labeling

Check your description card against the live string by copying the address character by character into a plain-text editor. Do not rely on your memory or on a screenshot. Paste the address, then place a space or a visible marker before each boundary: before the first slash after the domain, before the question mark, and before the hash symbol. This gives you a visual segmentation that you can compare against the labels on your card.

Label each segment directly in the text. Write scheme, domain, path, query, or fragment next to the corresponding portion. Then read your labels alongside the card fields. If any label disagrees with the card, correct the card immediately. This step catches common errors such as a missing trailing slash in the path, a misspelled query key, or a fragment that was accidentally included in the path field.

Repeat this check whenever you modify an address. Even small changes, like renaming a page from first-page to first-draft, can introduce typos that are easy to miss when you are focused on content rather than structure. The manual copy-and-label routine takes less than a minute per address and prevents mismatches that would otherwise surface only after publication.

Step 1

Copy the full address from your browser or notes into a plain-text editor.

Step 2

Insert a space before each structural boundary: after the domain, before the question mark, and before the hash symbol.

Step 3

Write the part name (scheme, domain, path, query, fragment) above or beside each segment.

Step 4

Compare your inline labels with the fields on your description card and correct any mismatch.

Keeping the Description for Future Writing and Communication

Save your completed cards in a location you already use for project notes. If you keep a project journal, add a section for addresses. If you use a wiki or a shared document, create a dedicated page. The goal is to have one place where anyone involved in the project can find the current address, its purpose, and its labeled parts without asking you directly.

Update the cards whenever you add, rename, or remove a page. Treat the card list as a living index of your site's public addresses. When a collaborator asks why a link returns an unexpected result, you can point to the card and identify which part of the string might be involved. This is more efficient than re-explaining URL structure from the beginning each time.

You do not need to document every possible variation of query parameters or fragments. Record the versions you actually use or plan to share publicly. If an address is temporary or internal, note that on the card so future readers know it is not a stable reference. This simple annotation prevents confusion between working drafts and published pages, and it keeps your documentation honest about what is final and what is still in progress.

Frequently asked questions

Is a domain name the same thing as a URL?

No. A domain name identifies the web server, while a URL is the complete address of a specific resource on that server. A URL always contains a domain name, but it also includes a scheme, a path, and optionally a query string and a fragment.¹²

What does the question mark in a URL indicate?

The question mark separates the path from the query string. Everything between the question mark and the hash symbol, if present, is a set of key-value parameters passed to the server as extra information about the request.²

Is the fragment sent to the server?

No. The fragment, which is the part after the hash symbol, is never sent to the server with the request. It only tells the browser where to focus within the returned resource, such as scrolling to a specific heading on a page.²