Domain Names and URLs: Understanding Website Addresses Before Launch

Before you publish your first website, you will encounter two closely related terms that are often used interchangeably but answer different questions: domain name and URL. This article walks through one hypothetical address string, labels each part, and shows how a short reference card can keep your own project organized.

What Question Does Each Term Answer?

Imagine you are preparing a small personal project site and someone asks, "What is your website address?" You might answer with just a domain name, such as example.org, or you might give a longer string like https://example.org/notes/first-page?view=compact#intro. Both are valid answers, but they answer different questions. A domain name identifies the server or service you want to reach; a full URL identifies one specific resource on that server.¹²

Domain names exist because computers communicate through numeric IP addresses that are difficult for people to remember or distinguish. A domain name provides a human-readable alias for that numeric address, making it practical to share and type. The structure is read from right to left: the rightmost label is the top-level domain, and the labels to its left narrow the identification further.¹³

A URL builds on the domain name by adding more information. It specifies which protocol to use when requesting the resource, which path on the server to look for, and optionally what extra parameters or in-page location to apply. In short, the domain name answers "which server?" while the full URL answers "which resource on that server, and how should I request it?"²

Labeling Every Part of the Example Address

To make these definitions concrete, we will use one hypothetical address for the rest of this article: https://example.org/notes/first-page?view=compact#intro. This address is constructed purely for the purpose of breaking a URL string into its component parts. It does not represent a real, published page, and you should not expect it to load in a browser.

The first segment, https, is the scheme. It tells the browser which protocol to use when making the request. The next segment, example.org, is the authority; specifically it is the domain name of the server being requested. After the authority comes the path, /notes/first-page, which identifies a particular resource on that server. The question mark introduces a query string: view=compact. The hash sign introduces a fragment: intro. Each of these segments has a distinct role in the address.²

Two punctuation marks deserve special attention because they signal transitions between sections. The question mark always marks the beginning of the query portion; everything after it and before a hash sign is query data. The hash sign always marks the beginning of the fragment portion; the fragment is not sent to the server with the request but instead tells the browser where to position itself within the returned resource. Recognizing these two delimiters lets you separate a URL into its major zones at a glance.²

Comparing Paths and Queries on the Same Host

Now keep the scheme and authority fixed at https://example.org and vary only the path and query. Consider three strings: /notes/first-page?view=compact, /notes/second-page?view=compact, and /notes/first-page?view=full#intro. All three target the same server, but each points to a different resource or a different presentation of a resource. The path changes which resource is requested; the query changes how that resource is asked to behave or display.²

This distinction matters when you plan your own site structure. If you change only the query, you are still asking for the same underlying resource but with different instructions. If you change the path, you are asking for a different resource entirely. The fragment, on the other hand, does not change what the server returns at all; it only affects where the browser scrolls or jumps within the already-delivered content.²

We are not inferring how any particular server would actually handle these strings. Different servers and applications interpret paths and queries according to their own rules. The point of this comparison is purely structural: by reading the string carefully, you can tell which part is the resource identifier, which part carries optional instructions, and which part is a local navigation hint.

Building an Address Card for Your Project

Write down a short address card for your hypothetical project before you begin any real configuration work. The card needs only four lines: a one-sentence purpose statement, the full address string, a label for each segment, and a note about which segments are required versus optional. For our example the purpose might read "Demonstrate how to break a URL into named parts for a beginner guide."

Record the full string exactly as you intend to use it, including the scheme. Omitting https from your card may seem harmless during planning, but it can cause confusion later when you or a collaborator tries to distinguish between the domain name alone and the complete address. Keeping the scheme visible reminds you that the protocol is part of the address, not just a browser default.

Next to each segment, write its role in plain language. For instance, beside example.org write "domain name — identifies the server." Beside /notes/first-page write "path — identifies the specific resource." Beside view=compact write "query — optional instructions passed to the server." Beside intro write "fragment — in-page bookmark, not sent to server." This exercise takes only a few minutes but produces a reference you can revisit whenever you need to explain or troubleshoot an address.

Verifying the Card by Hand

Check your address card against the original string by copying the full URL into a plain-text editor and inserting spaces or line breaks before each delimiter. Place a break after the colon-slash-slash that separates scheme from authority, another before the first slash that begins the path, another before the question mark, and another before the hash sign. You should end up with five clearly separated tokens: the scheme, the authority, the path, the query, and the fragment.

Compare each token with the label on your card. If a token on the card says "path" but the text between the authority and the question mark is empty, you have a mismatch. If your card lists a fragment but the string contains no hash sign, the card is inaccurate. This item-by-item comparison catches the most common beginner mistakes: forgetting the scheme, confusing a query with a fragment, or misidentifying the boundary between path and query.

Record the date you completed this check and the version of the string you verified. If your project evolves and the address changes, you will have a clear before-and-after trail. This habit is especially useful when multiple people contribute to a site, because it gives everyone a shared, annotated reference rather than relying on memory or scattered chat messages.

Step 1

Copy the full URL into a plain-text editor.

Step 2

Insert line breaks at each delimiter: after ://, before the first path slash, before the question mark, and before the hash sign.

Step 3

Compare each resulting token against the label on your address card and correct any mismatch.

Step 4

Note the date and string version on the card for future reference.

Keeping Your Record for Future Use

Store the finished address card in a place you will actually revisit: a project notebook, a dedicated note file, or a shared document with your collaborators. The value of the card is not in creating it once but in having a reliable, annotated reference the next time you need to explain your site structure, write documentation, or debug an address that is not behaving as expected.

You may find it helpful to create one card per page or per address you plan to publish. For a small personal project, two or three cards are usually enough. For a larger site, you might keep a single table where each row is one address with its labeled segments. The format matters less than the habit of writing things down before you need them.

Over time, these cards become a personal glossary. When someone asks whether a particular string is a domain name or a URL, you can point to your card and show exactly which segment serves which role. That concrete reference is far more useful in a conversation than an abstract definition, and it keeps your own understanding sharp as your project grows.

Frequently asked questions

Is example.org a real website I can visit?

No. In this article, example.org is used purely as a hypothetical host to demonstrate how a URL string is divided into named parts. You should not expect that address to load a published page.

What is the difference between a query and a fragment?

A query begins with a question mark and passes optional key-value instructions to the server. A fragment begins with a hash sign and acts as an in-page bookmark; it is never sent to the server and only affects where the browser positions itself within the returned resource.²

Do I need to include https in my address card?

Including the scheme is a good habit because it reminds you that the protocol is part of the complete address. Omitting it can cause confusion when you or a collaborator later needs to distinguish the domain name alone from the full URL.