Domain Names and URLs: Understanding Website Addresses Before Launch

Before you launch a website, you will type, copy, and share web addresses many times. Understanding what each part of an address means helps you catch mistakes early and communicate clearly with collaborators. This article walks through one hypothetical address and shows how to read it piece by piece.

What Domain Names and Full URLs Each Tell You

Suppose you are planning a small personal project site and someone asks you for the address. You might say "example.org" out loud, or you might paste a longer string like https://example.org/notes/first-page into a message. Both are useful, but they answer different questions. The domain name tells a listener which server to find on the Internet. The full URL tells a browser exactly which resource on that server to retrieve.

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 reach servers through IP addresses, which are long sequences of numbers that people find difficult to remember and that can change over time. A domain name acts as a friendly alias for that numeric address.¹²

A URL, short for Uniform Resource Locator, goes further. It is the address of a unique resource on the internet and serves as one of the key mechanisms browsers use to retrieve published resources such as HTML pages, images, or stylesheets. While the domain name portion of a URL identifies the server, the remaining parts narrow the request down to one specific page or file on that server.³

Reading the Example Address Part by Part

For this exercise we will use the following hypothetical address: https://example.org/notes/first-page?view=compact#intro. This address is constructed purely for the purpose of labeling each component. It does not claim that this page exists or is live anywhere. Treat it as a string to dissect, not a destination to visit.

The first segment, https, is the scheme. It indicates the protocol the browser must use to request the resource. For websites the protocol is usually HTTPS or its unsecured version HTTP. The scheme is always followed by the separator :// before the next part begins.³

Next comes example.org, which is the domain name and forms the authority portion of the URL. The authority tells the browser which web server is being requested. In our string, example.org is the host. After the domain, the path begins with the first forward slash. Here the path is /notes/first-page, which represents the location of the resource on the web server.³

The Question Mark, the Hash, and What Comes After

Continuing with our example, after the path you see ?view=compact. The question mark signals the start of the query string. Query parameters are extra key-value pairs provided to the web server, separated by the ampersand symbol when there is more than one. In this case there is a single parameter where the key is view and the value is compact. The web server can use these parameters to adjust what it returns, though each server has its own rules about how parameters are handled.³

Finally, the hash character # introduces the fragment identifier, which in our example is intro. An anchor represents a sort of bookmark inside the resource itself, giving the browser directions to show the content located at that bookmarked spot. It is worth noting that the fragment is never sent to the server with the request; it only matters once the page has loaded in the browser.³

To summarize the full breakdown: https is the scheme, example.org is the domain, /notes/first-page is the path, ?view=compact is the query string, and #intro is the fragment. Each delimiter marks a boundary. The colon and double slashes end the scheme, the first slash after the domain starts the path, the question mark starts the query, and the hash starts the fragment.

Same Domain, Different Paths and Queries

Now keep the host portion fixed at example.org and imagine two other addresses you might encounter on the same project. One could be https://example.org/notes/second-page and another could be https://example.org/notes/first-page?view=full. In both cases the domain is identical, meaning the browser contacts the same server. What changes is the path or the query string, which tells the server to look for a different resource or to apply different parameters.

This distinction matters when you share links with others. If you accidentally omit the path, the recipient may land on a different page than you intended. If you drop the query string, the server might return a default view instead of the one you were looking at. The string is not just decoration; each segment carries information that shapes what the browser requests.

We are not inferring how any particular server handles these variations. Different servers may treat a missing query parameter gracefully or return an error. The point here is simply to notice that the text before the question mark, the text between the question mark and the hash, and the text after the hash are structurally distinct parts of the same address.

Building an Address Description Card

Record the purpose of the address in one short sentence. For our hypothetical project, you might write: "This is the main notes page displayed in compact view, anchored to the introduction section." Keeping the purpose next to the raw string gives you a quick reference when you later need to explain the link to a collaborator or troubleshoot a broken bookmark.

Write the full address on its own line, exactly as it should appear. Below it, list each component with a label: scheme, domain, path, query, and fragment. Even if a particular address lacks one of these parts, noting its absence reinforces your understanding of the structure. For example, a simple homepage like https://example.org/ has a scheme and domain but no meaningful path beyond the root, no query, and no fragment.

Check your card by reading the address aloud from left to right, pausing at each delimiter. Say "scheme" when you reach the colon, "domain" when you reach the first slash after the host, "path" as you read the segments between slashes, "query" at the question mark, and "fragment" at the hash. This verbal walk-through helps you internalize where each boundary falls without needing to consult a reference every time.

Step 1

Copy the full address from your browser's address bar or from your notes into a plain-text document. Avoid rich-text editors that might introduce hidden formatting characters.

Step 2

Label each segment directly beneath the copied string. Write the word "scheme" under https, "domain" under example.org, "path" under /notes/first-page, "query" under ?view=compact, and "fragment" under #intro.

Step 3

Compare your labeled card against the original address character by character. If any segment is missing or misplaced, correct the card before you rely on it for sharing or documentation.

Keeping Your Address Notes for Future Use

Once you have a verified description card, store it somewhere you will actually revisit. A simple text file in your project folder works well because it is searchable and does not depend on any particular tool. Some people prefer a spreadsheet with one row per page address; others keep a short markdown document. The format matters less than the habit of writing the information down at all.

When you later write documentation, share a link in an email, or describe your site structure to a designer, you can pull the card up and copy the exact string rather than retyping it from memory. This reduces the chance of introducing a typo in the path or dropping a query parameter. Over time, your collection of cards becomes a small reference map of your site.

You do not need to document every possible address your site might serve. Start with the pages you share most often or that carry meaningful query parameters. As your project grows, you can add new cards and revise old ones. The goal is not completeness for its own sake but a reliable record that saves you from re-deriving the structure each time you need to explain where something lives.

Frequently asked questions

Is the domain name the same thing as the URL?

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

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

No. The fragment identifier is never sent to the server with the request. It only affects what the browser displays after the page has loaded, typically by scrolling to a bookmarked section.³

Why does the query string matter if the path already identifies a page?

The path locates the resource, while the query string provides additional parameters that the server can use to modify its response, such as changing the display format or filtering results. Each server decides how to handle these parameters.³