Domain Names and URLs: Understanding Website Addresses Before Launch

Before a website goes live, its address needs to make sense both to the person building it and to anyone who might type it into a browser. This article walks through a single hypothetical address, labels every part, and offers a simple recording method you can reuse for your own project.

What Question Does Each Part Answer?

Suppose you are planning a small personal project and you sketch out an address like https://example.org/notes/first-page?view=compact#intro on a sticky note. This address is purely hypothetical; it is used here only to practice reading the structure of a web address, and no such page is assumed to exist or be live. Even so, looking at it raises two different questions that people often blur together. The first question is: which server on the Internet am I trying to reach? The second is: once I reach that server, which specific resource do I want?

A domain name answers the first question. Domain names provide a human-readable address for any web server available on the Internet, because the numeric IP addresses that computers actually use are hard for people to remember and may change over time. In our example, example.org is the domain name. It tells the browser which machine to contact but says nothing about which page, file, or section on that machine you are interested in.¹

A full URL answers the second question. A URL is the address of a unique resource on the Internet and is one of the key mechanisms browsers use to retrieve published resources such as HTML pages, images, or style sheets. In our example, the entire string from https through #intro is the URL. It narrows the request down from a whole server to one particular resource and even to a specific spot within that resource. Understanding this distinction is the foundation for everything that follows.²

Reading the Example Address Piece by Piece

Let us label every part of our hypothetical address in order. The string begins with https, which is the scheme. The scheme indicates the protocol the browser must use to request the resource; for websites this is normally HTTPS or its unsecured version HTTP. After the scheme comes the authority section, separated by the characters ://. In our example the authority is simply example.org, the domain name that identifies the target server. No port number appears, which means the browser will assume the standard port for HTTPS.²

After the authority comes the path: /notes/first-page. The path tells the server which resource you are requesting. In the early days of the web a path often matched a physical file location on the server, but today it is mostly an abstraction handled by web servers without any physical reality. You can think of it as specifying a location within the site, much like a street address narrows down a building within a city. The question mark that follows introduces the query string. In our example, ?view=compact is the query. Query parameters are extra key-and-value pairs provided to the web server, and the server can use them to do additional processing before returning the resource. The question mark is the signal that everything after it belongs to the query rather than the path.²

Finally, the hash character introduces the fragment. In our example, #intro is the fragment identifier. An anchor represents a sort of bookmark inside the resource, giving the browser directions to show the content located at that bookmarked spot. One important detail: the part after the hash is never sent to the server with the request. It is handled entirely by the browser once the resource has loaded. So in our hypothetical address, the server would receive a request for the path /notes/first-page with the query view=compact, but it would never see the fragment intro.²

Same Host, Different Paths and Queries

Now keep the host part of our example unchanged and vary the rest. If you change the path to /notes/second-page, you are asking for a different resource on the same server. If you change the query from ?view=compact to ?view=full, you are still requesting the same path but asking the server to handle the request differently. These are observations about the string itself; whether the server actually returns different content depends on how that server is configured, which is something we cannot determine just by reading the address.

You can also remove the query entirely and keep only the path, or remove both the query and the fragment. Each variation produces a different URL string, and each one could in principle point to a different resource or a different presentation of the same resource. The key point for a first-time site builder is that the domain name stays constant across all these variations. It is the part that identifies the server, while the path, query, and fragment refine what you want from that server.

This distinction matters when you start sharing links or writing documentation. If you hand someone a URL that includes a query string or a fragment, they will land on a more specific spot than if you hand them just the domain. Knowing which parts to include and which to leave off is a practical skill that saves confusion later, especially when you are collaborating with others who may not be familiar with your project structure.

Making an Address Description Card

Record a short description card for each address your project uses. For our hypothetical example, the card might list the purpose of the address, such as a compact reading view of the first note, followed by the full URL, and then each labeled part: scheme, domain, path, query, and fragment. Writing these out by hand or in a simple text file forces you to think about what each piece does and whether you have chosen sensible values.

Use plain language in the purpose field. Instead of writing something vague like "main page," describe what a visitor would see or do there. For instance, "displays the first note in a compact layout and scrolls to the introduction section" tells you much more about the intent behind the address. This habit pays off when you return to the project after a break or when you need to explain the address to a collaborator.

Check that the card matches the actual string character by character. A missing slash, a misspelled query key, or a forgotten hash can turn a working address into a broken one. This is ordinary proofreading, not a technical test, but it catches the kind of small errors that are easy to overlook when you are focused on content rather than structure.

Checking the Card by Hand

Once your description card is written, verify it against the original address string. The following steps are simple author suggestions for building confidence that your card is accurate. They do not require any special tools, just a text editor or even a sheet of paper.

After you finish marking each segment, compare your labels with the card you wrote earlier. If everything matches, your card is reliable. If something differs, correct the card and repeat the marking pass. This loop of copy, mark, and compare takes only a minute or two, but it builds the habit of treating addresses as structured strings rather than opaque blobs of text.

Write the full address on a fresh line without looking at your card. Then go back and insert a space or a vertical bar before each boundary: after the scheme, after the domain, after the path, and before the fragment. This produces a segmented view you can compare against your labeled card.

Step 1

Copy the full address into a blank text file. Do not retype it from memory; use copy and paste so that you are working with the exact string.

Step 2

Mark each boundary by inserting a space or a separator character. Place one separator after https://, one after example.org, one after /notes/first-page, and one before #intro. You should end up with five visible segments.

Step 3

Label each segment with its role: scheme, domain, path, query, fragment. Compare these labels with the entries on your description card.

Keeping the Record for Future Use

Store your description cards in a place you will actually revisit. A plain text file inside your project folder works well because it travels with the rest of your files. If you use a note-taking application, a dedicated page or notebook for address records keeps them together. The format matters less than the habit of writing the card down and keeping it current.

When you add new pages or change existing paths, update the cards at the same time. An outdated card is worse than no card because it can mislead you or a collaborator into thinking an address still works the way it used to. Treat the card as a living document that grows with your project.

This practice also helps when you write documentation, share links in emails, or set up navigation menus. Instead of guessing which parts of a URL to include, you can look at your card and decide deliberately. Over time the habit of labeling addresses becomes automatic, and you will find it easier to spot mistakes in other people's links as well.

Frequently asked questions

Is a domain name the same thing as a URL?

No. A domain name identifies the server you want to reach, while a URL is the complete address that also includes the scheme, path, and optionally a query and fragment. The domain is one component within a URL.¹²

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

No. The fragment identifier is never sent to the server with the request. The browser handles it locally after the resource has loaded, using it to scroll to the bookmarked spot.²

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

Yes. The domain stays the same while you vary the path, query, or fragment. Each combination produces a different URL that may point to a different resource or a different view of the same resource on the same server.