Domain Names and URLs: Understanding Website Addresses Before Launch

Before you launch a website, you will need to talk about its address with collaborators, in documentation, or in your own notes. Understanding the difference between a domain name and a full URL makes that communication clearer. This article uses one hypothetical address string to walk through each component and offers a simple note-taking method you can reuse for your own project.

What Domain Names and URLs Each Answer

Domain names are a key part of the Internet infrastructure. They provide a human-readable address for any web server available on the Internet. Computers reach each other through IP addresses, which are numbers that identify each device on a network uniquely. People find those numeric addresses hard to remember and hard to connect with the content a site offers, so domain names exist to give each server a readable label that humans can work with.¹²

A URL (Uniform Resource Locator) is the address of a unique resource on the internet. It is one of the key mechanisms used by browsers to retrieve published resources, such as HTML pages, CSS documents, images, and so on. In theory, each valid URL points to a unique resource. This means a domain name tells you which server you are talking about, while a full URL tells you which specific resource on that server you want to reach.³

To make this distinction concrete, consider the following hypothetical address: https://example.org/notes/first-page?view=compact#intro — This address does not point to a real page and has not been published anywhere. It exists only as a string we can take apart to understand how each piece works. Throughout this article, we will return to this same example to observe how the parts relate to each other.

Reading the Example Address Part by Part

The scheme is the first part of the URL, which indicates the protocol that the browser must use to request the resource. In our example, https is the scheme. For websites the protocol is usually HTTPS or its unsecured version HTTP, though browsers also know how to handle other schemes such as mailto for opening a mail client.³

Next comes the authority, separated from the scheme by the character pattern ://. In our example, example.org is the domain name within the authority. The domain indicates which web server is being requested. A TLD (top-level domain) is the final component of a domain name; here org is the TLD and example.org together form the second-level domain name.³⁴

After the domain comes the path, /notes/first-page in our example. The path represents the route to a particular resource on the web server. Following the path, the question mark introduces the query string. In this example, view=compact is the query, a key-value pair that provides extra parameters to the web server. Finally, the hash sign introduces the fragment identifier. Here intro is the fragment, which acts as a sort of bookmark inside the resource, giving the browser directions to show the content located at that bookmarked spot.³

Same Host, Different Paths and Queries

Now let us keep the host portion of our example unchanged and look at what happens when only the path or query varies. The string https://example.org/about keeps the same scheme and domain but uses a different path. The string https://example.org/notes/second-page also keeps the same host while pointing to a different location in the path. In each case the domain portion remains identical; only the route after the domain changes. Observing this helps you see that the domain identifies the server, while the path narrows down which resource on that server you are referring to.

You can also compare what happens when the query string changes or disappears. The address https://example.org/notes/first-page?view=compact includes a query, while https://example.org/notes/first-page omits it entirely. Both strings share the same scheme, domain, and path, but one carries an extra parameter after the question mark and the other does not. The fragment works the same way: https://example.org/notes/first-page#intro includes a fragment, while the version without a hash sign has none. These are purely structural observations about how the string is composed; they do not tell us how any particular server would respond to each variation.

Noticing these structural differences is useful when you are documenting your own project. If two pages on your future site share the same domain but differ in path, you can describe them as separate resources on the same host. If one page accepts query parameters and another does not, your notes can record that distinction without needing to know anything about the server software behind them. The goal at this stage is simply to read the string accurately and describe what you see.

Building an Address Description Card

Write down a short description card for your hypothetical project before you share any address with others or reference it in your own planning documents. The card should record three things: the purpose of the address, the full address string, and a breakdown of each part. For our running example, the purpose might be something like “a reading page for project notes in a compact view” and 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.

Record your reasoning for each choice on the card as well. Why did you pick that path structure? In our example, /notes/first-page suggests a section called notes with a page called first-page. Why include a query at all? The answer here is simply that the hypothetical scenario calls for a compact display mode, so view=compact captures that intent. Why add a fragment? The fragment intro marks a specific section within the page that a reader might want to jump to directly. None of these choices require knowing how a real server would behave; they are just decisions about how to describe the string.

Keep the card short and focused. A single paragraph or a small table with columns for part name, value, and brief note is enough. The point is to create a reference you can glance at later when you need to explain what an address means or when you are checking whether a link you wrote matches what you intended. If your project eventually has multiple addresses, you can make one card per address and keep them together in a single document.

Verifying Your Card by Hand

Hand-copying the address and labeling each segment is a straightforward way to catch mistakes before you share the address anywhere. This verification step is author advice based on common note-taking practice, not a requirement from any specification. The process takes only a few minutes and can save you from sharing an address with a typo or a missing part.

Check your card against the original string one more time after labeling. Read the full address aloud and compare it character by character with what you wrote on the card. Pay attention to whether the question mark appears before the query and the hash sign appears before the fragment. A common mistake is swapping those two delimiters or forgetting one of them entirely. If everything matches, your card is ready to use.

If you find a mismatch, correct the card and repeat the labeling step once more. You do not need any special tools for this; a plain text editor or even a handwritten note works fine. The value of the exercise is not the format but the act of slowing down and looking at each part individually. Once the card passes this check, you can file it with your other project notes.

Step 1

Copy the full address string into a blank line in your text editor or notebook. Do not paste it; typing it by hand forces you to notice each character.

Step 2

Draw a vertical line or insert a space before each delimiter: after the ://, before the first / of the path, before the ?, and before the #. This separates the string into its visible parts.

Step 3

Label each segment above or beside it: scheme, domain, path, query, fragment. Compare these labels with the entries on your description card.

Keeping Your Notes for Later

Once your description card is verified, store it somewhere you will actually look again. A project wiki, a shared document, or even a pinned note in your task manager all work. The format matters less than the habit of returning to the card when you need to reference the address. If you later add more pages or change a path, update the card at the same time so it stays accurate.

Decide for yourself how much detail to keep. Some people record only the full address and a one-line purpose. Others add the part-by-part breakdown and the reasoning behind each choice. Neither approach is wrong; the right level of detail is whatever helps you or a collaborator understand the address quickly without re-deriving it from scratch. If your project grows, you might also note which addresses are stable and which you expect to change, though that is a personal organizational choice rather than a technical requirement.

This practice of writing down what each part of an address means may feel unnecessary for a single hypothetical example, but it scales well. When you eventually work with real addresses on a live project, the same card format applies without modification. You will already be comfortable identifying the scheme, domain, path, query, and fragment, and you will have a repeatable method for documenting them. That familiarity is the real payoff of working through the exercise now, before launch pressure makes careful reading harder.

Frequently asked questions

Is a domain name the same thing as a URL?

No. A domain name identifies a web server with a human-readable label, while a URL is the full address of a specific resource on that server. A URL includes the domain name plus additional parts such as the scheme, path, and optionally a query or fragment.¹³

What does the question mark in a URL indicate?

The question mark introduces the query string, which consists of key-value pairs that provide extra parameters to the web server. In the example used in this article, ?view=compact is the query portion.³

Do I need to include the fragment when I share a link with someone?

Not necessarily. The fragment points to a specific spot within a resource, like a bookmark. If you want someone to land on a particular section of a page, include it. If you just want them to reach the page itself, you can omit the fragment and the link will still work.³