Domain Names and URLs: Understanding Website Addresses Before Launch

When you prepare your first website, you will meet two closely related terms: domain name and URL. They look similar in everyday conversation, but each one answers a different question about how someone reaches your content. This article uses a single hypothetical address to show what each part means and how to keep a useful record of it.

A Hypothetical Address to Read

Suppose you are planning a small personal project and you sketch out a sample address for one of its pages. The address you write down is https://example.org/notes/first-page?view=compact#intro. This string is purely hypothetical; it is used here only to practice reading the parts of a web address, and there is no claim that this page exists or has been published anywhere. Treating it as a practice string lets you focus on structure without worrying about a real site.

The domain name portion of that string answers the question “which server am I looking for?” 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 each other through IP addresses, which are long sequences of numbers that people find difficult to remember and that may change over time. A domain name like example.org solves that problem by giving the server a label that humans can read and recall.¹

A full URL answers a more specific question: “which resource on that server do I want?” A URL, short for Uniform Resource Locator, is the address of a unique resource on the internet. It is one of the key mechanisms browsers use to retrieve published resources such as HTML pages, images, or stylesheets. Where the domain name points to the server as a whole, the rest of the URL narrows the request down to a particular page or file on that server.²

Reading Each Part of the Example

The first part of the example string is https, which 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 its unsecured counterpart HTTP. In our example, https tells the browser to use the secure version of the protocol when it contacts the server.²

After the scheme and the separator ://, the next part is example.org. This is the domain name, and it identifies which web server is being requested. The structure of a domain name is made of several parts separated by dots and read from right to left. The rightmost part, here .org, is the top-level domain, which tells users the general purpose of the service. The label to its left, example, is the specific name chosen for this server.¹

Everything after the domain is the path, the query, and the fragment. The path /notes/first-page points to a specific resource on the server. The question mark introduces the query string, which in this case is view=compact; queries are extra parameters provided to the web server as key-value pairs. The hash sign introduces the fragment, here intro, which acts as a bookmark inside the resource and is never sent to the server with the request. So the question mark signals the start of the query, and the hash sign signals the start of the fragment.²

Same Host, Different Paths and Queries

Now keep the host part of the example unchanged and vary the other pieces. If you replace the path /notes/first-page with /notes/second-page, the domain example.org and the scheme https stay exactly the same. What changes is which resource the address points to. The host still identifies the same server, but the path now directs the browser to a different location on it. Reading the string alone tells you this; you do not need to visit the page or know how the server is configured.

Next, change only the query. Replace view=compact with view=full while leaving the path as /notes/first-page. The string now reads https://example.org/notes/first-page?view=full#intro. The resource location has not moved, but the extra parameter carried after the question mark is different. This observation is about the structure of the string itself. It does not tell you what any particular server would do with these parameters, because each web server has its own rules for handling them.

Finally, remove the fragment. The address becomes https://example.org/notes/first-page?view=compact without the trailing #intro. The resource being requested is the same one as before; the fragment only gave the browser directions to a bookmarked spot within that resource. Dropping it means the browser will load the resource from its default starting point rather than scrolling to a specific section. Comparing these three variations side by side shows that the host, path, query, and fragment each carry independent information, and changing one does not automatically change the others.

Building an Address Description Card

Write a short description card for any address you plan to use in a project. The card does not need to follow a formal template; a few lines in a notebook or a plain text file are enough. Record three things: the purpose of the address in your own words, the full URL as you intend to share it, and a labeled list of each part. This is a personal organizational habit suggested here for clarity, not a requirement from any specification.

For the hypothetical example, the purpose might read: “a compact view of the first note in my project.” The full address is https://example.org/notes/first-page?view=compact#intro. Below that, list each part on its own line: scheme is https, domain is example.org, path is /notes/first-page, query is view=compact, and fragment is intro. Writing these out separately makes it easy to spot a missing or mistyped piece later.

The real value of the card shows up when you review it. If you cannot explain why a particular part is included, that is a signal to reconsider whether it belongs there. For instance, if you added a query parameter but are not sure what it controls, you might remove it until you understand its role. The card turns a long string of characters into a set of small, checkable decisions.

Verifying the Card by Hand

Once your description card is written, verify it against the actual string using nothing more than copy-and-paste and a highlighter or a text editor. The goal is to confirm that every part you listed matches the real address character for character. The following steps are author suggestions for a careful manual check.

Pay attention to the boundary characters during this check. The colon followed by two slashes separates the scheme from the domain. The first single slash after the domain begins the path. The question mark separates the path from the query, and the hash sign separates the query from the fragment. If any of these boundaries is missing or misplaced in your copy, the address will not work as you described it on the card.

If you find a mismatch, correct the card or the address and repeat the check. A single wrong character in a path or a missing question mark before a query can change the meaning of the entire string. Repeating the process two or three times builds confidence that the card is accurate before you share the address with collaborators or embed it in another document.

Step 1

Copy the full URL from your description card and paste it into a plain text editor. Using a highlighter or brackets, mark each boundary: the :// after the scheme, the first / after the domain, the ? before the query, and the # before the fragment.

Step 2

Read each labeled part on your card and compare it to the corresponding segment in the pasted string. Check the scheme spelling, the domain labels, every slash in the path, the query key and value, and the fragment name. Note any difference you find.

Keeping the Record for Later Use

Store the finished description card wherever you keep your project notes. It can live in a text file alongside your site outline, in a shared document with collaborators, or even in a comment at the top of a configuration file. The format matters less than the habit of writing it down before the address goes live. When you need to explain the address to someone else or revisit it after a break, the card gives you a quick reference without having to re-parse the string from scratch.

As your project grows, you may create additional cards for other pages. Each one follows the same pattern: purpose, full address, labeled parts. Over time this collection becomes a small map of your site’s address structure. You can scan the cards to notice patterns, such as paths that are deeper than necessary or query parameters that overlap, and decide whether to simplify them.

This practice also helps when you write documentation, share links in emails, or set up redirects later on. Because each card already separates the address into named parts, you can quickly identify which piece changed if a page moves. You are not required to keep cards for every address you ever create; the choice of which addresses deserve a card is yours. The point is that the habit exists and is available whenever an address is important enough to document carefully.

Frequently asked questions

Is the example address https://example.org/notes/first-page?view=compact#intro a real page?

No. That address is used in this article only as a hypothetical string for practicing how to read the parts of a URL. There is no claim that the page exists or has 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 web server as extra parameters. The fragment follows the hash sign and acts as a bookmark inside the resource; it is never sent to the server with the request.²

Do I need to write a description card for every page on my site?

No. The card is a personal organizational suggestion. You might create one only for addresses that are important enough to document carefully, such as a homepage or a key landing page, and skip cards for less critical paths.