Domain Names and URLs: Understanding Website Addresses Before Launch

Before you publish anything online, it helps to know what each piece of a website address actually does. This article uses one hypothetical URL to show the difference between a domain name and a full URL, then walks through a practical way to record and check the parts.

What question does a domain name answer, and what question does a full URL answer?

Suppose you are planning a small personal project site and you want to understand the address people will type into a browser. The first thing to notice is that a domain name and a full URL answer two different questions. A domain name identifies which server on the Internet you want to reach. Domain names provide a human-readable address for any web server available on the Internet, because IP addresses are hard to remember and might change over time. A full URL, on the other hand, 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.¹²

Think of it this way: the domain name is like the name of a building, while the full URL is like the building name plus a floor number, a room number, and even a note about which desk to walk to. For our hypothetical exercise we will use the address https://example.org/notes/first-page?view=compact#intro. This address does not point to a real page that exists or has been published; it is purely a string we will take apart to understand what each segment means.

With that distinction in mind, the rest of this article labels every part of the example, compares a few variations, and then shows a simple way to record the information so you can refer back to it while building or describing your own site.

Labeling each part of the example address

Let us go through https://example.org/notes/first-page?view=compact#intro piece by piece. The first segment, https, is the scheme. The scheme indicates the protocol that the browser must use to request the resource. For websites the protocol is usually HTTPS or HTTP. Next comes example.org, which is the domain name and forms the host portion of the address. The domain indicates which web server is being requested.²

After the domain comes the path, which in our example is /notes/first-page. The path points to a resource on the web server. In the early days of the web a path like this represented a physical file location, but nowadays it is mostly an abstraction handled by web servers without any physical reality. Following the path, the question mark introduces the query string. In our example the query is view=compact. Parameters are extra key-value pairs provided to the web server, and the server can use them to do additional processing before returning the resource.²

Finally, the hash symbol introduces the fragment, which in our example is intro. An anchor represents a sort of bookmark inside the resource, giving the browser directions to show the content located at that bookmarked spot. It is worth noting that the fragment identifier is never sent to the server with the request. So the question mark signals the start of the query, and the hash symbol signals the start of the fragment. These two punctuation marks are the boundaries that separate the last three parts of a URL.²

Keeping the host the same while changing paths and queries

Now let us hold the scheme and host constant and only change what comes after them. If we write https://example.org/notes/second-page, the domain is still example.org but the path now points to a different resource. If we write https://example.org/notes/first-page?view=full, the path stays the same but the query value changes from compact to full. In each case the string itself is different, and that difference is what matters at the level of the address.

We are not making any claim about what a server would actually return for these strings. The only point here is that each segment of the URL carries a distinct role. The path names the resource, the query adds optional parameters, and the fragment points to a location within the returned document. Changing any one of them produces a different URL string, even though the domain name remains identical.

This observation is useful when you are planning content structure for a new site. You can sketch out several addresses that share one domain but differ in path or query, and use those sketches to think about how your pages relate to each other. No server needs to exist yet for this exercise; you are simply working with the string.

Making an address description card for a hypothetical project

Record the following information on a single card or note for any address you plan to use. Write the purpose of the page in one sentence, then write the full URL, and below that list each part with its label: scheme, host, path, query, and fragment. For our hypothetical example the card would read: purpose is a compact view of the first note; full address is https://example.org/notes/first-page?view=compact#intro; scheme is https; host is example.org; path is /notes/first-page; query is view=compact; fragment is intro.

This card is a personal reference tool. It does not need to follow any official format. The value comes from having every part written out explicitly so that later, when you are composing a link in an HTML document or sharing the address with a collaborator, you can check each segment without guessing.

If your project has several pages, make one card per address. You might find that some pages share the same host and path but differ only in the query or fragment. Writing them side by side makes those differences visible at a glance and reduces the chance of mixing up two similar addresses.

Checking the card by copying and labeling manually

Once your card is written, verify it by copying the full URL into a plain-text editor and labeling each part directly in the text. Place a bracket or comment under the scheme, another under the host, and so on. This manual step catches small mistakes like a missing slash or a misplaced question mark that are easy to overlook when you only glance at the address.

Check that the question mark appears before the query and the hash symbol appears before the fragment. If either symbol is missing or appears in the wrong position, the browser will interpret the string differently from what you intended. For instance, if you accidentally write #intro before ?view=compact, the browser would treat everything after the hash as a fragment and never send the query to the server.

Use a second copy of the URL and compare it character by character against your card. If the two match, your card is accurate. If they differ, correct the card and repeat the check. This takes only a moment but prevents confusion later when you paste the address into navigation menus, documentation, or messages to collaborators.

Step 1

Copy the full URL from your card into a blank plain-text file.

Step 2

Label each segment directly beneath the copied string: scheme, host, path, query, fragment.

Step 3

Compare the labeled copy against your original card and correct any mismatch.

Keeping the record for future writing and communication

Store your address cards in whatever system you already use for project notes. A simple text file, a spreadsheet row, or a note-taking application all work. The important thing is that the record lives somewhere you will actually look when you need to write a link, describe a page to someone, or troubleshoot an address that is not loading as expected.

When you later compose HTML links or share addresses in documentation, you can refer back to the card instead of reconstructing the URL from memory. This is especially helpful when your site has several pages with similar paths, because the card makes the distinguishing segments explicit.

Over time you may add or remove pages. Update the cards as your project evolves. A current set of address cards gives you a quick overview of your site structure and makes it easier to explain that structure to anyone who asks.

Frequently asked questions

Is example.org a real website I can visit?

No. In this article, example.org is used purely as a hypothetical host name to demonstrate how URL parts are labeled. The page https://example.org/notes/first-page?view=compact#intro does not exist and has not been published.

What is the difference between the query and the fragment in a URL?

The query follows the question mark and consists of key-value pairs sent to the server. The fragment follows the hash symbol and acts as a bookmark inside the returned document; it is never sent to the server.²

Do I need to understand every URL part before launching a simple site?

For a basic site, knowing the scheme, host, and path is usually enough to write and share links. The query and fragment become relevant when your pages accept parameters or use in-page anchors, but you can learn those as needed.