Domain Names and URLs: Understanding Website Addresses Before Launch

If you are preparing your first website, you will encounter both the term domain name and the term URL, and the two are easy to confuse. This article uses a single hypothetical address to show what each concept covers and how to read every part of the string.

What Question Does Each One Answer?

Suppose you are planning a small personal project site and you want to share one specific page with a friend. The address you hand over might look like https://example.org/notes/first-page?view=compact#intro. This is a hypothetical example used purely for reading practice throughout this article; the page does not exist and has never been published. The point is to have a concrete string we can take apart together.

A domain name answers the question: which server on the Internet am I talking to? 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 numeric IP addresses, but people find those numbers hard to remember and they may change over time, so domain names solve that readability problem.¹²

A full URL answers a different question: which specific resource on that server do I want, and how should I get there? A URL is the address of a unique resource on the internet, and it is one of the key mechanisms used by browsers to retrieve published resources such as HTML pages, CSS documents, and images. In our example, example.org is the domain name, but the entire string including the scheme, path, query, and fragment is the URL.³

Reading the Example Address Piece by Piece

Let us mark every part of our hypothetical address. The string https://example.org/notes/first-page?view=compact#intro breaks down as follows. The scheme is https, which indicates the protocol the browser must use to request the resource. The authority section contains the domain name example.org. After the domain comes the path /notes/first-page, which points to a resource on the web server. The question mark introduces the query string view=compact, and the hash symbol introduces the fragment intro.³

Two punctuation marks deserve special attention because they signal boundaries. The question mark always separates the path from the query parameters; everything after it consists of key-value pairs that the web server can use to do extra processing before returning the resource. The hash symbol, also called the number sign or octothorpe, always separates the main address from the fragment identifier. The fragment represents a bookmark inside the resource itself, giving the browser directions to show the content located at that bookmarked spot. Notably, the part after the hash is never sent to the server with the request.³

The domain name itself also has internal structure. A domain name is made of several parts separated by dots and read from right to left. In example.org, the rightmost part org is the top-level domain, which tells users the general purpose of the service behind the domain name. The label example is the second-level domain. Together they form a fully-qualified domain name, and adding the scheme https:// turns the whole thing into a complete URL.¹⁴

Same Host, Different Paths and Queries

Now keep the host part of our example unchanged and vary the rest. Imagine a second address: https://example.org/notes/second-page?view=full. The scheme and domain are identical, but the path now points to a different resource label, and the query parameter has a different value. The fragment is absent here, which simply means no specific bookmark within the resource is requested. These are all differences in the string itself; we are not making any claim about what a server would actually do with each one.

A third variation might be https://example.org/notes/first-page#intro, where the query is removed entirely but the fragment remains. This tells us something useful about how the parts are independent. You can add or remove the query without touching the fragment, and vice versa. The path can change while the domain stays the same. Each segment of the URL string carries its own information, and understanding that separation helps you read any address you encounter.

It is worth repeating that these observations are about the structure of the string, not about server behavior. The URL standard defines how the parts are composed, but each web server has its own rules regarding parameters, and the only reliable way to know if a specific web server is handling parameters is by asking the web server owner. So when you read an address, you can identify what each part is called and what role it plays in the URL format, but you cannot assume how any particular server will respond.³

Building an Address Description Card

Record a short description card for your own hypothetical project before you start building. The card does not need to be fancy; a plain text file or a note in your preferred app works well. For our running example, the card might contain four fields: the purpose of the page, the full address string, a labeled breakdown of each part, and a short note about why you chose this structure.

Write the purpose in one sentence that a non-technical collaborator could understand. For instance, the purpose field for our example might read: a compact view of the first note in a personal notebook project. Then copy the full address exactly as you intend it to appear. Below that, list each component on its own line: scheme is https, domain is example.org, path is /notes/first-page, query is view=compact, fragment is intro. This labeled breakdown becomes your reference when you discuss the address with anyone else.

The note field is where you capture your reasoning. Perhaps you chose the path segment notes because your project organizes content into note-like pages, and you picked first-page as a simple sequential label. Maybe you added the query view=compact because you plan to offer two display modes. None of this is required by any technical standard; it is simply your own documentation of the choices you made. Keeping this reasoning alongside the address helps you stay consistent when you add more pages later.

Verifying Your Card by Hand

Once your description card is drafted, a quick manual check can catch typos and mislabeled parts before you share the address or embed it in your site. The following steps are general author suggestions, not requirements from any specification.

Check each label against the punctuation rules you learned earlier. Confirm that the question mark appears only once and that everything between it and the hash belongs to the query. Confirm that the hash appears only once and that everything after it is the fragment. If your address has no query, there should be no question mark; if it has no fragment, there should be no hash.

Read the full address aloud or have a friend read it back to you from the card. Listening to the string spoken slowly often reveals a missing slash, a transposed letter, or a stray space that your eyes skip over during silent reading. This low-tech check is surprisingly effective for catching errors that automated tools might not flag, especially in short personal project addresses.

Step 1

Copy the full address from your description card into a blank text editor. Make sure no extra spaces or line breaks were introduced during pasting.

Step 2

Mark each boundary character by hand: underline the colon-slash-slash after the scheme, draw a box around the question mark, and circle the hash. Compare your markings against the labeled breakdown on your card.

Step 3

Write a one-line summary stating which parts are present and which are absent. For our example you would note: scheme, domain, path, query, and fragment are all present; port is absent.

Keeping Your Record for Future Reference

Store your address description card somewhere you will actually revisit. A dedicated folder in your project notes, a pinned note, or even a comment at the top of your site's main configuration file all work. The goal is not the storage format but the habit of having a single authoritative place where the address and its breakdown live together. When you later add a second page or change a query parameter, you can update the card and immediately see what changed.

Use the card as a communication tool as well. If you ask for help in a forum or from a collaborator, pasting your labeled breakdown alongside the raw address saves everyone time. Instead of asking someone to figure out which part you are confused about, you have already isolated the piece. This is especially useful when your project grows beyond a single page and you need to discuss multiple addresses that share the same domain but differ in path or query.

Finally, treat the card as a living document. Your first version will reflect your initial choices, and that is fine. As your project evolves, you may rename path segments, add new query parameters, or drop fragments you no longer need. Updating the card each time keeps your understanding of the address aligned with what your site actually uses. The practice of writing, checking, and revising a short description is more valuable than memorizing any single rule, because it builds the habit of reading addresses carefully whenever you encounter them.

Frequently asked questions

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

No. According to the URL specification, the part after the hash symbol, known as the fragment identifier, is never sent to the server with the request. It acts as a bookmark within the resource on the client side.³

What is the difference between a domain name and a URL?

A domain name identifies which web server you are talking to, while a URL is the full address of a specific resource. A URL includes the scheme, the domain name, and optionally a path, query, and fragment. The domain name is one component within the larger URL.¹³

Can I change the path or query without changing the domain?

Yes. The path and query are independent parts of the URL string. You can change the path from /notes/first-page to /notes/second-page or adjust the query value while keeping the domain example.org exactly the same. Each part carries its own information and can be modified separately.