Domain Names and URLs: Understanding Website Addresses Before Launch

When you prepare your first website, the address bar string looks like one continuous line of text. In reality it is built from several distinct parts, each answering a different question. This article uses one hypothetical address to show what each part means and how you can keep a clear record of your own.

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

Imagine you are setting up a small project site and someone asks where it lives on the internet. The shortest useful answer is a domain name. A domain name is a human-readable address for a web server. Computers on the internet are reached through numeric IP addresses, which are difficult for people to remember and may change over time, so domain names exist to give people a stable, memorable label for a server.¹²

Now suppose that same person wants to find a specific page on your site, not just the server itself. That question requires a full URL. A URL is the address of a unique resource on the internet. It includes the domain name but adds further instructions that tell the browser which protocol to use, which file or endpoint to request, and optionally which part of the document to display.³

So the two concepts answer different questions at different levels of specificity. A domain name identifies the server. A URL identifies a particular resource on that server. For the rest of this article we will work with a single hypothetical address to see how the parts fit together. This address is purely for illustration and does not point to a real, published page.

Labeling Every Part of the Hypothetical Address

Our working example is https://example.org/notes/first-page?view=compact#intro. Read it from left to right and you can separate five components. The scheme is https, which tells the browser to use the secure version of the Hypertext Transfer Protocol. The authority is example.org, which is the domain name of the server being requested. In most web URLs the port is omitted because the server uses the standard port for HTTPS, so here the authority consists of just the domain.³

After the authority comes the path: /notes/first-page. The path tells the server which resource to return. The question mark that follows introduces the query string, which contains parameters the server can read. In our example the parameter is view=compact, a single key-value pair. Finally, the hash sign introduces the fragment identifier, which in this case is intro. The fragment points to a specific location within the resource itself rather than requesting something new from the server.³

Looking at the domain name portion more closely, example.org is itself made of two labels separated by a dot. The label org is the top-level domain, which is the most generic part of the domain hierarchy. The label example is the second-level domain. Together they form a fully qualified domain name, and adding the scheme https:// turns the whole string into a complete URL.⁴

Comparing Different Paths and Queries on the Same Host

Keep the host portion fixed at example.org and change only the path. The address https://example.org/notes/first-page and the address https://example.org/notes/second-page share the same domain, the same scheme, and the same top-level directory, but they point to different resources. The path is what distinguishes them. You can think of the domain as the building and the path as the room number inside it.

Now add a query string. The address https://example.org/notes/first-page?view=compact and the address https://example.org/notes/first-page?view=full share the same domain and the same path, but they carry different parameters. The question mark is the delimiter that signals the start of the query. Each parameter is a key-value pair, and multiple pairs would be separated by ampersands. The server may use these parameters to change what it returns, but the exact behavior depends entirely on how that particular server is configured.

Finally, consider the fragment. The address https://example.org/notes/first-page#intro and the address https://example.org/notes/first-page#summary point to the same resource on the server, but they ask the browser to scroll to different spots within that resource. The fragment is never sent to the server with the request; it only affects what the browser displays after the resource arrives. This distinction matters when you are planning links: changing the fragment does not create a new server-side resource, while changing the path or query may.

Building an Address Description Card for Your Hypothetical Project

Record a short card that captures the purpose of your address, the full string, and a breakdown of each component. For our hypothetical project the card might read: Purpose is to demonstrate a reading-notes page. Full address is https://example.org/notes/first-page?view=compact#intro. Scheme is https. Domain is example.org. Path is /notes/first-page. Query is view=compact. Fragment is intro.

The value of this card is not in memorizing the terms but in having a single reference you can check later. When you write documentation, share a link with a collaborator, or troubleshoot a broken address, you can look at the card and quickly identify which part might be wrong. If a link loads the wrong page, the path is the first place to check. If the page loads but shows the wrong view mode, the query parameter is the suspect. If the page loads correctly but does not scroll to the expected section, the fragment is likely the issue.

You do not need any special tool to make this card. A plain text file, a note in your project wiki, or even a handwritten sticky note works fine. The important thing is that every part of the address is labeled with its role, not just copied as a raw string. This habit becomes more useful as your site grows and you manage more addresses.

Verifying Your Card by Hand-Copying and Labeling

Check your address card against the actual string by copying the full URL character by character into a blank line. Do not rely on autocomplete or paste shortcuts for this exercise; the point is to notice every delimiter. As you copy, pause at each special character: the colon and double slash after the scheme, the first slash of the path, the question mark, the equals sign inside the query, and the hash sign before the fragment.

Write a short label above or beside each segment. For the scheme, write the protocol name. For the domain, write the full domain name. For the path, note which directory level each slash introduces. For the query, write the parameter name and its value separately. For the fragment, write what section of the page it targets. This labeling step turns a single opaque string into five understandable pieces.

Use a second pass to confirm that your labels match the rules. The scheme must appear before the colon-slash-slash separator. The domain must appear between that separator and the next slash. The path begins with a slash and continues until a question mark, a hash, or the end of the string. The query begins at the question mark and continues until a hash or the end. The fragment begins at the hash and continues to the end. If any label does not fit these boundaries, you have found a mistake in your card.

Step 1

Copy the full URL by hand into a blank line, pausing at each delimiter character.

Step 2

Write a role label beside each segment: scheme, domain, path, query, fragment.

Step 3

Confirm that each label sits between the correct delimiters according to the rules above.

Keeping Your Record for Future Writing and Communication

Store the finished card somewhere you will actually look at it. If you keep a project notebook, paste it on the first page. If you use a digital note tool, pin it to the project workspace. The goal is not to build a database of addresses but to have one reliable reference for the addresses you currently care about. As your site grows you can add more cards, one per important page or endpoint.

When you share an address with someone else, refer to your card to decide how much detail to include. A casual mention might only need the domain. A technical instruction might need the full URL including the query. A support request might need you to specify which fragment you expected to see. Having the breakdown already written saves you from re-parsing the string under pressure.

Over time this practice builds an intuitive sense for how addresses work. You will start noticing patterns: which parameters your site actually uses, which fragments correspond to which sections, and which paths tend to change as you restructure content. That intuition is the real payoff. The card is just the scaffold that helps you get there.

Frequently asked questions

Is the domain name the same thing as the URL?

No. A domain name identifies the server, while a URL identifies a specific resource on that server. A URL contains the domain name plus additional parts such as the scheme, path, query, and fragment.¹³

Does changing the fragment after the hash sign request a different page from the server?

No. The fragment identifier is never sent to the server with the request. It only tells the browser where to scroll or position itself within the resource that has already been loaded.³

Do I need to include the port number every time I write a URL?

In most cases, no. If the web server uses the standard port for its protocol, the port is omitted from the URL. You only need to include it when the server uses a non-standard port.³