Domain Names and URLs: Understanding Website Addresses Before Launch

Before you publish your first website, you will encounter two related but distinct concepts: the domain name and the full URL. Understanding what each one tells you—and how they fit together—helps you read, write, and share addresses with confidence. This article uses a single hypothetical address to walk through every part step by step.

What Question Does Each Part Answer?

Suppose you are planning a small personal project and you want to give it a public address. The first decision most people think about is the domain name. A domain name provides a human-readable address for a web server available on the Internet. Computers communicate through IP addresses—long strings of numbers that are difficult for people to remember—but domain names solve that problem by giving each server a memorable label. In our hypothetical example, the domain name is example.org. It answers one specific question: which server on the Internet are we talking about?¹

A full URL answers a broader question. While the domain name identifies the server, the complete URL identifies a 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, CSS documents, and images. So when you type an address into your browser, you are not just naming a server—you are pointing to a particular page, file, or location within that server. The hypothetical address we will use throughout this article is https://example.org/notes/first-page?view=compact#intro. This page does not actually exist; it is constructed purely to demonstrate how each part of the string works.²

Think of it this way: the domain name is like the name of a building, while the full URL is like a complete mailing address that includes the building name, the floor, the room number, and even a note about which desk to deliver to. Both are useful, but they answer different levels of specificity. For the rest of this article, we will stay with our single example and examine each piece in turn.

Labeling Every Part of the Example Address

Let us take the hypothetical address https://example.org/notes/first-page?view=compact#intro and mark each component. The first segment, https, is the scheme. It tells the browser which protocol to use when requesting the resource. For most websites today, the scheme is HTTPS. The next segment, example.org, is the domain name—the human-readable identifier for the server. After the domain comes the path, which in this case is /notes/first-page. The path points to a specific location or resource on that server.²

After the path, you will notice a question mark followed by view=compact. The question mark signals the beginning of the query string. Query parameters are extra pieces of information provided to the web server, formatted as key-value pairs. In our example, the key is view and the value is compact. Finally, the hash symbol introduces the fragment identifier: #intro. The fragment acts as a kind of bookmark within the resource itself, telling the browser to scroll to or focus on a particular spot. It is worth noting that the fragment is never sent to the server with the request—it is handled entirely by the browser.²

To summarize the labeling for our example: https is the scheme, example.org is the domain, /notes/first-page is the path, ?view=compact is the query, and #intro is the fragment. The question mark always introduces the query portion, and the hash symbol always introduces the fragment. These punctuation marks are not decorative; they serve as structural delimiters that tell the browser how to parse the rest of the string.²

Same Host, Different Paths and Queries

Now let us keep the host portion—example.org—exactly the same and change only the path and query. Imagine a second address: https://example.org/notes/second-page?view=full#summary. The domain has not changed, so the browser would still contact the same server. What changed is the path, which now points to a different resource location, and the query, which now passes a different value for the view parameter. The fragment also shifted from intro to summary, meaning the browser would look for a different bookmark within whatever resource it retrieves.

Consider a third variation: https://example.org/notes/first-page. Here the path is identical to our original example, but the query and fragment are absent entirely. This demonstrates that the query and fragment are optional parts of a URL. The address is still valid without them. The difference between this version and the original is purely in the string itself—one carries extra instructions for the server and the browser, while the other does not. We are observing what the string says, not making claims about what any particular server would actually do with these instructions.

This comparison highlights an important point for beginners: changing the path, query, or fragment produces a different URL even when the domain stays the same. Each variation is a distinct address. When you are planning your own site structure, it helps to recognize that the domain is only the starting point. The paths you choose determine how individual pages and resources are located, and query parameters can further refine what the server receives. None of this requires you to predict server behavior; you are simply reading the address string and understanding what each segment communicates.

Building an Address Description Card

Record a short description card for any address you plan to use or share. For our hypothetical project, the card might look like this: Purpose — a personal notes page displayed in a compact layout, with the browser scrolling to an introduction section. Full address — https://example.org/notes/first-page?view=compact#intro. Scheme — https. Domain — example.org. Path — /notes/first-page. Query — view=compact. Fragment — intro. Writing these out separately forces you to acknowledge each component and makes it easier to spot mistakes later.

Write the purpose in plain language that someone without technical background could understand. The purpose is not a technical specification; it is your own reminder of why this address exists and what you expect it to point to. If you later change the path or remove the query, you can update the card and immediately see what shifted. This practice is especially useful when you manage more than one page, because each page gets its own card and its own line in your notes.

Check that every field on your card matches the actual string character by character. A common mistake is confusing a forward slash with a backslash, omitting the question mark before a query, or placing the fragment before the query. The card format makes these errors visible because each part occupies its own labeled line. You do not need any special software for this—a plain text file or a notebook works perfectly well.

Verifying Your Card by Hand

Manual verification is a simple but reliable way to confirm that your description card matches the address you intend to use. The process requires no tools beyond your eyes and a text editor. Below are the steps we recommend as a practical habit before you share any address publicly or embed it in another document.

These steps are author suggestions based on common editorial practice. They are not prescribed by any specification, but they help catch typos and structural errors that are easy to overlook when you are reading a long string quickly.

Use this checklist each time you add a new page address to your project notes. Over time, the habit becomes fast, and you will find that most errors are simple transpositions or missing punctuation marks that a careful line-by-line review catches immediately.

Step 1

Copy the full address from your browser's address bar or from your planning document into a blank line in your text editor. Do not retype it from memory; always paste or copy the exact string you want to verify.

Step 2

Starting from the left, identify the scheme and confirm it matches the scheme field on your card. Move to the domain and compare it character by character. Then locate the first forward slash after the domain and confirm that everything between that slash and the question mark (or the end of the string, if there is no query) matches the path field on your card.

Step 3

If a question mark is present, verify that the text between the question mark and the hash symbol (or the end of the string) matches your query field. If a hash symbol is present, verify that everything after it matches your fragment field. Mark each field as confirmed or flag any discrepancy for correction.

Keeping Your Record for Future Use

Once your description card is verified, store it somewhere you will actually revisit. A dedicated section in your project notes, a spreadsheet tab, or even a pinned message in a team chat all work. The format matters less than the habit of keeping the card alongside the content it describes. When you later write documentation, share a link with a collaborator, or troubleshoot a broken reference, having the card saves you from re-parsing the address from scratch.

You may choose to record only the parts that are relevant to your current task. For a simple personal blog, you might note just the domain and path for each page and skip the query and fragment if they are not yet in use. For a project that relies on query parameters to control display options, recording those becomes essential. The key is consistency: whatever level of detail you choose, apply it the same way across all your cards so that the set remains easy to scan.

This record also serves as a communication aid. If you need to explain your site structure to someone else—perhaps a designer, a friend helping with content, or a future version of yourself—the card gives you a ready-made reference. You can point to the purpose field to explain intent and to the labeled parts to explain mechanics, without needing to re-derive the breakdown each time. Over the life of a project, this small investment in documentation pays for itself repeatedly.

Frequently asked questions

Is the domain name the same thing as the URL?

No. The domain name identifies the server, while the full URL identifies a specific resource on that server. A URL includes the domain name plus additional parts such as the scheme, path, query, and fragment.¹²

Do I need to include the query and fragment every time I write an address?

No. The query and fragment are optional parts of a URL. If your page does not use query parameters or in-page anchors, the address is perfectly valid without them. Include them only when they serve a purpose in your project.²

Can I change the path of a page without changing the domain?

Yes. The domain stays the same regardless of how many different paths you use beneath it. Each unique combination of path, query, and fragment produces a different URL, but they can all share the same domain name.