Every website has an address—you post them on social media, customers save them to revisit products, and you include them in emails. 

Most web addresses you encounter are Uniform Resource Locators (URLs); some are Uniform Resource Identifiers (URIs). Understanding the distinction between URIs and URLs can help when you’re fixing broken links, managing redirects, or troubleshooting why your product page disappeared from search after a site update. Here’s what you need to know.

What is a URI?

A Uniform Resource Identifier is a standardized string of characters used to uniquely identify a resource—like a web page, image, document, or email address—so computers can recognize it. “Uniform” means it follows a consistent structure, so browsers and apps can reliably interpret it. 

URI functions like a naming system—more precisely, an identification and referencing system. A “resource” can be anything from a product page or PDF to an image or API endpoint. And “identifier” highlights that the URI doesn’t just name the resource—it specifies it in a way that distinguishes it from all others, enabling accurate retrieval or interaction.

In web development, URIs allow browsers, apps, and servers to accurately identify resources. The format is set by the Internet Engineering Task Force, which keeps the rules consistent whether you’re linking to a blog post, a checkout page, or a file stored on your web server. Without this system, search engines couldn’t distinguish between your content and someone else’s, checkout pages wouldn’t load, and apps couldn’t connect to your store.

Uniform Resource Locators (URLs) and Uniform Resource Names (URNs) are types of URIs.

Elements of a URI

A URI is made up of parts that work together to identify, and sometimes locate, a resource:

• Scheme. The scheme is at the beginning of the URI and tells the browser or app which protocol to use for accessing the resource. It’s always followed by a colon (:). Common examples include http and https for web pages, ftp for file transfers, and mailto for email addresses. For many, like http or https, that colon is followed by two slashes (//) to mark the start of the resource’s address.

• Authority. Authority usually holds the network location (like 192.168.1.1) or a domain name (like yourstore.com), and sometimes a port number (a numeric value that specifies which server port to connect to). For instance, in https://example.com:8080, example.com:8080 is the authority and :8080 is the server port.

• Path. The path points to the exact spot where the resource lives, whether that’s a product image buried in a folder on your web server or the checkout page on your store. Paths always start with a forward slash (/).

• Query. Some URIs also have a query section. That’s where you see query parameters, usually after a question mark (?), to provide extra instructions. A search results page on your site might use them to filter by category or sort by price. Multiple parameters are separated by ampersands (&).

• Fragment. Finally, the fragment jumps to a secondary resource or section within the main one. It comes after a hash symbol (#). On a long help article, for example, it might scroll you straight to the Return Policy heading.

Common URI schemes

Several URI schemes are common in everyday web use, including:

• https:// for secure web pages. Type https:// at the start of a web address and you’re using HTTPS, the secure version of HTTP, which is the standard protocol for loading almost any web page today. Here’s how to migrate from HTTP to HTTPS if you aren’t already using this secure system.

• mailto: for email links. Click an email link with mailto: at the beginning, and your email app pops open with the address already filled in.

• ftp:// for file transfers files. ftp:// was once common for file transfers. You might still see it in legacy systems, but modern setups usually rely on more secure methods like SFTP or cloud storage platforms. For example, a business moving a batch of product images from a local computer to a server is more likely to use SFTP or upload directly to a cloud service.

Other URI schemes you might see less often include ldap: for directory services or telnet: for connecting to another computer. These follow the same rules for identifying resources, but they’re not part of day-to-day store management.

What is a URL?

A URL is a type of URI that provides the resource’s location and access method. In practice, most web addresses you see are URLs. Open a product page, for instance, and the address bar contains a URL. The URL is the instruction that tells the web browser exactly which resource on the internet to pull and how to get it. You can copy, share, or revisit it to reach the same resource every time. 

For example, https://yourstore.com/products/123?color=blue#reviews tells the browser to use Hypertext Transfer Protocol Secure (HTTPS), identifies the host, navigates through the path components, applies filters via the query string, and jumps to the reviews section using a fragment. URLs aren’t only for pages. They can also point to a PDF on a web server, a downloadable file, or an API endpoint your store uses for inventory.

URLs are also how search engines keep track of your site. Their crawlers follow URLs from page to page, indexing your web resources so they can send people to the right spot later. Without URLs, a browser wouldn’t know where to find your homepage, and a payment app couldn’t connect to your cart. On the World Wide Web, they provide the information a browser or other client needs to locate a resource, request it from the correct server, and display or deliver it to the user.

Elements of a URL

Most URLs you see in a browser follow the same basic URL format: 

• Protocol. At the start, the protocol tells the browser which rules to use, like Hypertext Transfer Protocol (http://) or Hypertext Transfer Protocol Secure (https://). 

• Authority. After the protocol, you’ll find the authority. This usually includes the domain name—the human-readable address that points to your site’s network location (for instance, example.com). Subdomains (shop.example.com) are part of the domain, and if a site uses a nonstandard port, that appears here, too. Together, the domain plus optional subdomain and port number make up the authority component.

• Path. The last core piece is the path. Path components lead the browser to a specific file or page inside the site’s structure, for example, /products/tote-bag.

Many URLs carry extra elements like:

• Query string. A query string appears after a question mark and holds query parameters, like ?color=black&size=m, which your store might use to filter a category page or track a campaign. 

• Fragment. A fragment component comes after # and jumps to a section inside the page, such as #reviews. 

• Relative URL. You also see a relative URL in templates or within a CMS that omit the protocol and domain, for example, /cart, which rely on the current site as the base.

All of this sits inside a consistent URL syntax that lets most web browsers locate resources predictably, whether that is a product page, a PDF on a web server, or another web resource inside your store.

URI vs. URL vs. URN

URLs and URNs are types of URIs. URLs don’t just name resources; they tell your browser how to get there.

A URN names a resource without tying it to a location. You might find them in places like XML namespaces, academic paper identifiers (like DOI:10.1000/xyz123), or in systems that reference books by ISBN in URN format (like urn:isbn:0451450523). You can identify the resource, but you can’t paste a URN into a browser and expect a page to load without additional resolution services. 

Not every URI is a URL. URLs and URNs are two ways of doing the same larger job—identifying resources—each with its own purpose and format. They follow the same URI syntax, but serve different needs. URNs are persistent names that don’t change even if a resource moves, but URLs can break if you relocate your resource.

You might use a URI to identify your store’s customer service email address, a product image in your content management system (CMS), or a PDF saved on your local computer. For example, mailto:[email protected] is a URI that identifies an email address, while https://yourstore.com/products/123 is a URI that also works as a URL.