I would like to know the differences between these two types of URLs: relative URLs (for pictures, CSS files, JS files, etc.) and absolute URLs.
In addition, which o
In most instances relative URLs are the way to go, they are portable by nature, which means if you wanted to lift your site and put it someone where else it would work instantly, reducing possibly hours of debugging.
There is a pretty decent article on absolute vs relative URLs, check it out.
Assume we are creating a subsite whose files are in the folder http://site.ru/shop.
Link to home page
href="http://sites.ru/shop/"
Link to the product page
href="http://sites.ru/shop/t-shirts/t-shirt-life-is-good/"
Link from home page to product page
href="t-shirts/t-shirt-life-is-good/"
Link from product page to home page
href="../../"
Although relative URL look shorter than absolute one, but the absolute URLs are more preferable, since a link can be used unchanged on any page of site.
We have considered two extreme cases: "absolutely" absolute and "absolutely" relative URLs. But everything is relative in this world. This also applies to URLs. Every time you say about absolute URL, you should always specify relative to what.
Link to home page
href="//sites.ru/shop/"
Link to product page
href="//sites.ru/shop/t-shirts/t-shirt-life-is-good/"
Google recommends such URL. Now, however, it is generally considered that http:// and https:// are different sites.
I.e. relative to the root folder of the domain.
Link to home page
href="/shop/"
Link to product page
href="/shop/t-shirts/t-shirt-life-is-good/"
It is a good choice if all pages are within the same domain. When you move your site to another domain, you don't have to do a mass replacements of the domain name in the URLs.
The tag <base> specifies the base URL, which is automatically added to all relative links and anchors. The base tag does not affect absolute links. As a base URL we'll specify the home page: <base href="http://sites.ru/shop/">.
Link to home page
href=""
Link to product page
href="t-shirts/t-shirt-life-is-good/"
Now you can move your site not only to any domain, but in any subfolder. Just keep in mind that, although URLs look like relative, in fact they are absolute. Especially pay attention to anchors. To navigate within the current page we have to write href="t-shirts/t-shirt-life-is-good/#comments" not href="#comments". The latter will throw on home page.
For internal links I use base-relative URLs (5). For external links and newsletters I use absolute URLs (1).
In general, it is considered best-practice to use relative URLs, so that your website will not be bound to the base URL of where it is currently deployed. For example, it will be able to work on localhost, as well as on your public domain, without modifications.
A URL that starts with the URL scheme and scheme specific part (http://
, https://
, ftp://
, etc.) is an absolute URL.
Any other URL is a relative URL and needs a base URL the relative URL is resolved from (and thus depend on) that is the URL of the resource the reference is used in if not declared otherwise.
Take a look at RFC 2396 – Appendix C for examples of resolving relative URLs.
For every system that support relative URI resolution, both relative and absolute URIs do serve the same goal: referencing. And they can be used interchangeably. So you could decide in each case differently. Technically, they provide the same referencing.
To be precise, with each relative URI there already is an absolute URI. And that's the base-URI that relative URI is resolved against. So a relative URI is actually a feature on top of absolute URIs.
And that's also why with relative URIs you can do more as with an absolute URI alone - this is especially important for static websites which otherwise couldn't be as flexible to maintain as compared to absolute URIs.
These positive effects of relative URI resolution can be exploited for dynamic web-application development as well. The inflexibility absolute URIs do introduce are also easier to cope up with, in a dynamic environment, so for some developers that are unsure about URI resolution and how to properly implement and manage it (not that it's always easy) do often opt into using absolute URIs in a dynamic part of a website as they can introduce other dynamic features (e.g. configuration variable containing the URI prefix) so to work around the inflexibility.
So what is the benefit then in using absolute URIs? Technically there ain't, but one I'd say: Relative URIs are more complex because they need to be resolved against the so called absolute base-URI. Even the resolution is strictly define since years, you might run over a client that has a mistake in URI resolution. As absolute URIs do not need any resolution, using absolute URIs have no risk to run into faulty client behaviour with relative URI resolution. So how high is that risk actually? Well, it's very rare. I only know about one Internet browser that had an issue with relative URI resolution. And that was not generally but only in a very (obscure) case.
Next to the HTTP client (browser) it's perhaps more complex for an author of hypertext documents or code as well. Here the absolute URI has the benefit that it is easier to test, as you can just enter it as-is into your browsers address bar. However, if it's not just your one-hour job, it's most often of more benefit to you to actually understand absolute and relative URI handling so that you can actually exploit the benefits of relative linking.
If by absolute URLs you mean URLs including scheme (e.g. http / https) and the hostname (e.g. yourdomain.com) don't ever do that (for local resources) because it will be terrible to maintain and debug.
Let's say you have used absolute URL everywhere in your code like <img src="http://yourdomain.com/images/example.png">
. Now what will happen when you are going to:
In the first example what will happen is that you will get warnings about unsafe content being requested on the page. Because all your URLs are hardcoded to use http(://yourdomain.com/images/example.png). And when running your pages over https the browser expects all resources to be loaded over https to prevent leaking of information.
In the second example when putting your site live from the test environment it would mean all resources are still pointing to your test domain instead of your live domain.
So to answer your question about whether to use absolute or relative URLs: always use relative URLs (for local resources).
First lets have a look at the different types of urls that we can use:
http://yourdomain.com/images/example.png
//yourdomain.com/images/example.png
/images/example.png
images/example.png
In the examples below I assume the website is running from the following location on the server /var/www/mywebsite
.
http://yourdomain.com/images/example.png
The above (absolute) URL tries to access the resource /var/www/website/images/example.png
. This type of URL is something you would always want to avoid for requesting resources from your own website for reason outlined above. However it does have its place. For example if you have a website http://yourdomain.com
and you want to request a resource from an external domain over https you should use this. E.g. https://externalsite.com/path/to/image.png
.
//yourdomain.com/images/example.png
This URL is relative based on the current scheme used and should almost always be used when including external resources (images, javascripts etc).
What this type of URL does is use the current scheme of the page it is on. This means that you are on the page http://yourdomain.com
and on that page is an image tag <img src="//yourdomain.com/images/example.png">
the URL of the image would resolve in http://yourdomain.com/images/example.png
.
When you would have been on the page http**s**://yourdomain.com
and on that page is an image tag <img src="//yourdomain.com/images/example.png">
the URL of the image would resolve in https://yourdomain.com/images/example.png
.
This prevent loading resources over https when it is not needed and automatically makes sure the resource is requested over https when it is needed.
The above URL resolves in the same manner on the server side as the previous URL:
The above (absolute) URL tries to access the resource
/var/www/website/images/example.png
.
/images/example.png
For local resources this is the prefered way of referencing them. This is a relative URL based on the document root (/var/www/mywebsite
) of your website. This means when you have <img src="/images/example.png">
it will always resolve to /var/www/mywebsite/images/example.png
.
If at some point you decide to switch domain it will still work because it is relative.
images/example.png
This is also a relative URL although a bit different than the previous one. This URL is relative to the current path. What this means is that it will resolve to different paths depending on where you are in the site.
For example when you are on the page http://yourdomain.com
and you use <img src="images/example.png">
it would resolve on the server to /var/www/mywebsite/images/example.png
as expected, however when your are on the page http://yourdomain.com/some/path
and you use the exact same image tag it suddenly will resolve to /var/www/mywebsite/some/path/images/example.png
.
When requesting external resources you most likely want to use an URL relative to the scheme (unless you want to force a different scheme) and when dealing with local resources you want to use relative URLs based on the document root.
An example document:
<!DOCTYPE html>
<html>
<head>
<title>Example</title>
<link href='//fonts.googleapis.com/css?family=Lato:300italic,700italic,300,700' rel='stylesheet' type='text/css'>
<link href="/style/style.css" rel="stylesheet" type="text/css" media="screen"></style>
</head>
<body>
<img src="/images/some/localimage.png" alt="">
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" ></script>
</body>
</html>