Domain Names and URLs: Understanding Website Addresses Before Launch

When you prepare your first website, the terms domain name and URL often appear together, yet they answer different questions. This article uses one hypothetical address to show what each part of a website address does and how to keep a clear record of it.

What a Domain Name Answers and What a Full URL Answers

Suppose you are setting up a small personal site to publish study notes. Someone asks you for the address of your site. You might reply with just a domain name, such as example.org, or you might paste a full address like https://example.org/notes/first-page?view=compact#intro. These two answers operate at different levels of specificity. A domain name identifies which server on the internet you want to reach. A full URL goes further and specifies which exact resource on that server the browser should retrieve. Understanding this distinction helps you communicate clearly with collaborators, hosting providers, and readers who need to find your content.¹²

Domain names exist because computers communicate through IP addresses, which are long numeric strings that people find difficult to remember and that can change over time. A domain name is a human-readable alias for an IP address, making it practical for people to type, share, and recall. The structure is read from right to left, with the top-level domain on the right providing general information about the service, and labels to the left narrowing down to a specific server or subdomain.¹³

A URL is the address of a unique resource on the internet. It combines the scheme, the domain, and additional parts that narrow the request to a specific page, file, or position within a page. In theory, each valid URL points to a unique resource. When you share a full URL rather than just a domain name, you give the recipient enough information to land on a particular piece of content without further navigation.²

Reading Each Part of the Example Address

To see how the parts of a URL fit together, consider the 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 label and discuss. Treating it as a pure reading exercise keeps the focus on structure rather than on any live server behavior.²

The first component is the scheme, written here as https. It tells the browser which protocol to use when requesting the resource. The next component is the domain, example.org, which identifies the web server. Together, the scheme and the domain form the minimum information needed to reach a particular server. In our example, the authority section is simply example.org with no port number shown, which means the browser will use the standard port for HTTPS.²

After the domain comes the path, written as /notes/first-page. The path indicates which resource on the server is being requested. Following the path is the query string, introduced by the question mark character. In this example, ?view=compact is the query, consisting of a key called view with the value compact. Finally, the hash character introduces the fragment, which here is intro. The fragment acts as a bookmark inside the resource itself and is never sent to the server with the request. To summarize the delimiters: the question mark signals the start of the query, and the hash signals the start of the fragment.²

Same Host, Different Paths and Queries

Keeping the host portion fixed at example.org, we can compare several hypothetical addresses that differ only in their paths. The address https://example.org/notes/first-page and the address https://example.org/notes/second-page share the same scheme and domain but request different resources through different path strings. The scheme and domain tell the browser where to go; the path tells it what to ask for once it arrives. Changing the path changes which resource is being requested, even though the destination server remains the same.

Now consider what happens when we vary the query string while keeping everything else identical. The address https://example.org/notes/first-page?view=compact and the address https://example.org/notes/first-page?view=full both point to the same path on the same server, but they carry different query parameters. The key is the same in both cases, but the value differs. From the string alone, we can observe that these two addresses are distinct, but we cannot determine what the server actually does with the view parameter. The string tells us what is being requested, not how the server responds.

This distinction between observation and inference matters when you are documenting addresses for your own project. You can reliably note which parts of a URL differ between two addresses and describe those differences in terms of scheme, domain, path, query, and fragment. What you should avoid is assuming that a particular query value produces a specific result on the server, unless you have confirmed that behavior through testing or documentation. The address string is a request description, not a guarantee of outcome.

Building an Address Description Card

Write down a short description card for each address your project uses. For our hypothetical notes site, the card would include the purpose of the page, the full address, and a breakdown of each component. The purpose might read: study notes, first page, compact view. The full address is https://example.org/notes/first-page?view=compact#intro. Below that, list the scheme as https, the domain as example.org, the path as /notes/first-page, the query as view=compact, and the fragment as intro.

Record the card in a format that is easy to scan quickly. A simple list with one item per line works well. Place the full address at the top so you can copy it without searching through a paragraph. Below the address, list each part with a short label. If your project has multiple pages, create one card per address. Over time, this collection becomes a quick reference that saves you from re-parsing long strings every time you need to share or troubleshoot a link.

The value of this card is not in the act of writing it once but in having a stable reference you can check against later. When you update content, add new pages, or share links with collaborators, the card gives you a single place to verify that each part of the address is what you intended. It also helps you spot mistakes such as a missing query parameter or a fragment that points to a section you have since renamed.

Verifying the Card by Hand

Manual verification is a straightforward habit that catches small errors before they cause confusion. The process does not require any special tools, only a text editor or even a plain sheet of paper. The goal is to confirm that every part of the address you recorded matches the actual string you intend to use.

After completing the steps, compare your labeled parts against the card you wrote earlier. If every part matches, the card is accurate. If any part differs, update the card to reflect the actual string. This check takes only a minute but prevents the kind of small mismatch that leads to broken links or shared addresses that do not work as expected.

Check your card each time you modify the address structure of your project. If you add a new page, change a query parameter, or rename a section that a fragment points to, update the corresponding card immediately. Keeping the card current means you always have a reliable reference without needing to reconstruct the address from memory.

Step 1

Copy the full address https://example.org/notes/first-page?view=compact#intro into a blank text document. Make sure the copy is exact, with no extra spaces or missing characters.

Step 2

Mark each boundary in the copied string. Place a bracket or highlight around the scheme https, then around the domain example.org, then around the path /notes/first-page, then around the query view=compact, and finally around the fragment intro. Label each marked section with its name.

Step 3

Compare your labeled sections against the description card you created. Confirm that the scheme, domain, path, query, and fragment all match between the copied string and the card entries.

Keeping the Record for Future Use

Once your description card is verified, store it somewhere you will naturally look when working on the project. A plain text file in your project folder, a note in your preferred writing app, or even a comment at the top of a configuration file all work. The format matters less than consistency. What matters is that the card is available at the moment you need to share a link, write documentation, or troubleshoot a page that is not loading as expected.

As your project grows, you may accumulate several cards. At that point, consider organizing them by page purpose or by the section of your site they belong to. For a small personal notes site, a single file with all cards listed sequentially is usually sufficient. For a larger project, grouping cards by section or by content type helps you find the right address quickly without scrolling through an unsorted list.

This practice is a personal choice rather than a technical requirement. Some people prefer to rely on browser bookmarks or server logs instead of hand-written cards. The advantage of a written card is that it captures your intent alongside the address itself. When you return to the project after a break, the card reminds you not only what the address is but why you structured it that way. That context is difficult to recover from a bookmark alone.

Frequently asked questions

Is the fragment part of the address sent to the server?

No. The fragment, which appears after the hash character, acts as a bookmark inside the resource and is never sent to the server with the request. It only affects how the browser displays the content it already received.²

Can I tell what a server does with a query parameter just by reading the URL?

No. The query string describes what is being requested, but it does not reveal how the server processes that request. You would need to test the address or consult the server documentation to know what effect a specific parameter has.

Do I need a description card if I only have one page?

It is not required, but even a single card can save time. If you later add more pages or need to share the address with someone else, having the breakdown already written down means you can explain each part without re-parsing the string from scratch.