Before a website goes live, its address already carries meaning that affects how visitors find and use it. This article takes one hypothetical URL apart piece by piece so you can see exactly what each part does and why it matters when you plan your own project.
What Question Does a Domain Name Answer, and What Does a Full URL Answer?
Suppose you are preparing a small personal project site and you write down the address https://example.org/notes/first-page?view=compact#intro as a placeholder for planning purposes. This address is not a real page; it exists only so we can practice reading its structure. The first thing to notice is that the address contains two different levels of information. The domain name portion, example.org, answers a broad question: which server on the Internet should handle this request? Domain names provide a human-readable address for any web server available on the Internet, because computers communicate through numeric IP addresses that are difficult for people to remember or associate with a particular service.1
A full URL answers a much more specific question: which exact resource on that server should the browser retrieve? A URL is the address of a unique resource on the internet, and it is one of the key mechanisms used by browsers to retrieve published resources such as HTML pages, CSS documents, and images. So while the domain name points to the building, so to speak, the full URL specifies the room, the shelf, and even the paragraph you want to read.2
In our hypothetical example, example.org identifies the server, but the rest of the string narrows the request down to a particular page, a particular display preference, and a particular spot within that page. Understanding this distinction helps you see why two URLs sharing the same domain can lead to completely different content. The domain is the shared starting point; everything after it adds specificity.12
Labeling Each Part of the Example Address
Let us mark each segment of https://example.org/notes/first-page?view=compact#intro in order. The string https is the scheme, which indicates the protocol the browser must use to request the resource. For websites the protocol is usually HTTPS or its unsecured version HTTP. The characters :// separate the scheme from the authority section that follows.2
Next comes example.org, the domain name, which is part of the authority. The authority indicates which web server is being requested. After the domain, the path /notes/first-page tells the server which resource to return. In the early days of the web a path represented a physical file location on the server, but nowadays it is mostly an abstraction handled by web servers without any physical reality. The question mark ? introduces the query section, which in this case is view=compact. Query parameters are extra key-value pairs provided to the web server, and the server can use them to do additional processing before returning the resource. Finally, the hash symbol # introduces the fragment, here called intro. An anchor represents a sort of bookmark inside the resource, giving the browser directions to show the content located at that bookmarked spot.2
Two punctuation marks deserve special attention because they change the meaning of everything that follows. The question mark signals the start of query parameters; everything between the question mark and the hash (or the end of the string) belongs to the query. The hash signals the start of the fragment identifier; the fragment is never sent to the server with the request, which means it only affects what the browser displays locally. Keeping these two delimiters straight prevents a common mistake: accidentally placing a parameter after the hash, where the server would never see it.2
Same Host, Different Paths and Queries
Now keep the host portion example.org unchanged and vary only the path. If you write /notes/second-page instead of /notes/first-page, you are pointing to a different resource on the same server. The domain has not changed, so the browser will contact the same machine, but the path tells that machine to serve different content. This is the most basic way a single domain can host many distinct pages.
Next, keep the path the same and change the query. Writing ?view=full instead of ?view=compact keeps the same resource but asks the server to handle the request differently. Because each web server has its own rules regarding parameters, you cannot assume from the URL alone what the server will actually do with view=full. The string tells you what is being requested; it does not guarantee what will be returned. This distinction matters when you are documenting addresses for a project: record what the URL says, not what you think the server will do.2
You can also remove the fragment entirely. Without #intro the browser would load the page from its default starting position rather than scrolling to a bookmarked section. Adding, removing, or changing the fragment does not alter what the server receives, because the fragment is never sent with the request. Observing these variations side by side makes the role of each segment concrete: the path selects the resource, the query adds optional instructions, and the fragment positions the viewer within the already-retrieved resource.2
Building an Address Card for Your Hypothetical Project
Write down a short card that records three things about your project address: the purpose of the page, the full URL string, and a labeled breakdown of each part. For our hypothetical example the card might read: Purpose: display the first note in a compact reading view, scrolled to the introduction section. Full address: https://example.org/notes/first-page?view=compact#intro. Scheme: https. Host: example.org. Path: /notes/first-page. Query: view=compact. Fragment: intro.
This card serves as a single reference you can share with collaborators or revisit months later when the project has grown. Recording the purpose alongside the technical parts helps you catch mismatches early. If the stated purpose says the page shows a compact view but the query reads view=full, something is inconsistent and you can fix it before the site launches.
Choose a format that is easy to update. A plain text file, a table in a document, or even a note in a project management tool all work. The important thing is that the card lives somewhere you will actually look, and that each part is labeled with the same vocabulary you used when dissecting the URL. Consistent labels reduce confusion when you later add more pages or parameters.
Verifying the Card by Hand
A quick manual check can catch typos and misplaced delimiters before they cause problems. The following steps are author suggestions for a simple verification routine that requires no special tools.
After completing the check, compare your labeled segments against the original string one more time. If every character is accounted for and each delimiter sits where you expect, the card is consistent. If not, correct the card and repeat the process. This habit takes only a minute but prevents the kind of small errors that become confusing later when you are writing documentation or sharing the address with others.
Check the scheme, host, path, query, and fragment in that order, confirming that each segment starts and ends at the correct delimiter. Specifically, confirm that the colon-slash-slash sequence immediately follows the scheme, that the first single slash after the host begins the path, that the question mark appears before any query content, and that the hash appears before any fragment content.
Step 1
Copy the full URL from your address card into a blank text file so you have an untouched reference.
Step 2
Mark each delimiter by hand: underline the :// sequence, circle the first / that begins the path, put a box around the ?, and put a box around the #.
Step 3
Read the segments between your marks aloud and compare them to the labels on your card. If a segment does not match, note the discrepancy.
Keeping the Record for Future Use
Record your address card in a place that survives the planning phase. Many first-time builders create useful notes during setup and then lose them once the site is live. Storing the card in the same repository or folder as your site files makes it easy to find when you write documentation, explain the project to a collaborator, or debug an unexpected behavior.
When your project grows beyond a single page, extend the card format to cover each new address. A consistent structure means you can scan a list of cards and quickly see which pages share the same host, which use query parameters, and which rely on fragments for navigation. This overview is especially helpful when you need to explain your site structure to someone who has not seen it before.
You may also find it useful to note your own recording choices: why you chose a particular format, whether you include the scheme in everyday references, and whether you treat fragments as part of the shareable address or as internal bookmarks. These decisions are personal and project-specific. Writing them down alongside the card gives future you the context needed to understand past choices without guesswork.
Frequently asked questions
Is the fragment part of a URL sent to the server?
No. The fragment identifier, which comes after the hash symbol, is never sent to the server with the request. It only tells the browser where to scroll or position the view within the already-retrieved resource.2
Can two URLs with the same domain point to different content?
Yes. The domain identifies the server, but the path, query, and fragment specify which resource and which view the browser should load. Changing any of those parts can lead to different content even though the domain stays the same.2
Do I need to include the scheme when sharing a URL with someone?
In a browser address bar you can usually omit the scheme because the browser defaults to HTTP. However, when documenting an address for reference or sharing it in written form, including the scheme makes the full URL unambiguous.2