When you prepare a website for the first time, the string in the address bar can look like one undifferentiated block of characters. Knowing which part names the server and which part points to a specific page helps you describe your project clearly, plan your site structure, and catch typos before anything goes live.
What Domain Names and Full URLs Each Answer
A domain name answers one question: which server on the internet are you trying to reach? Domain names provide a human-readable address for any web server available on the internet, solving the problem that numeric IP addresses are hard to remember and might change over time. When someone types example.org into a browser, the domain name is the part that tells the system which machine to contact.1
A full URL answers a broader question: which specific resource on that server do you want? A URL is the address of a unique resource on the internet and is one of the key mechanisms browsers use to retrieve published resources such as HTML pages, CSS documents, and images. Where the domain name narrows things down to one server, the rest of the URL narrows things down to one particular item on that server.2
For the rest of this article we will work with one made-up address: https://example.org/notes/first-page?view=compact#intro — this is a hypothetical string used only for practice and does not point to a real page or a live server. Treat it as a labeled specimen that you can take apart and reassemble without any risk.
Reading Each Part of the Example Address
The first segment, https, is the scheme. It indicates the protocol the browser must use to request the resource. For websites the protocol is usually HTTPS or its unsecured version HTTP. In our example the scheme tells the browser to use a secure connection when reaching the server.2
The next segment, example.org, is the domain name. It identifies which web server is being requested. 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, which tells users the general purpose of the service behind the domain name. The label example is what follows the TLD and distinguishes this particular domain from others under the same TLD.12
After the domain comes the path, /notes/first-page. The path represents the location of a resource on the web server. In the early days of the web a path like this represented a physical file location, but nowadays it is mostly an abstraction handled by web servers without any physical reality. You can still read it as a route that narrows down which content you are asking for.2
The Question Mark, the Hash Sign, and What They Introduce
Following the path in our example is ?view=compact. The question mark introduces the query portion of the URL. Query parameters are extra key-value pairs provided to the web server, and each web server has its own rules regarding how it handles them. Here view is the key and compact is the value. You cannot assume from the string alone what the server will do with this parameter; you can only observe that the string carries it.2
The final segment, #intro, begins with a hash sign and is called the fragment identifier or anchor. An anchor represents a sort of bookmark inside the resource, giving the browser directions to show the content located at that bookmarked spot. It is worth noting that the part after the hash sign is never sent to the server with the request. The fragment only matters once the resource has been loaded.2
To summarize the punctuation rules for this example: the question mark always signals the start of the query portion, and the hash sign always signals the start of the fragment. If a URL has both, the question mark comes first and the hash sign comes second. This ordering is fixed in the structure of the string regardless of what the server does with either part.2
Comparing Variations With the Same Host
Now keep the host part, example.org, exactly as it is and change only the path. If you write https://example.org/notes/second-page the domain and scheme stay identical, but the path now points to a different route. From the string alone you can tell the browser will ask the same server for a different resource. You cannot tell from the string whether that resource exists or what it contains.
Next, keep the path the same and change the query. Writing https://example.org/notes/first-page?view=full replaces the value compact with full. The server receives a different parameter value, but again the string itself only records the difference; it does not reveal how the server responds. You are comparing two strings and noting where they diverge, not predicting behavior.
Finally, remove the fragment entirely. The address https://example.org/notes/first-page?view=compact is valid without any hash sign. The fragment is optional. Each variation you write is a distinct string, and each distinct string could in principle point to a different resource or display state. Practicing these small substitutions helps you see which part of the address controls which layer of specificity.
Making an Address Description Card for Your Project
Write down a short card for each address your project will use. The card should contain three things: the purpose of the page in one plain sentence, the full URL string exactly as you intend it, and a labeled breakdown of each part. For our hypothetical example the purpose might read "first page of notes displayed in compact view, scrolled to the introduction section."
Record the breakdown in a simple list: scheme is https, domain is example.org, path is /notes/first-page, query key is view with value compact, and fragment is intro. Keeping the labels consistent across every card you make means you can compare cards side by side later without re-learning your own notation.
Choose a format that is easy to update. A plain text file, a spreadsheet row, or a note in your project management tool all work. The important thing is that the card lives somewhere you will actually look at it again, not buried in a draft you never reopen.
Verifying the Card by Hand
Once your card is written, verify it against the actual string using manual copying and item-by-item labeling. This catches typos, missing slashes, and misplaced punctuation that are easy to overlook when you composed the address from memory.
If every label matches, your card is consistent with the string. If any label does not match, correct the card or the string and repeat the check. This simple loop catches most transcription mistakes before they cause confusion.
Use this same verification routine whenever you add a new address to your project. The process takes only a minute per address and builds a habit of reading URLs carefully rather than guessing.
Step 1
Copy the full URL from your card and paste it into a blank line below. Do not retype it from memory; copy and paste so that the string on the verification line is character-for-character identical to what is on the card.
Step 2
Starting from the left, mark the scheme by writing the word scheme above https. Then mark the domain above example.org. Place a slash marker at the beginning of the path and write path above /notes/first-page. Circle the question mark and write query start above it, then label view=compact as the query content. Circle the hash sign and write fragment start above it, then label intro as the fragment.
Step 3
Check each label against the breakdown list on your card. Confirm that the scheme matches, the domain matches, the path matches, the query key and value match, and the fragment matches. If any label disagrees with the card, you have found a discrepancy to fix.
Frequently asked questions
Is example.org a real website I can visit?
No. In this article example.org is used as a hypothetical placeholder for practicing how to read URL strings. It does not represent a live project or a page you should expect to load.
Does the fragment part after the hash sign get sent to the server?
No. The fragment identifier is never sent to the server with the request. It only tells the browser where to scroll or focus once the resource has already been loaded.2
Can I change the query value without changing anything else in the URL?
Yes. You can replace compact with any other value while leaving the scheme, domain, path, and fragment untouched. The resulting string is a different URL, but each part remains independently editable.