You probably came here for one reason: to know the difference between a URI and a URL. So here’s the one-sentence summary:

TL;DR: The difference between a URI và a URL is that a URI can be just a name by itself, or a name with a protocol that tells you how khổng lồ reach it—which is a URL.

Bạn đang xem: Url và uri là gì


…is a URI because it is only the name of a resource, and…

…is a URL because it’s both the name of a resource (, & the way to lớn get there (https://).

In this article you’ll learn more about the difference between URIs, URLs, & URNs, with examples of each.



Here are some examples of URIs, URNs, và URLs that show the relationship. Remember, a URI can be a URN or a URL because both are subtypes of URI.

Names and addresses aren’t technically URIs in this example, but it illustrates the difference between a thing & how to lớn find that thing.

A name, name và location, or botha name or numbera name/number with location
A name, a name and address, or bothSomeone’s name or addressSomeone’s name & address
An ISBN numberAn ISBN numbermailto://dan

URIs, URLs, and URNs

A Uniform Resource Identifier (URI) is a string of characters that uniquely identify a name or a resource on the internet. A URI identifies a resource by name, location, or both. URIs have two specializations known as Uniform Resource Locator (URL), and Uniform Resource Name (URI).

A Uniform Resource Locator (URL) is a type of URI that specifies not only a resource, but how to lớn reach it on the internet—like http://, ftp://, or mailto://.

A Uniform Resource Name (URN) is a type of URI that uses the specific naming scheme of urn:—like urn:isbn:0-486-27557-4 or urn:isbn:0-395-36341-1.

So a URI or URN is like your name, and a URL is a specific subtype of URI that’s like your name combined with your address.

All URLs are URIs, but not all URIs are URLs.

We’ve learned above that URIs include both URNs and URLs, but let’s break that into more detail.

A URI is an identifier of a specific resource. Examples: Books, DocumentsA URL is special type of identifier that also tells you how khổng lồ access it. Examples: HTTP, FTP, MAILTOIf the protocol (https, ftp, etc.) is either present or implied for a domain, you should call it a URL—even though it’s also a URI.

So which should I use?

URI vs. URL is one of the most timeless of all the geek debates. If you ever hear someone correct someone—in one direction or another—you’ll often hear the drawing of Katana swords right after.

So which is correct?

When most people mention a domain name the HTTP protocol is implied, making it a URL.

The answer is that it depends on what’s being discussed. If you’re talking about an everyday website domain, like, it’s best lớn use URL instead of URI because URL is more specific.

It’s usually best khổng lồ be as specific as possible, so URL is better than URI even when both are technically true.

If you’re talking lớn someone from San Francisco, for example, và they ask you where you live, you wouldn’t tell them you live in San Francisco, or in California. You’d respond with your neighborhood, because that’s the level of detail they were asking for.

Technically is a URI, just like technically you live in California, but is also a URL and you also live in San Francisco.

In other words, in 99% of everyday cases, you should use URL instead of URI because both are technically true but URL is more specific!

URL Structures


URLs have their own specific structure as well. In that structure you have the following components:

The Scheme, which is the protocol that you’re using to interact.The Authority, which is the target you’re accessing. This breaks down into userinfo, host, & port.The Path, which is the resource you’re requesting on the host.The Query, which are the parameters being used within the web application.The Fragment, which is the target lớn jump lớn within a given page.


Schemes can include: HTTP, HTTPS, FTP, MAILTO, IRC, FILE, etc. HTTP & HTTPS are usually used to lớn reach mạng internet resources, but they can point lớn local (on-network or on-computer) resources as well.

The tệp tin scheme refers to a tệp tin located on the local computer, and it looks for the tệp tin at the path that’s provided. The host can also include a port designation that overrides the mặc định port for the specified protocol. For example:

…will go to lớn the host on port 443 because 443 is the default port for HTTPs. But if you specify the port lượt thích so:

…the client will attempt to connect lớn connect lớn port 9023 using the HTTPs protocol instead.

Finally, URLs also have query parameters và fragment identifiers.


Query parameters indicate an argument being passed into a website application, such as a search function for a webpage, like:

This would search for the word “bing” on a function called search on Google.

Fragments allow you to lớn jump lớn a specific part of the page from the URL, lượt thích so:

This would jump khổng lồ a hyperlink on the page labeled “worse” on the page named results.html.

Quizing Some Examples

Ok, let’s look at some examples & see if you can answer the questions.

Is this a URI, URL, or a URN?

Answer: It’s an incomplete URL because it doesn’t have a protocol (although you can argue that it can be implied). As for the structure, if this were a URL it would only be the host portion because it lacks a scheme & a path.

Is this a URI, URL, or a URN?


Answer: This looks to lớn be a resource within a URL, but since it doesn’t seem to lớn be a unique resource or prefaced by the urn: prefix, it is not a formal URN. So it is neither a URN, URL, or URI.

RFC Confusion

A deeper explanation (let’s get technical)

Let me warn you: this is one of the most common NerdFights in tech history, & that’s saying a lot.

One obstacle lớn getting lớn the bottom of things is that the relevant RFCs are extremely dense, confusing, & even contradictory. For example, RFC 3986 says a URI can be a name, locator, or both…

My emphasis.

A URI can be further classified as a locator, a name, or both. Theterm “Uniform Resource Locator” (URL) refers lớn the subset of URIsthat, in addition to identifying a resource, provide a means oflocating the resource by describing its primary access mechanism(e.g., its network “location”).RFC 3986, Section 1.1.3

But just a little further down that same RFC says…

My emphasis.

The URI itself only providesidentification; access to the resource is neither guaranteed norimplied by the presence of a URI.RFC 3986, Section 1.2.2

And then, if you’re not yet completely confused, it also says…

My emphasis.

Each URI begins with a scheme name, as defined in Section 3.1, thatrefers to lớn a specification for assigning identifiers within thatscheme.RFC 3986, Section 1.1.1

And it goes on to give examples:

Notice how they all their examples have schemes. ldap://<2001:db8::7>/c=GB?objectClass?one mailto:John.Doe news:comp.infosystems.www.servers.unix tel:+1-816-555-1212 telnet:// urn:oasis:names:specification:docbook:dtd:xml:4.1.2


These three contradictions are the source of this entire long-lived debate.

The same RFC just told us that a URI can be a name, a locator, or both—but a URI only provides identification, & a way to lớn access isn’t guaranteed or implied—oh và also each URI begins with a scheme name (which in many cases tells you exactly how khổng lồ access the resource).

It’s no wonder everyone is confused!

The reason the internet’s been fighting about this for over a decade is that the RFC is poorly written.

Salvaging practical rules from all this

Being the top search result for this topic means I have the conversation a lot.

Ok, so given the fact that the RFC adds khổng lồ confusion rather than eliminating it, what—if anything—can we use from them?

In the vein of language being here for communication rather than pedantry, here are my own practical interpretations of the RFCs that will hopefully synchronize people & result in fewer swordfights.

All butterflies fly, but not everything that flies is a butterfly.

A Uniform Resource Identifier (URI) provides a simple & extensible means for identifying a resource (straight from RFC 3986). It’s just an identifier; don’t overthink it.For most debates about this that matter, URI is the superset, so the question is just whether a given URI is formally a URL or not. All URLs are URIs, but not all URIs are URLs. In general, if you see http(s)://, it’s a URL.URIs technically bởi vì require a scheme (see above), but the RFC also says they can be a name, locator, or both, so YOLO! My advice for anyone saying URIs bởi or bởi not require a scheme is lớn show them this article, because it’s the only thing I know of that highlights the contradictions in the RFC.A little-known section of RFC 3986 actually speaks directly khổng lồ the religious part of the argument, and seems to lớn say we should say URI instead of URL.

RFC 3986 is from 2005, so presumably they’re saying URI is the preferred term after that point.

Future specifications and related documentation shoulduse the general term “URI” rather than the more restrictive terms“URL” and “URN”RFC 3986, Section 1.1.3

So that’s tư vấn for the “URI” denomination, but in my opinion it’s even more support for those who say, “stop looking for the answers in 15-year-old RFCs”.

It’s lượt thích another widely-read text in this way.

There’s just so much contradictory nội dung that there’s partial backing for multiple conclusions.


What a mess. Here’s the TL;DR…

The RFCs are ancient, poorly written, & not worth debating until they’re updated.A URI is an identifier.A URL is an identifier that tells you how to get lớn it.Use the term that is best understood by the recipient.

I’d welcome a new version of the RFC that simplifies & clarifies the distinction, with modern examples.

These RFCs were written a very long time ago, and they’re written with the academic weakness of not being optimized for reading.

The best thing I can possibly tell you about this debate is not to over-index on it. I’ve not once in trăng tròn years seen a situation where the confusion between URI or URL actually mattered.

The irony is that RFCs are supposed lớn remove confusion, not add to it.

So while there is some direct support that “URI” is preferred by the RFCs, và “URL” seems most accurate for full addresses with http(s) schemes (because it’s most specific), I’ve chosen to prioritize the Principle of Communication Clarity higher than that of pedantic nuance.

It’s taken me a long time to get khổng lồ this point.

As a result, I personally use “URL” in most cases because it’s least likely khổng lồ cause confusion, but if I hear someone use “URI” I’ll often switch immediately khổng lồ using that instead.

Xem thêm: Giải Toán Lớp 5 Bảng Đơn Vị Đo Thời Gian, Bảng Đơn Vị Đo Thời Gian Lớp 5


Feb 20, 2022 — Added additional sections & more in-depth explanations of differences in URLs, URIs, and URNs.Jan 16, 2022 — Updated for brevity, legibility, và clarity.May 3, 2019 — I’ve done a major update to lớn the article, including correcting some errors I had had in previous versions. Namely, I had fragments such as file.html shown as a URN, which is not right. This version of the article is the best version, especially since it fully explores the conflicting language within the RFC and how little we should actually be paying attention to such an old document. I’d definitely read & follow an update, though.