Domain Names and URLs: Understanding Website Addresses Before Launch

When you prepare your first website, you will meet two closely related concepts: domain names and URLs. Knowing what each one tells you—and how they combine inside a complete address—helps you plan pages, write links, and talk about your project with confidence before anything goes live.

What Domain Names and URLs Each Tell You

Suppose you are sketching out a small personal notes project and you write down the address https://example.org/notes/first-page?view=compact#intro on a sticky note. This is a hypothetical string used purely for practice; it does not point to a real page that exists or is published anywhere. Even so, it contains every major component you will encounter in a genuine web address, which makes it a useful starting point for learning the vocabulary.

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

A full URL answers a more specific question: “which resource on that server do I need?” 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 stylesheets. In our example the full URL is the entire string from https to #intro. It narrows the broad destination given by the domain name down to one particular spot.²

Reading the Example Address Piece by Piece

The first token in our string is https, which is called the scheme. The scheme indicates the protocol that the browser must use to request the resource. For ordinary websites the protocol is HTTPS or its unsecured counterpart HTTP. In our hypothetical address, https tells a browser to use a secure connection when it eventually contacts the server.²

After the scheme and the separator ://, the next part is the authority, and in our example the domain portion of that authority is example.org. This is the host that will handle the request. Following the host comes the path /notes/first-page. A path like this originally represented a physical file location on a server; nowadays it is mostly an abstraction handled by web servers without any physical reality. The path still serves as a label that distinguishes one resource from another on the same host.²

Two more components appear after the path. The question mark introduces the query string, which in our example is view=compact. Query parameters are extra key-value pairs provided to the web server, and the server can use them to adjust what it returns. The hash sign introduces the fragment, which here is intro. A fragment represents a sort of 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; it is handled entirely on the client side.²

Same Host, Different Paths and Queries

Now keep the host portion example.org fixed and imagine a second address: https://example.org/notes/second-page?view=compact#intro. The only change is the path, which shifts from first-page to second-page. The scheme, host, query, and fragment remain identical in their positions and syntax. This illustrates that each component of the string is independent; editing one part does not automatically alter the others.

Next, change the query while leaving everything else as it was in the original example: https://example.org/notes/first-page?view=full#intro. The string now carries a different parameter value. We can observe that the text differs, but we should not leap to conclusions about what the server actually does with view=full versus view=compact. Each web server has its own rules regarding parameters, and the only reliable way to know whether a specific server is handling parameters is by asking the server owner.²

Finally, remove the fragment entirely: https://example.org/notes/first-page?view=compact. The address is still valid and still points to the same resource on the same host with the same query. The fragment was optional. These small variations show that a URL is a structured string where each delimiter—the question mark, the ampersand, the hash—marks a boundary between components. Recognizing those boundaries lets you read and edit addresses without guessing.

Building an Address Description Card

Record a short description card for each address your project will use. For the hypothetical notes project, the card might have four lines: a purpose line stating what the page is for, a full-address line copying the complete URL exactly as written, a parts line listing scheme, host, path, query, and fragment separately, and a notes line for anything you want to remember later, such as why you chose that particular path name.

Write the card in whatever format feels natural—a plain-text file, a note in your favourite app, or a row in a spreadsheet. The important thing is that the full address appears exactly once, character for character, so you always have a single reference copy. If you later need to change the path or add a query parameter, you edit the card first and then update any links that point to that address.

Keeping the parts separated on the card also helps when you communicate with a collaborator. You can say “the host stays the same, only the path changes” instead of pasting two long strings and asking someone to spot the difference. This habit costs almost nothing during the planning stage and saves confusion once the project grows beyond a single page.

Verifying Your Card by Hand

A quick manual check catches typos and misplaced delimiters before they cause confusion. The process is deliberately simple and requires no special tools.

Check each delimiter in order: confirm the scheme ends with a colon, the authority begins with two slashes, the path begins with a single slash, the query begins with a question mark, and the fragment begins with a hash. If any delimiter is missing or in the wrong position, the card needs a correction.

Compare your card against the original source of the address—if a teammate sent it in a message, open that message side by side. This final pass ensures nothing was lost during transcription.

Step 1

Copy the full address from your description card into a blank text editor line by itself.

Step 2

Mark each boundary with a visible symbol: place a space before and after every question mark, hash, and the :// separator so the parts become visually distinct.

Step 3

Read each isolated part and confirm it matches what your card says for that component. If the path on the card reads /notes/first-page but the isolated text shows /notes/firstpage, you have found a discrepancy to fix.

Keeping the Record for Future Use

Once your description card is verified, store it somewhere you will actually look. If you are drafting content for the site, keep the card open while you write internal links so the paths you type match the paths you planned. If you are sharing the project with a friend or collaborator, the card gives you a concise summary you can paste into a message without re-explaining every component from scratch.

As your project grows, you can add one card per page or per section. The format stays the same; only the values change. Because each card isolates the host from the path and query, you can quickly see which pages share a common host and which ones differ, making it easier to spot naming inconsistencies across the site.

The choice of how detailed your notes become is entirely yours. Some people add a column for the date they last checked the address; others keep only the four lines described above. The goal is not to build a database but to have one reliable place where the address and its meaning are written down together, so you never need to reconstruct an address from memory alone.

Frequently asked questions

Is example.org a real website I can visit?

No. The address https://example.org/notes/first-page?view=compact#intro is used in this article purely as a hypothetical string for practising how to read URL components. It does not point to a published page.

Does changing the query string always change what appears on the page?

Not necessarily. The query string is sent to the server, but each server decides how to handle parameters. Two different query values might return identical content, or they might return different views. The URL alone does not guarantee a visible difference.²

Do I need to include the fragment when I share a link with someone?

It depends on whether you want the recipient to land at a specific spot within the page. The fragment is optional and is never sent to the server; it only tells the browser where to scroll. If you omit it, the recipient will still reach the same resource, just starting from the top.²