Friday, November 23rd, 2007
URI vs. URL: What’s the difference?
REST groupies can talk your ear off about resources and the difference between URI and URL. Many developers still don’t really know the difference though, and Ryan McDonough has put up this simple summary.
His summary is by example and goes like this:
URI
A URI identifies a resource either by location or name. More often than not, most of us use URIs that defines a location to a resource. However, a URI does not have to specify the location of a specific representation. Citing and example of a W3C URI for their home image, they use the following URI: http://www.w3.org/Icons/w3c_home. Note the absence of a file extension. The URI for the w3c_home image is still universally unique, but it does not specify the specific representation of the image (either a GIF, PNG, or JPG). The selection of the representation can be determined by the web server through HTTP content negotiation. The Apache HTTPD server has had excellent support for content negotiation for many years. Oddly, few sites take advantage of HTTP content negotiation. The W3C is one web application that makes heavy use of URIs and content negotiation.
URL
A URL is a URI but a URI is not a URL. A URL is a specialization of URI that defines the network location of a specific representation for a given resource. Taking the same W3C example, there are actually 2 representations available for the w3c_home resource:
These URIs also define the file extension that indicates what content type is available at the URL. Through content negotiation, the web server will forward the user agent to the proper type, depending on the client’s capabilities, when the URI http://www.w3.org/Icons/w3c_home is accessed.
More often than not, URI is the correct term to use when referring to the location of resources on the WWW.












I must admit, that was actually clearing up some confusion
Well I’m glad someone came along to clear that up. I’ve had enough arguments with web developers who did not realise the difference.
In short, don’t use ‘Url’ use ‘Uri’. Uri is a superset, so you can’t be wrong when you use it. Note that Uris can also be used as names. For example http://services.mindtouch.com/deki/draft/2006/11/dekiwiki is the type name used to instantiated our service-oriented wiki API, but the Uri doesn’t resolve to anything. It’s just a name that relies on domain ownership to avoid namespace collisions.
Just use Uri and never look back… :)
This helped quite a bit actually, great link to save and show to my fellow coders.
Sadly, this article is almost completely wrong. I wrote a response to the author, but since this site will potentially mislead many people, I’m reposting my comment here:
I’m not sure if you’ll find it constructive to say this, but this post is quite misleading. The first time I saw it I just ignored it, but since someone else linked to you, I have to say that a URL is a deprecated term for a URI that includes the network location and scheme. A URI is much more flexible.
So to break it down:
1. URI vs URL doesn’t have anything to do with extensions representing mime types nor content negotiation
2. It’s never preferred to use the term URL in a modern technical application because the term is deprecated, it is only appropriate in colloquial use, where “URL” still rules
3. Content negotiation lives within the world of HTTP (in the context of your article), addressing lives within the world of URIs, the HTTP scheme happens to use URI’s “generic syntax” for resource identifiers. This is not a HTTP-specific syntax by any means
4. A URL with or without an extension would be just as right either way, it lives in a different world from HTTP content negotiation
I guess the really important thing is that it’s just not appropriate to use the term URL in a modern technical context at all. The term has no meaning or importance technically, only culturally. One could argue that in a colloquial sense, URI and URL mean exactly the same thing.
To read Tim Berners-Lee on the topic:
“A URI can be further classified as a locator, a name, or both. The term “Uniform Resource Locator” (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network “location”).”
From Uniform Resource Identifier (URI): Generic Syntax, http://gbiv.com/protocols/uri/rfc/rfc3986.html#URLvsURN
Helpful or not, above explanation places misleading emphasis on the extension part. I think simplest explanation works best:
URI identifies. URL locates.
or
URI is a name. URL is a location.
A rectangle isn’t a square but a square is a rectangle. It doesn’t help much saying we should stick to URI because URL is more specific. When is it right to use URL? I understand it is a URI but it is specialised into a URL.
OK, I’ve been reading an hilarious discussion (http://www.webmasterworld.com/webmaster/3215887-2-30.htm) which degenerates into acronym vs. abbreviation pedantic antics.
“A URL is a URI, but a URI is not necessarily a URL. ”
A URI can be a name, a location or both. A URL is a location and a URI. But the same string sequence can be a URI name too.
Would this be correct then:
URL (Location): mailto:joe@soap.com
URI (Name): isbn:0374479550
URI (Name): http://soap.com/joe
URL (Location): http://soap.com/joe
isbn:0374479550 != URL as it does not specify a network location. You can’t get to it. It is just an name/identifier.
From the W3C site, “Uniform Resource Identifiers (URIs, aka URLs) are short strings that identify resources in the web: documents, images, downloadable files, services, electronic mailboxes, and other resources” (source: http://www.w3.org/Addressing/#rfc3986)
…
My view is that it’s silly to bother with arguing over whether URI or URL is the “officially proper” acronym to use. If you use one of these acronyms, and the person or people you are communicating with understand the idea you’re trying to get across – then you’ve used the right acronym. If you use one of these acronyms, and people don’t understand the point you’re trying to get across – then you’ve used the wrong acronym; so try using a different term, like ‘web address’, instead.
Thanks this was a misconception that I had. I essentially thought they were the same things.
Justin Are you site smart?
You got it all wrong. It is not about if a URI is a name is a locator or not. Or if the URI has a file extension or not. (URI never has the concept of file extension, it is that you think it has a file extension. ). It is about if a URI is bound with a network protocol. In other words, if you can get something back from the URI. W3C didn’t realize this earlier. Now, the term URL and URN is deprecated because the distinction is arbitrary.
Just use URI from now on.
See the URI spec http://www.ietf.org/rfc/rfc3986.txt.
This article is completely wrong and it makes me doubt why I’m still subscribed to this feed.
For lost souls: http://en.wikipedia.org/wiki/Uniform_Resource_Identifier describes it correctly.
I agree, the article is misleading. A URI merely gives a resource a name and doesn’t say where you’ll find it. The same resource can be found at multiple locations (without regard to filename extension). A URL tells you “if you go here, you’ll find the resource” without regard to its name. However, the URL can also be used as a URI.
I try to explain the difference using examples with made-up schemes:
fuel:coal = URI (identifies/names the resource)
mine:US-PA-NewEagle-MapleCreekMine = URL (specifies an address/location)
food:Beef-Bowl = URI
restaurant:HK-Central-Yoshinoya = URL
blog:Ajaxian = URI
website:www.ajaxian.com = URL
doh, I didn’t know user agents actually do the content negociation themselves :p That could come in handy.
I am the author of the original and I wanted to point out that the post DID contain A LOT of in accuracies as many commenter’s here, and at my blog, have pointed out. I have since updated that post so you may want to remove quotes you cited from the original post.
Ryan-
Dan Conolly wrote an excellent paper back in 2005 about this topic :
http://markkit.net/archive/www-128.ibm.com_developerworks_xml_library_x-urlni.html.html
I’ve read far too much on this topic over the past year or so and while finding no real conclusion. Just a bunch of he said/she said. Can anyone explain this in a concise manner – in a way that won’t invoke someone else to say – um… no it’s not? It only makes me chuckle and wonder… if something like this is not relatively understood by a significant amount of technically skilled people with direct experience in the area, might it be that it’s not yet clearly established what the difference is? Perhaps it’s more analog than digital.
Oh, and wouldn’t this would make a great spam bot question :).
maybe you are just too lazy to read.
1- URLs are URIs
2- URLs are required to be a valid location, URIs are not
this is a valid URI whereas it is not a valid URL :
slim://md5/3a2db9eb9a4fe0db9d2a86f34f8b86e6
i can’t be more concise, if you still do not understand, you will have to read the document.
Remind me why I should care about this?
19, 20 comments so far and counting. And not everyone has the same view. No wonder why everyone else still don’t know the difference. Kind of sad.
Why everyone is so lazy, just check the official URI specification. In section 1.1.3 of IETF RFC3986 (http://www.ietf.org/rfc/rfc3986.txt), here I quote,
“An individual scheme does not have to be classified as being just one of “name” or “locator”. Instances of URIs from any given scheme may have the characteristics of names or locators or both, often depending on the persistence and care in the assignment of identifiers by the naming authority, rather than on any quality of the scheme. Future specifications and related documentation should use the general term “URI” rather than the more restrictive terms “URL” and “URN” [RFC3305]. ”
Do we need say anything more?
“More often than not, URI is the correct term to use when referring to the location of resources on the WWW.”
I totally disagree. URL is not deprecated. It has a specific use. URI is *recommended* because it increases flexibility in vocabulary and applications of its use, but an [a href=".."] value or [img src=".."] is ALWAYS, ALWAYS, ALWAYS a URL in that context. (A [script src=".."], on the other hand, can be a URI; see cachefile.net.)
… and it really IS pronounced “jiff”, y’know…. ;-)
(I think one of the essentials of a sound technology is being able to explain it easily. People argue about REST without saying “it’s being able to store an application state in a long ugly URL”, probably because we can’t even yet agree on what an URL is.)
If you want to use URL, define “location” first? Can you?
Does any place in a http URI uses IP address? None!
(1) A URI is at first a name.
(2) A URI can be bound with a suite of network protocols, such as HTTP/DNS etc., for http-URI to make it dereferencible within the web.
But whether a URI locates something or not is not determined by the composition of URI. It is dependent if a server and client software supports it.
Let me repeat:
A URI is a URL only if there is supports to make it so but not because there is some special characteristics, such as a special scheme, extension, etc., of the URI.
Is it clear?
URL stands for Ugly and Really Long
URI stands for Unknown and Really Insightful
*sigh*
REST stands for Really Enhanced Stupid Text
Yeah…:-)
The comment posted by Xioashu Wang explains it all!!i guess it means URI is useless widout a URL??Correct me,if m wrong!!