What Is a URL? Parts of a Web Address Explained With Examples

Key takeaways

• A URL identifies a resource; a domain name is only one possible component of that address.
• Web URLs can include a scheme, hostname, port, path, query, and fragment with different roles.
• Relative references require a base, and a trailing slash can change how they resolve.
• Parse and construct URLs with the platform API, then apply the rules your application needs.

A URL, short for Uniform Resource Locator, is an address that identifies a resource using a defined scheme. On the web, it can identify a page, image, download, or API endpoint. The browser interprets its components to determine what to access and how.

Suppose a colleague shares a link to the second page of a product search, with a fragment pointing to the results. Understanding the URL lets you distinguish the destination site from the search term and the place the browser should display after loading.

That structure matters when reading links, diagnosing unexpected navigation, and generating addresses in application code.

The Parts of a URL

Consider this illustrative address:

https://shop.example.com:8443/products?q=red%20shoes&page=2#results

Its components have separate roles:

Component	Example	Role
Scheme	https	Specifies the scheme used to access the resource.
Hostname	shop.example.com	Identifies the host by name.
Port	8443	Specifies the network port for this address.
Path	/products	Identifies the resource or route within the service.
Query	q=red%20shoes&page=2	Supplies information interpreted by the application.
Fragment	results	Identifies a client-side location or other fragment meaning.

In everyday web addresses, the port is often omitted. HTTPS uses port 443 by default; specifying 8443 selects a different port. The WHATWG URL Standard defines the parsing and representation rules used by web-platform URL APIs.

Not every scheme has this structure. An address beginning with mailto:, for example, does not describe an ordinary HTTP request to a server.

A URL Is More Than a Domain Name

The hostname in the example is shop.example.com. The complete URL also contains the scheme and the resource information. Typing a domain into a browser may prompt the browser to construct an address, but that convenience does not make the terms interchangeable.

A hostname can contain subdomains, and familiar words can appear in places that do not identify the intended organisation. Compare these example addresses:

https://accounts.example.com/login
https://example.com.example.net/login

The second hostname is beneath example.net. The appearance of example.com at its beginning does not make it the first site’s host.

When a link requires a consequential action, inspect the actual destination rather than its visible label or reassuring words in the path. HTTPS protects a connection; it does not establish that the destination is the organisation you meant to visit. The distinction is relevant to phishing.

The Path Is an Application Address

A path such as /products/42 does not require a file named 42 on the server. An application may interpret it as a route, retrieve a database record, and generate a response.

Even a path ending in .pdf can be handled dynamically. The URL describes the resource exposed to the client, while the server controls how that resource is produced.

Paths can also distinguish resources by case or a trailing slash. Do not lowercase or remove characters from an entire URL merely because hostnames are commonly compared without case. The application’s routing and redirect behaviour determine which path forms are equivalent.

Query Parameters and Fragments Do Different Work

Web applications commonly interpret a query as name-value pairs. In our example, q supplies a search term and page selects a page. Their names and meaning belong to the application, not to a universal search protocol.

A fragment follows #. As the fragment reference explains, it is not sent as part of the ordinary HTTP request target. A browser may use it to navigate to an element, and application JavaScript may interpret it as state or routing information.

That distinction matters when debugging. A server access log will not ordinarily contain #results from this navigation. Client code can still read the fragment and send information elsewhere, so it is not a private storage mechanism.

Queries are also poor places for passwords or reusable secrets. Addresses can appear in browser history, logs, screenshots, and analytics even when transport uses HTTPS.

Build URLs Without Manual Concatenation

Reserved characters can change the structure of a URL. A literal ampersand inside a search term should not accidentally become the separator before another parameter.

The JavaScript URL API provides structured access:

const address = new URL('https://shop.example.com/products');
address.searchParams.set('q', 'red shoes & socks');
address.searchParams.set('page', '2');
address.hash = 'results';

console.log(address.href);
// https://shop.example.com/products?q=red+shoes+%26+socks&page=2#results

Here, the query serialisation represents spaces with + and the literal ampersand with %26. Passing the unencoded value to searchParams avoids manually encoding it and then encoding it again.

The same API can inspect an address:

const address = new URL(
  'https://shop.example.com:8443/products?page=2#results'
);

console.log(address.hostname); // shop.example.com
console.log(address.port);     // 8443
console.log(address.pathname); // /products
console.log(address.searchParams.get('page')); // 2

A parsed parameter is still input. The application must decide whether page 2 exists and whether the supplied value is acceptable.

Absolute and Relative References

An absolute web URL supplies its own scheme and destination. A relative reference needs a base to determine its final address.

These code examples deliberately demonstrate relative inputs rather than article links:

new URL('guide', 'https://example.com/docs/').href;
// https://example.com/docs/guide

new URL('guide', 'https://example.com/docs').href;
// https://example.com/guide

The trailing slash changes the base’s directory interpretation. A reference beginning with /guide instead resolves from the origin’s root. The relative-resolution guide explains these cases.

This can account for a link that works on one page but points somewhere unexpected on another. Inspect the base as well as the reference. Resolving a user-supplied value against a trusted base also does not force it to remain on that host: an absolute input can specify another destination.

Parsing Is Only the First Check

A successful parse establishes that the parser can interpret the address. It does not prove the resource exists, the server will respond, or the destination is permitted by your application.

For a link field, decide which schemes are accepted. For a restricted redirect, compare the parsed destination against the application’s policy. Avoid looking for a trusted hostname as a substring anywhere in the input; it could appear in a query or inside a different hostname.

When navigation fails, separate the stages. Was the address interpreted correctly? Did it reach the intended host? Did that service recognise the route? Did a redirect change the destination? This is more informative than treating every unsuccessful page load as a malformed URL.

A URL gives software a structured way to identify a resource. Reading and constructing its components deliberately makes links easier to explain, query values safer to handle, and unexpected destinations easier to investigate.

A web address becomes easier to understand when each part is read according to its role rather than as one long string.