What Is a URL? How Web Addresses Point Browsers to the Right Resource
Learn what a URL is, how web addresses are structured, what parts like the protocol, domain, and path mean, and how browsers use URLs to locate resources.
Every time you open a website, click an article, load an image, or download a file, your browser needs a way to identify where that resource can be found.
That is the job of a URL, short for Uniform Resource Locator. A URL is the address used to locate a resource on the web. It can point to a webpage, image, stylesheet, video, document, API endpoint, or many other resources accessible through a network.
A familiar URL might look like this:
https://example.com/articles/what-is-a-url
Although we usually treat that as one address, it contains several meaningful parts. The protocol tells the browser how to communicate, the domain identifies the host, and the path identifies a particular resource or location on that host.
Understanding those pieces makes URLs much less mysterious.
A URL Is an Address for a Resource
The simplest way to think about a URL is as an address.
If someone tells you to visit example.com, they are identifying a place on the web. If they give you a more specific address such as example.com/images/logo.png, they are pointing toward a particular resource associated with that site.
The full URL provides the browser with structured information it can use to make the request:
https://example.com/images/logo.png
└─┬─┘ └────┬────┘ └──────┬───────┘
protocol domain path
Those three components explain the basic structure of many everyday URLs. Real URLs can contain additional components, but protocol, domain, and path are a useful place to start.
A URL is also more general than a “webpage address.” The thing being located does not have to be an HTML page. The same addressing system can identify an image, CSS file, JavaScript file, PDF, API resource, or another type of content.
The Protocol Tells the Browser How to Communicate
At the beginning of a typical web URL you will see:
https://
This part identifies the scheme, commonly called the protocol in everyday explanations.
For normal web browsing, the two familiar forms are HTTP and HTTPS. HTTP stands for Hypertext Transfer Protocol, while HTTPS is HTTP used over a secure, encrypted connection.
Consider:
https://example.com
The https portion tells the browser that it should communicate with the server using HTTPS.
That matters because locating a server is only part of the problem. The browser also needs to know what kind of communication it is expected to perform, which is the same broader protocol distinction behind MDN’s URI scheme reference.
For modern websites, HTTPS is the normal choice because it protects communication between the browser and server from being casually read or modified while in transit. It also allows the browser to authenticate the server through the web’s certificate infrastructure.
The Domain Identifies the Host
After the protocol comes the domain:
https://example.com
└────┬────┘
domain
The domain gives the browser a human-readable name associated with the server or service it needs to reach.
Computers ultimately communicate using network addresses such as IP addresses, but names such as example.com are much easier for people to remember. The Domain Name System (DNS) helps translate domain names into the information computers need to locate the appropriate server, a resolution step also explained in Cloudflare’s DNS overview.
A simplified flow looks like this:
example.com
│
▼
DNS lookup
│
▼
Server address
│
▼
Browser connects
This is why the domain is such an important part of a URL. It establishes which host the browser should contact before the browser can ask that host for a particular resource.
Domains Can Have Several Components
A domain itself may contain multiple pieces.
Take:
www.example.com
Here, .com is the top-level domain, example is the registered domain label, and www is a subdomain.
Another service might use:
docs.example.com
or:
api.example.com
The organization can use these subdomains to separate different parts of its infrastructure or content.
From the user’s perspective, they are still recognizable as related addresses. From the technical perspective, however, different hostnames can be routed to different systems.
This is particularly common in larger applications where the main website, documentation, API, authentication service, and static assets may be served through different infrastructure.
The Path Points to a More Specific Location
Once the browser knows which host to contact, the path identifies the resource or route being requested.
In this URL:
https://example.com/products/shoes
└──────┬───────┘
path
the path is:
/products/shoes
It tells the server which resource the browser wants from example.com.
Paths often resemble folders and files because early websites frequently mapped URLs closely to files stored on a server. You may still encounter addresses such as:
/images/logo.png
/docs/manual.pdf
But modern application paths do not necessarily correspond to literal folders or files.
For example:
/products/42
might cause an application to retrieve product 42 from a database and dynamically generate the response. There does not need to be a physical 42 file sitting inside a products directory.
The path is therefore better understood as the identifier the server uses to determine which resource or application route is being requested, which is why MDN’s URL path reference and routing patterns often show up when developers match URLs inside applications.
The Browser Uses the Parts Together
Consider the complete address:
https://example.com/help/account
Each major part answers a different question:
| Part | Example | What it tells the browser |
|---|---|---|
| Protocol/scheme | https | How to communicate |
| Domain | example.com | Which host to contact |
| Path | /help/account | Which resource or route to request |
The browser can use the domain to determine where to connect, establish the appropriate HTTPS connection, and then request the path from the server.
Conceptually:
URL entered
│
▼
Identify domain
│
▼
Find server
│
▼
Establish HTTPS connection
│
▼
Request path
│
▼
Receive response
The response could contain HTML for a webpage, but it does not have to.
A URL Can Point Directly to an Image
Suppose a webpage contains a logo.
The HTML might tell the browser that the image lives at a URL conceptually like:
https://example.com/images/logo.png
The browser treats that image as another resource to retrieve. It contacts the appropriate host and requests /images/logo.png.
The server then returns image data rather than an HTML document.
This is an important part of understanding how webpages work. Loading one page can cause the browser to request many separate URLs:
/page
/styles.css
/app.js
/images/logo.png
/images/photo.jpg
Each resource has its own address, even though the user experiences them together as one webpage.
Files Can Have URLs Too
URLs can also point to downloadable or viewable files.
For example:
https://example.com/files/report.pdf
may identify a PDF, while:
https://example.com/downloads/archive.zip
may identify an archive.
The path helps distinguish these resources from everything else available through the same domain.
However, the filename-like ending does not guarantee that a physical file exists at exactly that location on the server. An application can dynamically generate a PDF or download response while still exposing a URL that looks like a conventional filename.
The URL identifies the resource. How the server produces that resource is an implementation detail.
URLs Are Also Used for APIs
Not every URL is intended to be opened as a traditional webpage.
Applications use URLs when communicating with APIs as well.
A service might expose:
https://api.example.com/users/123
A browser or application can make an HTTP request to that URL and receive structured data rather than a rendered webpage.
For example, the response might contain JSON representing a user record.
This reinforces the broader definition: a URL locates a resource, not necessarily a visual page intended for a person to read.
The same addressing model works whether the requester is a browser loading an article or an application retrieving data from an API, a distinction also captured in RFC 3986.
URLs Can Contain More Than Protocol, Domain, and Path
Protocol, domain, and path are the main pieces needed for a basic explanation, but many real URLs contain additional information.
Consider:
https://example.com/search?q=shoes&page=2
The path is:
/search
while:
?q=shoes&page=2
is the query string.
Query parameters can provide additional information to the application. In this example, they might indicate that the user searched for shoes and requested page 2 of the results.
Another URL might contain a fragment:
https://example.com/guide#installation
The #installation portion is a fragment identifier. On a webpage, it commonly points the browser toward a particular section of the document.
So a more complete URL structure can look like:
https://example.com/search?q=shoes#results
└─┬─┘ └────┬────┘ └─┬──┘ └──┬──┘
scheme host path query
+
fragment
Not every URL needs all of these components.
Query Parameters Often Carry Dynamic Information
Query strings are common because websites frequently need to represent choices without creating an entirely different path for each possible combination.
A shopping site could use:
/products?category=shoes&color=black
Here, /products identifies the main resource or route, while the query parameters describe the requested filtering.
Parameters generally follow a ?, and multiple parameters are commonly separated with &.
That gives us:
?category=shoes&color=black
with two name-value pairs:
category = shoes
color = black
Search pages, filters, pagination, analytics tracking, and application state are common places to encounter query parameters.
One important security lesson follows from their visibility: a URL should not be treated as a safe place for passwords or other secrets simply because HTTPS is being used. URLs can appear in browser history, application logs, analytics systems, screenshots, and other records, which is one reason structured logging needs careful redaction around request data.
Fragments Usually Point Within a Resource
A fragment appears after #.
Suppose a long documentation page contains an installation section:
https://example.com/docs#installation
The browser can load /docs and then navigate to the part identified by installation.
This is why clicking a table-of-contents link sometimes changes only the end of the URL rather than loading an entirely different page.
Fragments have an important technical distinction from ordinary paths and query strings: in normal HTTP navigation, the fragment is handled by the client and is not sent to the web server as part of the HTTP request.
Modern JavaScript applications can also use fragments for client-side behavior, although application routing practices vary.
For someone learning URLs, the simpler mental model is enough: the path identifies the resource, while a fragment can identify a location or state within that resource on the client side.
HTTPS Does Not Mean Every URL Is Trustworthy
Seeing https:// is important, but it does not prove that the website itself is legitimate.
Consider a phishing site using:
https://example-login-attacker.com
The site could have a perfectly valid HTTPS connection while still being controlled by an attacker.
HTTPS protects the connection to the domain you are visiting. It does not guarantee that you chose the correct domain in the first place.
That makes the domain particularly important when evaluating suspicious links.
An attacker may create a name that visually resembles a legitimate site, hoping users pay attention to familiar words somewhere in the address rather than checking the actual hostname.
The correct security question is not merely “Does this URL have HTTPS?” It is also “Which domain am I actually connecting to?”, the same practical issue that makes phishing work so often.
Small URL Differences Can Point Somewhere Completely Different
Compare:
https://accounts.example.com/login
with:
https://example.com.attacker-site.com/login
At a quick glance, both contain example.com.
But they do not have the same hostname structure. In the second address, the controlling registered domain is attacker-site.com; example.com appears earlier as part of a subdomain chosen by the attacker.
This is one reason URLs can be useful security information rather than merely navigation information.
When a link asks for a password, payment, download, or other sensitive action, checking the actual destination matters.
The path can be invented freely by whoever controls the domain. A path such as /microsoft/login, /bank/security, or /account/verification does not prove any relationship to the organization named there.
Spaces and Special Characters Need Representation Too
URLs have syntax rules, so some characters cannot simply appear everywhere in their ordinary form.
You may have seen addresses containing values such as:
%20
This is an example of percent-encoding. A space, for instance, is commonly represented as %20 in URL components where appropriate, as defined in MDN’s percent-encoding reference.
So something conceptually named:
annual report.pdf
could appear in a URL as:
annual%20report.pdf
Browsers usually handle much of this encoding automatically, which is why ordinary users rarely need to think about it.
Developers encounter it more often when constructing URLs, handling query parameters, or building APIs. Correct encoding ensures that data is not accidentally interpreted as part of the URL’s structural syntax.
Relative URLs Let Pages Reuse Their Existing Location
Not every link needs to contain the complete address.
A page on example.com might refer to an image using:
/images/logo.png
rather than writing the full:
https://example.com/images/logo.png
The first is a relative reference that the browser resolves using the current page’s URL as context.
This is useful because websites contain large numbers of internal links and resources. Developers do not always need to repeat the protocol and hostname for every one.
An absolute URL provides the full location, while a relative reference depends on an existing base URL.
For users, both may appear to behave identically after the browser resolves the final destination.
A URL Is Not Quite the Same Thing as a Domain Name
These terms are often mixed together.
example.com is a domain name.
https://example.com/products/42 is a URL.
The URL contains the domain but also provides additional information about how and what to access.
Similarly, /products/42 is a path, not the complete URL.
You can think of the relationship as:
URL
├── scheme/protocol
├── host/domain
├── path
├── query (optional)
└── fragment (optional)
Knowing the distinction becomes especially useful in web development, DNS configuration, analytics, cybersecurity, and SEO, where different parts of the address may need to be handled separately.
The Path Can Make Web Addresses Easier to Understand
Good URL paths often give people a reasonable idea of what they are about to open.
Compare:
example.com/articles/url-basics
with:
example.com/index.php?id=84729
Both can work technically, but the first communicates more meaning to a human reader.
Clear paths can also make links easier to share, maintain, organize, and debug. They allow a site’s information architecture to be reflected in addresses such as:
/docs/authentication/passkeys
/products/laptops
/blog/image-compression
The server is free to implement those routes however it wants internally. The URL does not need to expose the application’s database structure or physical filesystem.
That separation lets developers create stable, meaningful public addresses even when the underlying implementation changes.
What Happens After You Enter a URL?
Suppose you enter:
https://example.com/page
There is considerably more happening than simply “opening the address.”
At a high level, the browser interprets the URL, determines how to locate the host, establishes a connection, sends an HTTP request for the resource, receives the server’s response, and then processes that response, which is the same request flow behind latency vs bandwidth affecting how fast a page feels.
If the response is HTML, the browser may discover more URLs inside it for stylesheets, scripts, fonts, and images. Those resources then generate additional requests.
A single visible webpage can therefore involve dozens or hundreds of URLs.
This helps explain why the URL is such a fundamental concept in web architecture. It provides a consistent way for resources to refer to one another across an enormous distributed network.
The Most Useful Mental Model Is Still an Address
The technical details of URLs can become deep. They can include ports, usernames in some schemes, encoded characters, internationalized domain names, query parameters, fragments, and rules for resolving relative references.
But the fundamental idea remains straightforward.
A URL tells software where a resource is located and how it should be accessed.
For an everyday web address such as:
https://example.com/page
you can read it as:
https — use this communication scheme.
example.com — contact this host.
/page — request this resource or route.
The result might be a webpage, image, file, API response, or another resource entirely.
A URL is the web’s addressing system: it turns “I want that resource” into a structured location that a browser or other application can actually use to find it.