When you prepare to launch a personal website or a small project site, you will encounter two related but distinct concepts: the domain name and the full URL. Confusing them can lead to miscommunication with collaborators or mistakes in documentation. This article uses a single hypothetical address to show how each part works and how you can record the breakdown for your own reference.
What Question Does Each Part Answer?
Suppose you are setting up a small reading-notes project and you want to share a specific page with a friend. You type an address into the browser and send it along. The address you share is a full URL, but the domain name inside it answers a different question than the rest of the string. A domain name identifies which server on the Internet you want to reach. Domain names provide a human-readable address for any web server available on the Internet, because the numeric IP addresses that computers actually use are hard for people to remember and may change over time.1
A full URL goes further. It is the address of a unique resource on the internet and tells the browser not only which server to contact but also which specific resource to retrieve from that server. A URL is composed of different parts, some mandatory and others optional, and together they give the browser enough information to fetch one particular page, image, or document rather than just the site's front door.2
In our hypothetical example the full address is https://example.org/notes/first-page?view=compact#intro. This address is invented purely for the exercise of breaking the string into labeled pieces; it does not point to a real, live page. Keeping that premise in mind, we can now examine what each segment contributes.
Labeling the Parts of the Example Address
The first segment, 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 HTTP. In our example the presence of https tells the browser to use the secure version of the protocol when contacting the server.2
The next segment, example.org, is the domain name. It sits inside what the URL specification calls the authority section, which is separated from the scheme by the character pattern ://. The domain indicates which web server is being requested. The structure of a domain name is made of several parts separated by dots and read from right to left. In example.org, the rightmost part org is the top-level domain, and example is the label that precedes it.12
After the domain comes the path, /notes/first-page. The path identifies the resource on the web server. In our hypothetical address it suggests a page called first-page located inside a section called notes, though we are only reading the string structure here, not making claims about any actual server behavior. Following the path, the question mark introduces the query string view=compact. Query parameters are extra key-value pairs provided to the web server, and the question mark is the delimiter that signals their start. Finally, the hash sign introduces the fragment identifier intro. The fragment represents a sort of bookmark inside the resource, giving the browser directions to show content 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.2
Comparing Strings with the Same Host
To see how the parts differ in practice, keep the host portion example.org unchanged and vary the rest. Imagine a second address: https://example.org/notes/second-page?view=full. The scheme and domain are identical, so the browser would contact the same server. The path now points to a different resource, second-page instead of first-page, and the query parameter has a different value, full instead of compact. These are purely string-level observations; we are not inferring what any server would actually return.
Now consider a third variation: https://example.org/notes/first-page#summary. Here the path is the same as our original example, the query string is absent, and the fragment has changed from intro to summary. Removing the query string means no extra parameters are appended after the question mark, because there is no question mark at all. Changing the fragment would direct the browser to a different bookmark within whatever resource the server returns for that path. Again, this is a structural observation about the string, not a prediction of server behavior.
These comparisons illustrate a useful principle: the domain name stays constant across all pages of a site, while the path, query, and fragment change to locate different resources or positions within those resources. When you document addresses for your own project, noting which parts remain fixed and which parts vary helps you communicate clearly with collaborators who may only need the domain or who may need the full URL to a specific section.
Building an Address Description Card
Write down a short card for each important address in your project. For our hypothetical reading-notes site the card might contain four lines. The first line states the purpose: sharing a specific reading-notes page in a compact display mode. The second line records the full address exactly as it appears: https://example.org/notes/first-page?view=compact#intro. The third line lists the parts: scheme https, domain example.org, path /notes/first-page, query view=compact, fragment intro. The fourth line notes any context, such as the fact that this is a hypothetical example used for learning purposes.
Record the card in a format you will actually revisit. A plain-text file inside your project folder, a note in a wiki, or a row in a spreadsheet all work. The format matters less than the habit of writing the breakdown next to the raw string. When you later need to explain the address to a collaborator or troubleshoot a link, having the labeled parts beside the full string saves you from re-analyzing it from scratch.
If your project has several pages worth sharing, make one card per address. Over time the collection becomes a small reference that shows which paths your project actually uses, which query parameters appear, and whether any fragments are defined. This is a documentation habit, not a technical requirement, but it tends to reduce confusion when multiple people work on the same site.
Verifying the Card by Hand
Check your card against the original string by copying the address character by character into a blank line and then marking each boundary. Start at the left: everything before :// is the scheme. Between :// and the first single slash that follows the domain is the authority, which in our case is just example.org with no port number shown. From that first slash up to the question mark is the path. Between the question mark and the hash sign is the query. After the hash sign is the fragment.
Use a highlighter or a different text color for each segment if you are working in a visual editor. This makes mismatches obvious at a glance. For instance, if you accidentally include the question mark inside the path or forget that the fragment starts after the hash rather than including it, the color boundary will look wrong. This is a simple proofreading technique, not a formal validation tool, but it catches the most common transcription errors.
Compare your labeled parts with the definitions you recorded on the card. If the card says the query is view=compact but your highlighted segment shows view=compact&sort=date, one of them is wrong. Resolve the discrepancy before you share the address with anyone else. This manual check takes only a minute and prevents the kind of small mistake that leads a collaborator to the wrong page or a broken bookmark.
Keeping the Record for Future Use
Store the finished card somewhere you will find it again when the project evolves. If you later add new pages, you can copy the card format and fill in the new path, query, and fragment without re-deriving the structure. If a collaborator asks what a particular address means, you can point to the card instead of explaining from memory.
You may also find the card useful when writing documentation, drafting social media posts that link to your site, or setting up redirects. In each of those situations you need to know which part of the address is stable and which part might change. The domain rarely changes once chosen, but paths and queries can shift as you reorganize content. Having a written record makes those decisions visible rather than implicit.
The choice of where and how to keep these records is entirely yours. Some people prefer a dedicated markdown file in a repository; others keep a simple text document alongside their site files. The important point is that the breakdown exists in a retrievable form, so that the next time you or someone else needs to reason about the address, the work has already been done.
Frequently asked questions
Is a domain name the same thing as a URL?
No. A domain name identifies the server you want to reach, while a URL is the complete address that also specifies the protocol, path, and optionally a query and fragment. The domain name is one component inside a full URL.12
Does the fragment part after the hash sign 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 already-retrieved resource.2
Do I need to include the port number in my URL?
Usually not. The port is typically omitted when the web server uses the standard ports of the HTTP protocol, which are 80 for HTTP and 443 for HTTPS. You only need to include it explicitly if the server uses a non-standard port.2