Domain Names and URLs: Understanding Website Addresses Before Launch

Before you publish a website, you will encounter two closely related terms: domain name and URL. They look similar in a browser address bar, but they answer different questions. This article walks through a single hypothetical address and shows how to identify every part of it, so you can plan, record, and communicate your own project addresses with confidence.

What a Domain Name and a Full URL Each Answer

Imagine you are preparing a small personal project and you want to give it a web address. The domain name answers one question: which server on the internet should handle my request? Domain names provide a human-readable address for any web server available on the internet, because the underlying IP addresses that computers use are hard for people to remember and may change over time. In our hypothetical example, the domain name is example.org. That string alone tells a browser which server to contact, but it says nothing about which specific page or file you want from that server.¹

A full URL answers a broader question: which unique resource do I want, and how should the browser retrieve it? A URL is the address of a unique resource on the internet and is one of the key mechanisms used by browsers to retrieve published resources such as HTML pages, CSS documents, and images. So while the domain name points to the server, the complete URL points to a particular document or endpoint on that server. Our hypothetical address, https://example.org/notes/first-page?view=compact#intro, is a full URL. It names the server, identifies a specific path, adds a query instruction, and marks a spot within the document. This exercise is purely for reading and labeling the string; we are not claiming this page exists or is live anywhere.²

Keeping this distinction clear from the start prevents a common confusion. When someone says “my domain is example.org,” they are naming the server. When someone shares a full URL, they are pointing to a particular resource on that server. The rest of this article uses the hypothetical address above to show how each piece fits together.

Labeling Each Part of the Hypothetical Address

Write the full string https://example.org/notes/first-page?view=compact#intro on a blank line and mark each segment. The first segment, https, is the scheme. It indicates the protocol the browser must use to request the resource. For websites the protocol is usually HTTPS or its unsecured version HTTP. The authority follows the scheme and is separated from it by the character pattern ://. In our example the authority is example.org, which is the domain name indicating which web server is being requested.²

After the authority comes the path, /notes/first-page. The path represents the location of the 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. Next comes the query string, introduced by the question mark. In our example the query is view=compact. Parameters are extra key-value pairs provided to the web server, and the question mark is the delimiter that separates the path from these parameters. Finally, the hash sign 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. The part after the hash is never sent to the server with the request.²

To summarize the labeling: https is the scheme, example.org is the domain name within the authority, /notes/first-page is the path, ?view=compact is the query string, and #intro is the fragment. The question mark always signals the start of the query, and the hash sign always signals the start of the fragment. Memorizing these two delimiters makes it straightforward to parse any URL you encounter.

Comparing Different Paths and Queries on the Same Host

Now keep the host portion, example.org, unchanged and vary only the path. Compare https://example.org/notes/first-page with https://example.org/gallery/summer-2025. The scheme and domain are identical; only the path differs. This means both addresses point to the same server, but they request different resources. You can observe this difference purely by reading the strings. We are not making any claim about what the server actually returns or how it processes these paths internally.

Next, keep the path the same and change the query string. Compare https://example.org/notes/first-page?view=compact with https://example.org/notes/first-page?view=full. The scheme, domain, and path are all identical. Only the query parameter value has changed. This tells you that both addresses target the same resource location but pass different instructions alongside the request. Again, we are only reading the string structure here, not inferring what the server does with these instructions.

Finally, consider the fragment. Compare https://example.org/notes/first-page#intro with https://example.org/notes/first-page#conclusion. The scheme, domain, path, and any query are the same; only the fragment differs. Because the fragment is never sent to the server, changing it does not alter the request the server receives. It only tells the browser where to scroll or position the view within the already-loaded document. Recognizing this distinction helps you understand why sharing a link with a fragment might land a visitor at a different spot on the same page.

Creating an Address Card for Your Hypothetical Project

Record a short address card for your project. An address card is a simple note you keep alongside your project files that states the purpose of the address, the full URL, and what each part represents. For our hypothetical project the card might read: Purpose is a personal notes page. Full address is https://example.org/notes/first-page?view=compact#intro. Scheme is https. Domain is example.org. Path is /notes/first-page. Query is view=compact. Fragment is intro.

The value of this card is that it forces you to name each component explicitly. When you later need to share the address with a collaborator, write documentation, or troubleshoot a link, you can refer back to the card instead of guessing which part of the string does what. If your project eventually uses a real domain, the structure of the card stays the same; only the domain value changes.

Choose a format that is easy for you to maintain. Some people prefer a plain text file in their project folder. Others prefer a row in a spreadsheet. The format matters less than the habit of filling in every field each time you add a new address to your project. Leaving a field blank is a signal that you have not yet confirmed what that part of the string represents.

Verifying Your Address Card by Hand

Manual verification is a reliable way to catch typos or misidentified segments before you share an address publicly. The process requires no special tools, only careful reading.

Check each delimiter in order. Confirm that the colon-double-slash pattern appears exactly once, separating the scheme from the authority. Confirm that the first question mark appears after the path and before any query parameters. Confirm that the hash sign, if present, appears after the query string or directly after the path if there is no query.

Compare your card entry against the original string character by character. A single missing slash, an accidental space, or a transposed letter in the path can produce a completely different address. This step is tedious but short, and it catches the most common mistakes before they cause confusion.

Step 1

Copy the full URL from your address card into a plain text editor.

Step 2

Label each segment directly above the string: write scheme, domain, path, query, and fragment above their respective portions.

Step 3

Compare your labels against the card fields one by one. If any label does not match the corresponding card field, correct the card before moving on.

Keeping the Record for Future Use

Once your address card is verified, store it where you will naturally look when the project evolves. If you keep project notes in a text file, append the card there. If you use a task board, attach it to the relevant task. The goal is not to build an elaborate system but to have one place where the address and its breakdown live together.

When you eventually write content, share links, or describe your project to others, the card gives you a ready reference. You can quickly explain why a particular path was chosen, what the query parameter controls, or why the fragment points to a specific section. This is especially useful when collaborating, because it removes ambiguity about which part of the address is intentional and which might be a typo.

Over time you may accumulate several address cards if your project grows to include multiple pages or sections. Each card follows the same structure, so reviewing them together makes it easy to spot inconsistencies, such as one page using a different query convention than the others. The habit of recording and verifying pays off most when the number of addresses grows beyond what you can hold in memory.

Frequently asked questions

In the example address, does the fragment intro get sent to the server?

No. The part of a URL after the hash sign, known as the fragment identifier, is never sent to the server with the request. It only tells the browser where to position the view within the already-loaded document.²

What is the difference between the question mark and the hash sign in a URL?

The question mark separates the path from the query string, which carries extra parameters to the server. The hash sign separates the query or path from the fragment, which is a bookmark within the document and is not sent to the server.²

If I change only the path in a URL but keep the domain the same, am I still pointing to the same server?

Yes. The domain name determines which server is contacted. Changing the path requests a different resource on that same server, but the destination server remains the same.²