Absolute vs relative URLs

Question

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

Answer 1

Let's say you have a site www.yourserver.com. In the root directory for web documents you have an images sub-directoy and in that you have myimage.jpg.

An absolute URL defines the exact location of the document, for example:

http://www.yourserver.com/images/myimage.jpg

A relative URL defines the location relative to the current directory, for example, given you are in the root web directory your image is in:

images/myimage.jpg

(relative to that root directory)

You should always use relative URLS where possible. If you move the site to www.anotherserver.com you would have to update all the absolute URLs that were pointing at www.yourserver.com, relative ones will just keep working as is.

Answer 2

There are really three types that should be discussed explicitly. In practice though URLs have been abstracted to be handled at a lower level and I would go as far as to say that developers could go through their entire lives without writing a single URL by hand.

Absolute

Absolute URLs tie your code to the protocol and domain. This can be overcome with dynamic URLs.

<a href=“https://dev.example.com/a.html?q=”>https://dev.example.com/a.html?q=</a>

Absolute Pros:

1. Control - The subdomain and protocol can be controlled. People that enter through an obscure subdomain will be funneled into the proper subdomain. You can hop back and forth between secure and non-secure as appropriate.

2. Configurable - Developers love things to be absolute. You can design neat algorithms when using absolute URLs. URLs can be made configurable so that a URL can be updated site-wide with a single change in a single configuration file.

3. Clairvoyance - You can search for the people scraping your site or maybe pick up some extra external links.

---

Root Relative

Root Relative URLs tie your code to the base url. This can be overcome with dynamic URLs and/or base tags.

<a href=“/index.php?q=”>.example.com/index.php?q=</a>

Root Relative Pros:

1. Configurable - The base tag makes them relative to any root you choose making switching domains and implementing templates easy.

---

Relative

Relative URLs tie your code to the directory structure. There is no way to overcome this. Relative URLs are only useful in file systems for traversing directories or as a shortcut for a menial task.

<a href=“index.php?q=”>index.php?q=</a>
<link src=“../.././../css/default.css” />

Relative Cons:

1. CONFUSING - How many dots is that? how many folders is that? Where is the file? Why isn't it working?

2. MAINTENANCE - If a file is accidentally moved resources quit loading, links send the user to the wrong pages, form data might be sent to the incorrect page. If a file NEEDS to be moved all the resources that are going to quit loading and all the links that are going to be incorrect need to be updated.

3. DOES NOT SCALE - When webpages become more complex and views start getting reused across multiple pages the relative links will be relative to the file that they were included into. If you have a navigation snippet of HTML that is going to be on every page then relative will be relative to a lot of different places. The first thing people realize when they start creating a template is that they need a way to manage the URLs.

4. COMPUTED - They are implemented by your browser (hopefully according to RFC). See chapter 5 in RFC3986.

5. OOPS! - Errors or typos can result in spider traps.

---

The Evolution of Routes

Developers have stopped writing URLs in the sense being discussed here. All requests are for a website's index file and contain a query string, aka a route. The route can be thought of as a mini URL that tells your application the content to be generated.

<a href="<?=Route::url('named_url', array('first' => 'my', 'last' => 'whacky'))?>">
    http://dev.example.com/index.php/my:whacky:url
</a>

Routes Pros:

1. All the advantages of absolute urls.
2. Use of any character in URL.
3. More control (Good for SEO).
4. Ability to algorithmically generate URLs. This allows the URLs to be configurable. Altering the URL is a single change in a single file.
5. No need for 404 not founds. Fallback routes can display a site map or error page.
6. Convenient security of indirect access to application files. Guard statements can make sure that everybody is arriving through the proper channels.
7. Practicality in MVC approach.

---

My Take

Most people will make use of all three forms in their projects in some way or another. The key is to understand them and to choose the one best suited for the task.

Answer 3

If it is for use within your website, it's better practice to use relative URL, like this if you need to move the website to another domain name or just debug locally, you can.

Take a look at what's stackoverflow is doing (ctrl+U in firefox):

<a href="/users/recent/90691"> // Link to an internal element

In some cases they use absolute urls :

<link rel="stylesheet" href="http://sstatic.net/so/all.css?v=5934">

... but this is only it's a best practice to improve speed. In your case, it doesn't look like you're doing anything like that so I wouldn't worry about it.

Answer 4

I'm going to have to disagree with the majority here.

I think the relative URL scheme is "fine" when you want to quickly get something up and running and not think outside the box, particularly if your project is small with few developers (or just yourself).

However, once you start working on big, fatty systems where you switch domains and protocols all the time, I believe that a more elegant approach is in order.

When you compare absolute and relative URLs in essence, Absolute wins. Why? Because it won't ever break. Ever. An absolute URL is exactly what it says it is. The catch is when you have to MAINTAIN your absolute URLs.

The weak approach to absolute URL linking is actually hard coding the entire URL. Not a great idea, and probably the culprit of why people see them as dangerous/evil/annoying to maintain. A better approach is to write yourself an easy to use URL generator. These are easy to write, and can be incredibly powerful- automatically detecting your protocol, easy to config (literally set the url once for the whole app), etc, and it injects your domain all by itself. The nice thing about that: You go on coding using relative URLs, and at run time the application inserts your URLs as full absolutes on the fly. Awesome.

Seeing as how practically all modern sites use some sort of dynamic back-end, it's in the best interest of said site to do it that way. Absolute URLs do more than just make you certain of where they point to- they also can improve SEO performance.

I might add that the argument that absolute URLs is somehow going to change the load time of the page is a myth. If your domain weighs more than a few bytes and you're on a dialup modem in the 1980s, sure. But that's just not the case anymore. https://stackoverflow.com/ is 25 bytes, whereas the "topbar-sprite.png" file that they use for the nav area of the site weighs in at 9+ kb. That means that the additional URL data is .2% of the loaded data in comparison to the sprite file, and that file is not even considered a big performance hit.

That big, unoptimized, full-page background image is much more likely to slow your load times.

An interesting post about why relative URLs shouldn't be used is here: Why relative URLs should be forbidden for web developers

An issue that can arise with relatives, for instance, is that sometimes server mappings (mind you on big, messed up projects) don't line up with file names and the developer may make an assumption about a relative URL that just isn't true. I just saw that today on a project that I'm on and it brought an entire page down.

Or perhaps a developer forgot to switch a pointer and all of a sudden google indexed your entire test environment. Whoops- duplicate content (bad for SEO!).

Absolutes can be dangerous, but when used properly and in a way that can't break your build they are proven to be more reliable. Look at the article above which gives a bunch of reasons why the Wordpress url generator is super awesome.

:)

Answer 5

See this: http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax

foo://username:password@example.com:8042/over/there/index.dtb;type=animal?name=ferret#nose
\ /   \________________/\_________/ \__/            \___/ \_/ \_________/ \_________/ \__/
 |           |               |       |                |    |       |           |       |
 |       userinfo         hostname  port              |    |       parameter query  fragment
 |    \_______________________________/ \_____________|____|____________/
scheme                |                               | |  |
 |                authority                           |path|
 |                                                    |    |
 |            path                       interpretable as filename
 |   ___________|____________                              |
/ \ /                        \                             |
urn:example:animal:ferret:nose               interpretable as extension

An absolute URL includes the parts before the "path" part - in other words, it includes the scheme (the http in http://foo/bar/baz) and the hostname (the foo in http://foo/bar/baz) (and optionally port, userinfo and port).

Relative URLs start with a path.

Absolute URLs are, well, absolute: the location of the resource can be resolved looking only at the URL itself. A relative URL is in a sense incomplete: to resolve it, you need the scheme and hostname, and these are typically taken from the current context. For example, in a web page at

http://myhost/mypath/myresource1.html

you could put a link like so

<a href="pages/page1">click me</a>

In the href attribute of the link, a relative URLs used, and if it is clicked, it has to be resolved in order to follow it. In this case, the current context is

http://myhost/mypath/myresource1.html

so the schema, hostname, and leading path of these are taken and prepended to pages/page1, yielding

http://myhost/mypath/pages/page1

If the link would have been:

<a href="/pages/page1">click me</a>

(note the / appearing at the start of the URL) then it would have been resolved as

http://myhost/pages/page1

because the leading / indicates the root of the host.

In a webapplication, I would advise to use relative URLs for all resources that belong to your app. That way, if you change the location of the pages, everything will continue to work. Any external resources (could be pages completely outside your application, but also static content that you deliver through a content delivery network) should always be pointed to using absolute URLs: if you don't there simply is no way to locate them, because they reside on a different server.

Answer 6

I would heartily recommend relative URLs for pointing bits of the same site to other bits of the same site.

Don't forget that a change to HTTPS - even if in the same site - is going to need an absolute URL.