Before you publish a website, you will encounter two closely related terms: domain name and URL. They look similar but answer different questions. This article walks through one hypothetical address string piece by piece so you can see exactly what each part does and how to keep a clear record of it.
What Domain Names and URLs Each Answer
Domain names exist because computers on the Internet are reached through numeric IP addresses that are difficult for people to remember and that can change over time. A domain name provides a human-readable address for a web server, so that visitors can type something meaningful instead of a string of numbers. Domain names are made of several parts separated by dots and read from right to left, with the top-level domain on the right giving a general clue about the service behind the name.1
A URL, short for Uniform Resource Locator, goes one step further. It is the address of a unique resource on the Internet and includes not only the domain but also a scheme, a path, and optionally parameters and an anchor. In theory each valid URL points to a unique resource. The scheme tells the browser which protocol to use, the authority section names the server, and the remaining parts narrow down which specific resource on that server is being requested.2
To make these ideas concrete, this article uses one hypothetical address: https://example.org/notes/first-page?view=compact#intro. This address is purely illustrative; it is not a live page and does not need to resolve anywhere. We will treat it as a string to dissect so that every component becomes visible and nameable.
Breaking Down the Example Address
The first token in our example is https. This is the scheme, which indicates the protocol the browser must use to request the resource. For websites the protocol is typically HTTPS or its unsecured version HTTP. The scheme is always followed by the separator :// before the next part begins.2
Immediately after the separator comes example.org. This is the domain name, the human-readable identifier for the server. It consists of two labels separated by a dot: the label example and the top-level domain org. The top-level domain is the final component and gives a general clue about the purpose of the service.13
After the domain comes /notes/first-page. This is the path to the resource on the web server. In modern practice the path is mostly an abstraction handled by web servers rather than a literal file location, but it still tells the server which resource is being requested. Next comes ?view=compact. The question mark signals the start of the parameters section. Here there is one key-value pair: the key is view and the value is compact. Parameters are extra pieces of information provided to the web server, and multiple pairs would be separated by the ampersand symbol. Finally, #intro marks the anchor, also called the fragment identifier. The hash sign always introduces this part. The fragment is never sent to the server with the request; it gives the browser directions to show content at a bookmarked spot within the resource itself.2
Same Host, Different Paths and Queries
Keeping the scheme and domain unchanged, consider what happens when only the path or query string differs. The address https://example.org/notes/first-page?view=compact#intro and the address https://example.org/notes/second-page?view=compact#intro share the same host but point to different paths. The string /notes/second-page identifies a different resource location than /notes/first-page, even though every other component remains identical.
Now change only the query string: https://example.org/notes/first-page?view=full#intro. The path is the same, but the parameter value has shifted from compact to full. From the string alone you can observe that a different value is being passed to the server. What the server actually does with that value depends entirely on the server's own rules, which are not visible in the address itself. The URL standard only guarantees that the parameters section carries key-value pairs; it does not prescribe how any particular server interprets them.2
Finally, remove the fragment entirely: https://example.org/notes/first-page?view=compact. The hash and the word intro are gone. Because the fragment is never sent to the server, removing it does not change what the server receives. It only changes whether the browser attempts to scroll to a bookmarked position within the returned resource. These small variations show that each part of the string carries a distinct role, and changing one part does not necessarily affect the others.2
Creating an Address Description Card
Record the purpose of your hypothetical project in one short sentence before you write down any address components. For this exercise, the purpose might be: a personal notes page that displays a compact view of the first entry. Writing the purpose first helps you check later whether each part of the address actually supports that goal.
Next, write the full address on its own line exactly as you intend it to appear: https://example.org/notes/first-page?view=compact#intro. Below it, list each component with a label. Scheme: https. Domain: example.org. Path: /notes/first-page. Query: view=compact. Fragment: intro. This simple card gives you a reference you can share with a collaborator or revisit when you are editing content.
If your project will eventually have more than one page, add a row for each additional address following the same format. Keeping all addresses in one place makes it easier to spot inconsistencies, such as a path that uses a different naming pattern or a query parameter that appears on one page but not another. The card is a working document, not a final specification, so feel free to revise it as your project takes shape.
Verifying the Card by Hand
Check your address card by copying the full URL character by character into a plain-text editor. Do not paste from a formatted document, because hidden formatting characters can introduce errors that are invisible at a glance. Once the string is in plain text, place a space or a vertical bar before each boundary: after the scheme separator, after the domain, before the question mark, and before the hash sign.
Label each segment directly above or below it. Write scheme above https, domain above example.org, path above /notes/first-page, query above view=compact, and fragment above intro. Compare these labels against the definitions you recorded on your card. If any label does not match, correct the card before moving on.
Repeat this labeling exercise for every address on your card. The repetition builds familiarity with the structure, and doing it by hand rather than relying on automated tools means you will notice subtle differences such as a trailing slash, a missing parameter, or a fragment that was accidentally left out. This is ordinary author practice, not a technical requirement, but it catches mistakes early when they are still easy to fix.
Keeping the Record for Future Use
Store your address description card in a location you already check regularly, such as a project readme file or a dedicated notes folder. The value of the card is not in creating it once but in having it available when you write documentation, share a link with a collaborator, or troubleshoot why a page is not loading as expected.
When your project grows, update the card each time you add or rename a page. Treat the card as a living inventory. If you remove a page, note that on the card so you do not accidentally link to a resource that no longer exists. The URL standard acknowledges that in practice some URLs point to resources that have moved or disappeared, and the server owner is responsible for managing those changes.2
You may also find it useful to record why you chose a particular path name or query parameter. For instance, noting that view=compact was chosen to reduce visual clutter on small screens gives future-you or a collaborator the reasoning behind the decision. These brief annotations turn a simple address list into a lightweight design record that supports communication without requiring a formal specification document.
Frequently asked questions
Is a domain name the same thing as a URL?
No. A domain name identifies the server using a human-readable name. A URL includes the domain name but also adds a scheme, a path, and optionally parameters and a fragment, making it the full address of a specific resource.12
Does the fragment part of a URL get sent to the server?
No. The fragment identifier, which appears after the hash sign, is never sent to the server with the request. It only tells the browser where to scroll or navigate within the returned resource.2
Can I change the query parameters without affecting the path?
Yes. Each part of a URL is independent in the string. You can change the query value while keeping the scheme, domain, path, and fragment identical. What the server does with the new value depends on its own rules.2