Domain Names and URLs: Understanding Website Addresses Before Launch

When you prepare a personal website for the first time, two terms appear constantly: domain name and URL. They look similar in a browser address bar, but they answer different questions. This article uses one hypothetical address to show exactly where each part begins and ends, so you can read and describe any website address with confidence before your project goes live.

What Question Does Each One Answer?

Imagine you are setting up a small site to publish reading notes for a book club. A friend asks, “What is your site?” You might reply with a short name like example.org. That short name is a domain name. According to MDN, 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 numeric IP addresses, but people find those numbers hard to remember, so domain names exist as a friendlier alternative.¹²

Now suppose the same friend wants to link directly to one specific page of your reading notes. You would hand them something longer, such as https://example.org/notes/first-page. That longer string is a URL. MDN defines a URL (Uniform Resource Locator) as the address of a unique resource on the internet and describes it as one of the key mechanisms browsers use to retrieve published resources such as HTML pages, images, and stylesheets. In other words, a domain name identifies the server, while a full URL pinpoints one particular resource on that server.³

For our hypothetical book-club project we will use the address https://example.org/notes/first-page?view=compact#intro throughout this article. This address is invented purely to practise reading the string; it does not point to a real page that exists or has been published anywhere. Keeping that caveat in mind lets us focus on structure rather than worrying about whether the page loads.

Labelling Every Part of the Example Address

Write the full address on a line by itself: https://example.org/notes/first-page?view=compact#intro. The first segment, https, is the scheme. MDN explains that the scheme indicates the protocol the browser must use to request the resource, and for websites the protocol is usually HTTPS or HTTP. The double slash and the text that follows up to the next slash form the authority section; here the domain is example.org. Because no port number appears after a colon, the browser will use the standard port for HTTPS.³

After the domain comes the path: /notes/first-page. MDN notes that in the early days of the Web a path represented a physical file location on the server, but nowadays it is mostly an abstraction handled by web servers without any physical reality. For our reading exercise the important point is simply that the path tells you which resource on the server is being requested. The question mark that follows the path introduces the query string. Here the query is view=compact, a key-value pair that provides extra parameters to the server. MDN describes parameters as a list of key/value pairs that the web server can use to do extra processing before returning the resource.³

Finally, the hash symbol introduces the fragment, which in our example is intro. MDN clarifies that an anchor represents a sort of bookmark inside the resource, giving the browser directions to show the content located at that bookmarked spot. It also points out that the part after the hash, known as the fragment identifier, is never sent to the server with the request. So the fragment affects what the visitor sees on the page but does not change which resource the server delivers.³

Same Host, Different Strings: What Changes and What Stays

Keep the host portion example.org fixed and swap only the path. Compare https://example.org/notes/first-page with https://example.org/notes/second-page. The scheme, domain, and everything before the path are identical; only the final path segment differs. From reading the string alone you can tell that both addresses request resources from the same server, but you are looking at two different resources. You cannot determine from the string whether the server will actually return different content, redirect one to the other, or produce an error. The string tells you what is being requested, not what the server will do.

Now keep the path the same and change the query. Compare https://example.org/notes/first-page?view=compact with https://example.org/notes/first-page?view=full. The domain, path, and fragment position are unchanged; only the value paired with the key view differs. Again, the string tells you that the requester is asking for a different presentation or filtering of the same resource. Whether the server honours that parameter, ignores it, or treats both identically is a question about server configuration, not about the address string itself.

This distinction matters when you are planning your own site. You might draft several URLs during the design phase and want to know which parts you control through your content structure and which parts depend on how your server or platform is configured. The address string is something you can read, write, and verify without touching any server. Server behaviour is a separate layer that you confirm by actually loading the page or consulting your platform documentation.

Building an Address Description Card for Your Project

Record a short description card each time you settle on an address for a page in your project. The card does not need to be fancy; a plain text note or a row in a spreadsheet works. Include at least four fields: the purpose of the page in one sentence, the full URL you intend to use, the domain portion, and the path portion. If your address includes a query string or fragment, add those as separate fields so you can see at a glance which parts are structural and which are optional modifiers.

For our hypothetical book-club project the card might read like this. Purpose: the first page of reading notes for the group. Full address: https://example.org/notes/first-page?view=compact#intro. Domain: example.org. Path: /notes/first-page. Query: view=compact. Fragment: intro. Writing each piece on its own line makes it easy to spot a typo later, because you are comparing one short field at a time rather than scanning a long string all at once.

Choose whatever format helps you scan quickly. Some people prefer a table with one column per component; others prefer a bullet list. The key decision is to separate the domain from the path, because those two parts are managed in different places when you set up a site. The domain is tied to your registration and naming choice, while the path reflects the content structure you build on the server. Keeping them visually distinct on your card mirrors that real separation.

Verifying the Card by Hand

Copy the full address from your description card and paste it into a blank text file. Then go back to the card and copy it a second time into a different line. Compare the two lines character by character. This manual duplication step catches accidental spaces, missing slashes, or swapped characters that your eye tends to skip when you read a familiar string quickly.

Next, mark each component on the pasted line. Underline or highlight the scheme, then the domain, then the path, then the query, and finally the fragment if one is present. Check that the boundaries match what you wrote on the card. Specifically, confirm that the question mark sits between the path and the query, and that the hash sits between the query and the fragment. If either delimiter is missing or misplaced, the browser will interpret the string differently from what you intended.

Check the spelling of every label value against your notes. In our example that means confirming the word compact appears exactly as you planned, not compct or Compact with a capital C. Path segments are equally worth a second look: first-page with a hyphen is a different string from first_page with an underscore or firstpage with no separator. These small differences do not affect readability for humans, but they produce distinct addresses as far as the server is concerned.

Keeping Your Record Useful Over Time

Store the description card somewhere you already look when working on the project, such as the same folder where you keep draft content or the notes application you use for planning. The value of the card is not only in the moment you first write it; it becomes most useful weeks later when you need to share the address with a collaborator, embed it in a document, or troubleshoot why a link is not behaving as expected.

When you add more pages to the project, create a new card for each one. Over time you will have a small reference list that shows your site structure at a glance. If you ever decide to reorganise paths or rename a page, the cards give you a before-and-after record so you can update links deliberately rather than trying to remember what the old address looked like.

Decide for yourself how much detail to include. Some people add a date field noting when the card was created or last verified; others add a short note about why they chose that particular path name. Neither addition is required. The minimum useful card contains the full address and a one-line purpose statement, because those two pieces let any future reader understand what the address is for without opening a browser.

Frequently asked questions

Is a domain name the same thing as a URL?

No. A domain name identifies the server, while a URL is the complete address that also includes the scheme, path, and optionally a query string and fragment. Every URL contains a domain name, but a domain name alone does not specify which resource on that server you want.¹³

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

No. The fragment identifier is used by the browser to scroll to a bookmarked spot within the already-loaded resource. It is never included in the request sent to the server.³

Can I tell from a URL alone whether two pages show different content?

Not reliably. A URL tells you what is being requested, but the server decides what to return. Two different paths or query strings might produce different content, identical content, or a redirect, depending on how the server is configured.