When you prepare a website for the first time, two related terms come up 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 what each piece means and how you can record it clearly for your own project.
What Question Does Each Part Answer?
Suppose you are planning a small personal notes site and you sketch out an address like https://example.org/notes/first-page?view=compact#intro. This is a hypothetical string used only for practice in this article; it does not claim that such a page exists or is live anywhere. Looking at it as a whole, you can already see it contains several distinct pieces separated by symbols such as slashes, a question mark, and a hash sign. Before you can manage or describe your own site address, it helps to know what each piece is responsible for.
A domain name answers the question “which server or site am I reaching?” Domain names provide a human-readable address for any web server available on the Internet, because raw IP addresses are difficult for people to remember and may change over time. In our example, the domain name portion is example.org. It identifies the host, meaning the specific server that will receive the request.1
A full URL answers a more specific question: “which exact resource on that server do I want?” A URL is the address of a unique resource on the internet, and it is one of the key mechanisms browsers use to retrieve published resources such as HTML pages, images, or stylesheets. The same domain can host many different resources, so the URL adds further detail beyond the domain name to pinpoint one particular item.2
Labeling Every Part of the Example Address
Take the hypothetical address https://example.org/notes/first-page?view=compact#intro and split it at each boundary symbol. The first part, https, is the scheme. It tells the browser which protocol to use when requesting the resource. For websites the scheme is normally HTTPS or its unsecured version HTTP. The characters :// that follow the scheme act as a separator, indicating that the next portion is the authority.2
The authority in our example is example.org. This is the domain name, and it tells the browser which web server is being requested. The domain name sits between the :// separator and the first forward slash that begins the path. A URL is composed of different parts, some mandatory and others optional, and the domain is one of the mandatory pieces when you type an address into a browser.2
After the domain comes the path, which in our example is /notes/first-page. The path points to a specific resource on the server. Following the path, the question mark introduces the query string: view=compact. Query parameters are extra key-and-value pairs provided to the web server, and the question mark is the symbol that always signals the start of this section. Finally, the hash sign introduces the fragment identifier: intro. The fragment acts like a bookmark inside the resource, giving the browser directions to show content at that particular spot. Notably, the fragment is never sent to the server with the request.2
Same Host, Different Paths and Queries
Now keep the host portion, example.org, unchanged and swap only the path. If you replace /notes/first-page with /notes/second-page, you get a different URL that points to a different resource on the same server. The domain name has not changed, so the request still goes to the same host, but the path directs the server to a different location within that host. This is the core distinction: the domain identifies the server, while the path identifies the resource on it.
Next, keep both the host and path the same but change the query string. Replacing view=compact with view=full gives you https://example.org/notes/first-page?view=full. The path still refers to the same resource, but the query parameters differ. Each web server has its own rules regarding parameters, so from the string alone you can observe that the parameters are different without being able to confirm exactly how the server will respond. The point of this exercise is to notice how the string changes, not to predict server behavior.
You can also remove the fragment entirely. The address https://example.org/notes/first-page?view=compact is still a valid URL; it simply lacks the bookmark that would scroll the browser to a particular section. Because the fragment is optional and never reaches the server, removing it does not change which resource is requested. Practicing these small variations helps you see which parts of a URL are structural and which are supplementary.
Building an Address Description Card
Write down a short card for your own project that records three things: the purpose of the address, the full URL string, and a breakdown of each part. For instance, if your hypothetical notes project has a page meant for quick reading in a compact layout, you might write: Purpose: compact view of the first notes page. Full address: https://example.org/notes/first-page?view=compact#intro. Scheme: https. Domain: example.org. Path: /notes/first-page. Query: view=compact. Fragment: intro.
Record the reasoning behind each choice as well. Why did you pick that path structure? Perhaps you want all notes grouped under a /notes/ directory so they are easy to locate later. Why did you include a query parameter? Maybe you plan to offer both a compact and a full view of the same content. Writing these reasons down, even briefly, gives you a reference when you later discuss the address with a collaborator or revisit the project after a break.
Keep the card simple and focused on what you can observe in the string itself. You do not need to speculate about how the server processes each part or what happens behind the scenes. The goal is a clear, human-readable summary that lets you or anyone else understand the structure of the address at a glance. If your project eventually grows to include several pages, you can make one card per address or group related addresses under a shared heading.
Verifying Your Card by Hand
Check your description card against the original address string by copying the full URL into a plain text editor and marking each boundary manually. This low-tech approach catches typos and missing symbols that are easy to overlook when you only glance at the address in a browser bar.
Once you have marked every boundary, compare each labeled piece with the corresponding entry on your card. If the path on your card says /notes/first-page but the copied string shows /notes/firstpage without the hyphen, you have found a discrepancy worth correcting before the address is used anywhere else.
Repeat this check any time you modify the address. Adding a new query parameter, renaming a path segment, or changing the fragment are all moments when a quick manual comparison prevents small errors from compounding later.
Step 1
Copy the full URL from your card and paste it into a blank text file. Place a space or a visible marker before each boundary symbol: the :// separator, each forward slash in the path, the question mark, and the hash sign.
Step 2
Read each segment between your markers aloud and compare it word by word with the corresponding field on your description card. Note any mismatch, correct the card, and save the updated version.
Keeping Your Record for Future Use
Store your address cards in a place you already check regularly, such as a project notes file or a dedicated section in your site planning document. The exact format matters less than consistency; what helps is being able to find the card quickly when you need to share the address, write documentation, or troubleshoot a link.
Decide for yourself how much detail to include. Some people find it useful to note the date they created the card or the reason they chose a particular path name. Others prefer a minimal record with only the full URL and a one-line purpose statement. Both approaches work as long as the information is accurate and easy to locate.
Over time, these small records become a personal reference that saves you from re-deriving the structure of your addresses from memory. When you eventually add more pages, change a query parameter, or hand the project to someone else, having a written breakdown means you can explain the address clearly without starting from scratch.
Frequently asked questions
Is the domain name the same thing as the URL?
No. The domain name identifies the server, while the full URL includes the domain plus additional parts such as the scheme, path, query, and fragment that together point to one specific resource.12
Does the fragment after the hash sign get sent to the server?
No. The fragment identifier is used by the browser to scroll to a bookmarked spot within the resource and is never sent to the server with the request.2
Can I change the query string without changing which page is loaded?
The path determines which resource is addressed, so changing only the query string keeps the same resource in view. However, each web server has its own rules for handling parameters, so the visible result depends on how that server is configured.2