URI vs. URL: What’s the Difference?

How I structure and organize content on a website is a hugely important part of making it user-friendly and maximizing its performance in places like organic search results. So, I’ve learned a thing or two about URIs versus URLs over the years.

It might seem like something technical you don’t need to know about, but I find that understanding exactly how these things work makes it easier to improve navigation and keep all content and user journeys organized and optimized.

Plus, there are so many resources available on the internet today, from web pages to images to weather reports and electronic documents. It’s important to be able to identify and retrieve these different resource types. To do so, you’ll need to know what a URI and URL are and how they’re different.

Table of Contents

• What is a URI?
• What is a URL?
• What is the difference between URIs and URLs?
• How do uniform resource identifiers (URIs) work?
• URI Syntax
• How do uniform resource locators (URLs) work?
• URL Syntax

For example, foo://example.com:8042/over/there?name=ferret#nose is a URI containing a scheme name, authority, path, query, and fragment. A URI does not need to contain all these components. All it needs is a scheme name and a file path, which can be empty.

Here’s the exact location the URI linked above brings me to:

Source

Here’s another example of a URI: telnet://192.0.2.16:80/. In this example, “telnet” is the scheme name and the numbers after the double slash make up the authority. The path is empty, which is why no characters come after the slash. (I’ll talk more about URI syntax later on in this post.)

These days, “telnet” is not used because it’s not secure. So this URI prompts my browser to open the connection within an app as you can see in the screenshot below:

Types of URIs

There are two types of URIs: URNs and URLs.

A uniform resource name (URN) is a persistent and location-independent identifier that follows the “urn” scheme. In this context, “persistent” means that the URN persists in identifying the same resource over time.

Here’s an example of a URN provided by the RFC 3986: urn:oasis:names:specification:docbook:dtd:xml:4.1.2

A URL, on the other hand, is a location-dependent identifier that is not necessarily persistent. This means that URLs are not required to identify the same resource over time. URLs also do not follow the “urn” scheme.

Like me, it’s likely you won’t need to use URNs too much and will mostly be focused on the structure and syntax of URLs. But I find it’s still useful to understand the difference between them and how they work.

HubSpot's Free Website Builder

Create and customize your own business website with an easy drag-and-drop website builder.

• Build a website without any coding skills.
• Pre-built themes and templates.
• Built-in marketing tools and features.
• And more!

Get Started for Free

How do uniform resource identifiers (URIs) work?

Uniform resource identifiers (URIs) are the backbone of how we pull resources from the web and access them. Their structure framework uniquely identifies a resource. That could be a document like a file or an image, or it could be something like an API endpoint.

Using the structured framework of a URI, here’s a quick breakdown on how a URI works:

• A user enters a URI into a browser’s address bar.
• The browser then parses the URI into its individual components (scheme, authority, and path, along with query and fragment if they exist).
• The browser then uses the components of the URI to send a request to the server and display the resource.

For example, a URI using the scheme “data” and a medium type of “text” means your browser will take the content of the URI and resolve it as text on the screen. For example, if I paste data:text/plain,Hello%20World! into my browser, this is what I see:

URI Syntax

The syntax of a URI contains five components, the last two of which are optional. I think this is one of the best ways to understand a URI, since we all use them so frequently when browsing online. Later in the post, I’ll also break down the syntax of a URL so you can better compare the differences between the two.

1. Scheme

This describes the protocol for accessing the resource. “Http” or “https” are the most common, but you might also recognize protocols like “mailto” or “ftp.” This gives a browser information on the path it needs to take to access the resource. For example, “https” tells the browser to use Hypertext Transfer Protocol Secure.

2. Authority

The authority gives browsers information about the location of the resource. This would most commonly be a domain name (e.g., the “hubspot.com” part of this website’s address). Depending on the resource type, this could also be an IP address or have a port number if the resource is an app or service using a custom server set-up — although this is something I rarely see.

3. Path

The path gives browsers more information about where the resource can be found within the domain. It’s usually most of the resource address after the domain name, so “/blog/this-is-the-blog-title” is a good example. In this case, I would be telling the browser where to find a specific blog post within a domain. In a link that points to a file on a computer such as “file:///C:/Users/JaneDoe/Documents/example.txt,” everything after “file:///” would be the path pointing to the specific document.

4. Query

Queries are optional and refer to any extra parameters that are added to the URI to help refine or modify a request. I’ll see these most commonly when it comes to searches within a domain.

For example, let’s say I’m working on an ecommerce website with an internal search function for users to find products. A URI with a query attached to it might look like “https://ecommercewebsite.com/products/search?query=leather&limit=10.” In this case, the query the user has entered is “leather” and the “limit=10” refers to settings that indicate only 10 results should be returned.

5. Fragment

Also optional, fragments are most commonly used to locate a specific point inside a resource. The example I use most frequently is jump links within a blog post. They’re followed by a “#” symbol in a URI. Let’s say I wanted to bring you to this specific section of this blog post. The URI would look like this: “https://blog.hubspot.com/website/uri-vs-url#URI-syntax.”

URIs can also be used via browser-specific schemes. I use Google Chrome most of the time, but you can also try this with Microsoft Edge and other browsers. When I enter “chrome://settings” I’m brought to the settings of my Google Chrome browser. In this instance, “chrome” is the scheme and “settings” is the path.

Here are some examples of URLs:

• ftp://ds.internic.net/internet-drafts/draft-ietf-uri-irl-fun-req-02.txt
• https://blog.hubspot.com/website/application-programming-interface-api
• http://www.ietf.org/rfc/rfc2396.txt
• https://offers.hubspot.com/how-to-run-seo-audit?hubs_post-cta=anchor&hsCtaTracking=f55ac8df-26f8-41f5-b63a-fa80e97d2fec%7Cfe8e963d-d682-4a22-b84e-52f7d60e4786

You’ll notice that these look similar to the URI examples mentioned above. That’s because they contain many of the same components, including path and query.

However, a URL contains unique components, such as protocol and domain, as well. In the last URL example, “https://” is the protocol. “Offers” is the subdomain, and “hubspot.com” the domain name. “How-to-run-seo-audit” is the path, and the question mark and everything after makes up the query.

HubSpot's Free Website Builder

Create and customize your own business website with an easy drag-and-drop website builder.

• Build a website without any coding skills.
• Pre-built themes and templates.
• Built-in marketing tools and features.
• And more!

Get Started for Free

How do uniform resource locators (URLs) work?

URLs are like an online bridge. They enable users to access specific locations and files on the web, and they provide what browsers need to access them accurately and securely. Through the use of protocols, domains, and paths, URLs enable browsers to parse through information and guide users to resources.

Here’s how it actually works.

First, I’ll take the URL of a page I want to access and paste it into the address bar of an internet browser.

The browser takes my URL and uses the syntax to locate what I’m trying to access. Through the domain name in the URL, the browser contacts a domain name system (DNS) to translate the domain name into an IP address. This address is the actual location of the server where the browser can find the resource.

Once the browser has established a connection to the server through the protocol indicated in the URL (e.g., “https”), it sends a request using the other information in the URL, such as path. The server then processes the request and returns the information, such as a web page, for the browser to display on my monitor.

Side quest: Make sure your own website is optimized for performance, visibility, and security with this free website optimization checklist. And if you are looking for a unified platform where you can monitor all these things in one place, the HubSpot CMS website monitoring tools might be worth a look.

URL Syntax

Since a URL is a subtype of URIs, its syntax is the same as what I described when going through the syntax of a URI. But let’s take a look at a specific URL example before I go on to describe the differences.

1. Scheme (or “Protocol”)

The scheme or protocol tells browsers how they can access the page or resource. You’ll notice, for example, that “http://” is less frequently used these days. Instead, most websites employ “https://.” That’s because https is a newer protocol which encrypts the information as it gets sent between browsers and servers, making it more secure.

2. Domain

This is the main website name, such as hubspot.com or google.com. But the browser also needs to take into account any subdomains here, too.

For example, we’re currently on blog.hubspot.com. If I were to try entering the URL for this page without the subdomain, I’d get a “Page Not Found” message because the subdomain is part of the resource’s location.

3. Path

Again, this is the section of the URL that comes after the domain and points to the specific page on that site. It can include multiple subfolders that might indicate things like a version of a page in a specific language.

4. Query

This optional section of the URL comes up when accessing a page through results on a search engine.

5. Fragment

Another optional piece of a URL, this tells browsers to go to a specific point on the page.

Now, let’s take a closer look at the difference between a URI and a URL.

URLs are therefore a specific subset of URIs. Meaning, all URLs are URIs, but not all URIs are URLs.

The most common analogy used to understand the difference between URIs and URLs is comparing a person’s name versus their address. A person’s name is like a URI because it identifies the person without providing any information on how to locate them. An address, however, identifies the person as a resident of that address and provides their physical location. That’s why it’s like a URL.

The other major difference is that URIs can be used to identify and differentiate HTML, XML, and other files from each other. URLs, on the other hand, can only be used to identify and locate web pages.

Side quest: If all this talk of URIs and URLs has you thinking about your website and web content, head on over to Content Hub to explore how you can improve the scale and quality of your online presence, plus SEO recommendations, video hosting, and more.

Identifying and Locating Resources on the Web

During my early days of working on website optimization, I didn’t give things like link structure and protocol too much thought. But the internet has become a competitive landscape where higher visibility is the prize.

The technicalities of URI and URL structures might seem pretty mundane. But I’ve learned that when it comes to technical specs and performance, it’s all about “the more you know.” Understanding URIs and URLs is the foundation for building website architecture that puts user experience and discoverability at the forefront of your digital efforts.

Editor's note: This post was originally published in January 2021 and has been updated for comprehensiveness.

HubSpot's Free Website Builder

Create and customize your own business website with an easy drag-and-drop website builder.

• Build a website without any coding skills.
• Pre-built themes and templates.
• Built-in marketing tools and features.
• And more!

Get Started for Free