Domain Names and URLs: Understanding Website Addresses Before Launch

If you are preparing your first website, you will quickly encounter two terms that look almost identical but serve different purposes: domain name and URL. This article uses one hypothetical address to show exactly what each part means and how to keep your own records straight before launch.

What Question Does a Domain Name Answer, and What Question Does a Full URL Answer?

When you prepare a website for the first time, two terms come up almost immediately: domain name and URL. They look similar, and people sometimes use them interchangeably, but they answer different questions. A domain name identifies a web server on the Internet in a form that humans can read and remember. Domain names provide a human-readable address for any web server available on the Internet, solving the problem that IP addresses are hard to remember and might change over time. A URL, on the other hand, is the address of a unique resource on the internet. It tells the browser not just which server to contact but which specific resource to retrieve from that server.¹²

To make this distinction concrete, consider a hypothetical address we will use throughout this article: https://example.org/notes/first-page?view=compact#intro. This is not a real page that exists or has been published anywhere. It is a string assembled purely for the purpose of taking apart its components. The domain portion, example.org, points to a server. Everything after the domain narrows down which resource on that server the browser should request.²

The analogy MDN offers is useful here. Think of a URL like a postal address: the domain name is the city or town, the path represents the building where your mail should be delivered, the parameters represent extra information such as the number of the apartment in the building, and the anchor represents the actual person to whom you have addressed your mail. Each part adds a layer of specificity, and together they locate one particular resource.²

Labeling Each Part of the Example Address

Let us label every segment of our hypothetical string. The first part, https, is the scheme. It indicates the protocol that the browser must use to request the resource. For websites the protocol is usually HTTPS or its unsecured version HTTP. The scheme is separated from the rest of the address by the character pattern ://.²

The next part, example.org, is the domain name. It identifies which web server is being requested. Within this domain, org is the top-level domain, which tells users the general purpose of the service behind the domain name. The most generic TLDs such as .com, .org, and .net do not require web services to meet any particular criteria. The label example sits to the left of the TLD and is called the second-level domain.¹³

After the domain comes the path: /notes/first-page. The path represents the location of a 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. Following the path, the question mark introduces the query string: view=compact. Parameters are extra key-value pairs provided to the web server, and each web server has its own rules regarding how it handles them. Finally, the hash sign introduces the fragment: intro. The anchor represents a sort of bookmark inside the resource, giving the browser directions to show the content located at that bookmarked spot. It is worth noting that the part after the hash, also known as the fragment identifier, is never sent to the server with the request.²

Same Host, Different Paths and Queries: What Changes in the String

Now keep the host part, example.org, exactly the same and change only the path and query. Suppose you also plan a page at /notes/second-page with no query string at all, and another at /gallery?sort=date. Looking at these three strings side by side, you can observe that the scheme and domain remain identical while the path and query differ. The string /notes/first-page?view=compact#intro points to one resource with a specific display preference and a bookmark. The string /notes/second-page points to a different resource on the same server without any extra parameters. The string /gallery?sort=date points to yet another resource with its own parameter.

This observation is purely about the structure of the strings themselves. We are not inferring what the server actually does with these requests or whether the pages exist. The point is that each distinct combination of path and query produces a distinct URL, even though the domain stays the same. When you plan multiple pages for your project, each page will have its own path, and any optional parameters will further distinguish one request from another.

Notice also that the fragment identifier in our original example, #intro, does not appear in the other two addresses. A fragment is optional and only meaningful when the resource itself defines a target for it. If you are documenting your site structure before launch, it helps to note which pages will use fragments and which will not, simply so your records stay complete.

Building an Address Description Card for Your Hypothetical Project

Write down a short description card for each address you plan to use. For our hypothetical example, the card might contain four fields: the purpose of the page, the full URL, the domain, and the path with any query or fragment. For instance, the purpose could be “a compact view of the first notes page for quick reference.” The full URL is https://example.org/notes/first-page?view=compact#intro. The domain is example.org. The path is /notes/first-page, the query is view=compact, and the fragment is intro. This card is not a technical requirement from any specification; it is simply a way to keep your own planning organized.

Record one card per address rather than trying to list everything in a single block of text. If your project will eventually have five or ten pages, each card stays small and easy to review. You can store these cards in a plain text file, a spreadsheet, or even a note-taking application. The format matters less than the consistency of recording the same fields for every address.

Including the purpose field may feel redundant when you are the only person working on the project, but it becomes valuable the moment you need to explain your site structure to someone else or return to it after a break. A one-sentence purpose description reminds you why that particular path and query combination exists, which reduces confusion when you revisit the plan weeks later.

Verifying Your Description Card by Manual Copying and Labeling

Before you consider your description card complete, verify it by copying the full URL from your card and pasting it into a blank line. Then go through the string character by character and mark where each part begins and ends. This manual process catches typos, missing slashes, or misplaced question marks that are easy to overlook when you are reading quickly.

Check that the scheme is present and correctly spelled. Confirm that the domain portion matches what you intended, paying attention to the dot between the label and the TLD. Verify that the path starts with a forward slash immediately after the domain. If a query is present, confirm that it begins with a question mark and that each key-value pair uses an equals sign. If a fragment is present, confirm that it begins with a hash sign and appears after any query.

Record any discrepancy you find directly on the card rather than fixing it only in your memory. If the original card said /notes/first-page but the copied string shows /notes/firstpage, note the correction and update the card. This habit builds a reliable reference you can trust later without re-checking everything from scratch.

Step 1

Copy the full URL from your description card into a new blank line in the same document.

Step 2

Mark the boundary between the scheme and the domain by locating the :// pattern.

Step 3

Mark the boundary between the domain and the path by locating the first forward slash after the domain.

Step 4

If a question mark is present, mark it as the start of the query string and verify each key-value pair.

Keeping Your Address Record for Future Writing and Communication

Once your description cards are verified, keep them in a location you will actually revisit. A dedicated folder in your project directory or a pinned note in your preferred application both work well. The goal is not to create a formal document but to have a reliable place where the address details live alongside your other planning materials.

When you write content that links to your own pages, refer back to these cards rather than typing addresses from memory. This reduces the chance of introducing a typo into a live link. If you collaborate with others, sharing the relevant card gives them the exact address without ambiguity, which is especially useful when paths contain multiple segments or query parameters.

Over time you may choose to add fields to your cards, such as the date you created the page or a note about which content version the address corresponds to. These additions are entirely up to you. The core value of the practice is that you have a single, checked reference for each address, and you can extend it in whatever direction serves your workflow.

Frequently asked questions

Is a domain name the same thing as a URL?

No. A domain name identifies a web server in a human-readable form, while a URL is the full address of a specific resource on that server. A URL includes the domain name plus additional parts such as the scheme, path, query, and fragment.¹²

Does the fragment part of a URL get sent to the server?

No. The fragment identifier, which is the part after the hash sign, is never sent to the server with the request. It is used by the browser to scroll to a bookmarked spot within the resource itself.²

Do I need to include a query string in every URL I plan?

No. Query strings are optional. You only need them when you want to pass extra parameters to the web server. A URL with just a scheme, domain, and path is perfectly valid.²