When you prepare a website for the first time, two terms appear constantly: domain name and URL. They look similar but answer different questions about your address. This article uses one hypothetical string to show what each part means and how you can record it clearly before launch.12
What Domain Names and Full URLs Each Answer
Imagine you are setting up a small personal project and someone asks what your website address is. You might say example.org. That is a domain name. Domain names are a key part of the Internet infrastructure. They provide a human-readable address for any web server available on the Internet. Computers locate servers through IP addresses, but people find those numeric sequences difficult to remember and they may change over time. A domain name solves that problem by giving you a readable label for the server you want to reach.1
Now suppose the same person asks which page on your site they should read first. You would need something more specific than just the domain name. A URL (Uniform Resource Locator) is the address of a unique resource on the internet. It is one of the key mechanisms used by browsers to retrieve published resources such as HTML pages, images, and documents. A full URL tells a browser not only which server to contact but also which specific resource to retrieve from that server.2
So the domain name answers the question “which server?” while the full URL answers “which exact resource on that server?” For our hypothetical project, example.org is the domain name, and https://example.org/notes/first-page?view=compact#intro is a complete URL pointing to one particular resource. This address is used purely as an illustration for breaking down the string. It does not claim that this page actually exists or is currently live anywhere.12
Labeling Each Part of the Example Address
Write the full address on a blank line so you can examine each segment: https://example.org/notes/first-page?view=compact#intro. 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 ://.2
The next part, example.org, is the domain name within the authority section. A domain name has a simple structure made of several parts separated by dots and read from right to left. The rightmost part, org, is the top-level domain or TLD. TLDs tell users the general purpose of the service behind the domain name. The label to its left, example, is the second-level domain. Together these form the host that identifies which web server is being requested.13
After the domain comes the path: /notes/first-page. The path represents the location of the resource on the web server. Following the path, the question mark introduces the query string: view=compact. Parameters are extra key-value pairs provided to the web server, and the question mark always signals where they begin. Finally, the hash symbol introduces the fragment: intro. An anchor represents a sort of bookmark inside the resource, giving the browser directions to show the content located at that bookmarked spot. The part after the hash is never sent to the server with the request.2
Comparing Paths and Queries on the Same Host
Keep the host part of our example unchanged and observe what happens when you alter other components. If you change the path from /notes/first-page to /notes/second-page, you are pointing to a different resource on the same server. The domain name and scheme stay identical, but the browser would request a different location. You can observe this simply by reading the string; no server behavior needs to be assumed for this comparison.
Similarly, if you change the query from view=compact to view=full, the path remains the same but the extra parameter differs. The question mark always marks the boundary between the path and the query portion. Each key-value pair in the query is separated by an ampersand when there are multiple parameters. In our example there is only one pair, so no ampersand appears. Changing the fragment from intro to summary would likewise leave the path and query untouched while pointing the browser to a different bookmarked spot within the same resource.
Removing the fragment entirely also changes the string. Without the hash and the word intro, the browser would not attempt to scroll to any particular position within the resource. All these variations share the same domain name, which means they all target the same server. The differences lie entirely in what comes after the host. Noting these distinctions helps you describe addresses precisely when communicating with collaborators or writing documentation for your project.
Building an Address Description Card
Record the purpose of your hypothetical project in one short sentence. For instance, you might write: “This page collects my reading notes and displays them in a compact layout.” Keeping the purpose statement brief makes it easy to check later whether the address you chose still matches what the page actually does. If your project grows and the page changes its role, you can update the purpose line and compare it against the address structure.
Next, write the complete address exactly as you intend it to appear: https://example.org/notes/first-page?view=compact#intro. Below that line, list each component with a short label. Scheme: https. Domain: example.org. Path: /notes/first-page. Query: view=compact. Fragment: intro. This list is your address description card. It gives you a single reference you can share with a collaborator, paste into a project file, or keep in a notes document.
You may also want to add a brief note about which parts you expect to stay stable and which might change as the project evolves. For example, the domain name is likely to remain fixed once chosen, but paths and query parameters might shift as you add pages or adjust display options. Writing down these expectations now saves you from confusion later when you revisit the card after several weeks of work.
Verifying the Card by Hand
Manual verification is a simple habit that catches typos and mismatched labels before they cause confusion. The process requires no tools beyond a text editor and a few minutes of attention. Treat it as a final check before you share the address with anyone or embed it in another document.
After you complete the steps, compare your labeled copy against the original card. If every segment matches in spelling, punctuation, and order, the card is consistent. If anything differs, correct the card and repeat the process once more. This loop takes only a minute but prevents the kind of small errors that lead to broken links or misdirected readers.
Check the fragment separately by confirming that the hash symbol appears after the question mark and its value. In our example, intro comes after the hash and after the query view=compact. If you accidentally placed the fragment before the query, the meaning of the string would change. This is a common mistake when copying addresses by hand, so a dedicated check for the order of question mark and hash is worthwhile.
Step 1
Copy the full address from your description card into a new blank line in your text editor. Do not retype it from memory; use a direct copy to avoid introducing new errors at this stage.
Step 2
Starting from the left, mark each boundary. Place a space or a slash mark after https://, after example.org, before the question mark, and before the hash. You now have five visible segments on your line.
Step 3
Label each segment in order: scheme, domain, path, query, fragment. Write the label directly above or below the corresponding text so the mapping is visually clear.
Step 4
Compare your labeled line against the original card entry character by character. Pay special attention to the position of the question mark and the hash, since swapping their order changes the meaning of the string.
Keeping the Record for Future Use
Store the completed description card somewhere you will naturally find it when the project resumes. A plain text file inside your project folder works well because it travels with the rest of your materials. You can also paste it into a wiki page, a shared document, or a note-taking tool that your team already uses. The format matters less than the consistency of keeping it alongside the project it describes.
When you later write content that references this page, such as a blog post, an email to a collaborator, or a link in another site, you can return to the card and copy the exact address rather than reconstructing it from memory. This reduces the chance of dropping a query parameter or misspelling a path segment. The card also helps you explain the address to someone unfamiliar with URL structure, because the labeled breakdown is already written out.
Over time you may decide to simplify the address, remove the query string, or reorganize paths. When that happens, update the card first and then propagate the change to every place the old address appeared. Because the card lists each component separately, you can quickly see which parts changed and which stayed the same, making the update process more straightforward than if you had only a bare URL with no annotations.
Frequently asked questions
Is the domain name the same thing as the URL?
No. A domain name identifies the server, while a URL is the complete address of a specific resource on that server. The URL includes the scheme, domain, path, and optionally a query and fragment. The domain name is only one component within the full URL.12
Why does the fragment part after the hash never reach the server?
The fragment identifier is used by the browser to locate a position within the already-loaded resource. Because it only affects what the browser displays after receiving the resource, it is never included in the request sent to the server.2
Do I need to include the scheme when sharing my address with others?
In most cases browsers will assume HTTP or HTTPS if you omit the scheme, so you can share just the domain and path in casual conversation. However, when embedding the address in code, documentation, or a description card, writing the full scheme avoids ambiguity and makes the record complete.2