Understanding how document paths work can be a tricky thing for even the most seasoned of application developers. If you’ve spent any amount of time developing a dynamic application, you’ve probably run into some sort of issue with resources not being found. Evaluating what type of path you need to use is the first step. We’ll evaluate the pros and cons of each of these path formats, and hopefully this will guide you to choose the best method for your needs.

When you first start into web development you’re introduced to 3 different path formats:

Relative Paths

Say we want to link to an image. We’re editing the default file in the root of the project, and the image is in the “images” folder, which is also in the root. Our code would look something like this:

<img src=”images/some-image.jpg” />

The benefit to this is that it works in a variety of circumstances. If you move between local, development, testing, and production environments this path will work across all of them.

However, let’s say that this image is in a master page in a folder called “master-pages.” Your path is going to change to something like this:

<img src=”../images/some-image.jpg” />

This won’t display if you utilize the master page from the default file because it’s looking for a folder that’s one step down from the root folder. This is easily solved by changing the path back to the first one, but say that you’re utilizing the master page in a document that’s 3 levels deep. This starts to become increasingly complicated.

Root Relative Paths

We can solve the above problem by using a root relative path. For example:

<img src=”/images/some-image.jpg” />

By using the “/” at the beginning of the path, you’re now using the root directory as a reference point. This is the ideal path in most circumstances because your root directory is not likely to change.
But again, there are also issues with this path. When you’re working locally, your root directory starts to become more of an abstract concept. If you try to open the file directly, you will be referencing the root of the drive. If you’re working on a development server, your URL may be something like “http://localhost/MyApp” where the root directory is referencing the root of the server. Therefore the root path is “http://localhost/” not including “MyApp” in the path. You would have to set the image path like this in a local environment:

<img src=”/MyApp/images/some-image.jpg” />

This would have to be changed when moving to a production environment. As you can imagine this could be a very tedious process to go live, and would also create a problem when trying to keep multiple environments in sync.

Absolute Paths

An absolute path encompasses the entire URL. This is often used by beginners just to make sure that they are getting the correct path. However, this can also be used to reference files on other websites. For example, if I wanted to use an image on the alligatortek site I would use this:

<img src=”http://www.alligatortek.com/images/some-image.jpg”  />

Obviously it’s easier to keep things in sync, but if you’re using this for all of your paths; you’d have to upload your images every time you wanted to test something. This also makes it harder to scale your projects, or move your app between domains.

This is actually the preferred method when you’re using outside services to host different parts of your site (like a YouTube video). The problem comes when you’re hosting your site on an SSL. Modern browsers will throw security alerts, telling the users that the site is trying to access non-secure content. This leads us to our next path type.

Protocol Relative Paths

A protocol relative path is similar to a root relative path in that it starts with a slash, but also like an absolute path because you have to include the entire domain. If you want to include an image from an external source, and pull it from a port that matches your security setting, you would set your path like this:

<img src=”//www.alligatortek.com/images/some-image.jpg” />

So if you’re on a secure port, this path will pull from the secure port on the alligatortek website; if you’re on a non-secure port, it will pull the image through the non-secure port on the alligatortek website. This will prevent the warning messages from appearing, as well as help your application speed because you won’t be making unnecessary requests through secure ports.

If you’ve ever tried to set up redirects to pull content through ports based on your current protocol, you might have just had an epiphany. Many developers are unaware that this type of path even exists, but will save many a lot of time.

Keep in mind that this path has the same drawbacks as an absolute path.

Application Relative Paths

This is by far one of the greatest benefits of developing in a .NET environment. When you set up an application in IIS, you are setting the application root. Many beginners (and quite a few veterans) don’t realize that you can turn any html tag into a server control. When you do this you can precede the root relative path with a “~” in order to tell the server that you want to make the path relative to the application. Your new image tag will look like this:

<img src=”~/images/some-image.jpg” runat=”server” />

This puts a little strain on the server side, but this will ensure that your paths are consistent across all environments. It’s a real time saver, and will also re-write your path at a page level instead of in relation to where the image is called (like in a relative path).

One final consideration is when you write paths out of C# or VB.NET. If you would like to use an application relative path, you have to parse the path rather than just writing the string when you are setting the attributes dynamically. The server will often write the “~” as a plain string of text, which won’t find you the element that you’re looking for.

Choose Your Path

The bottom line is that I can’t tell you which path type you should be using because it’s completely circumstantial. I just hope that this will help you make a more informed decision. Leave a comment below if there’s something that you would like to add to the conversation.