Even if you expressly ask them not to, some webmasters will try to directly link to your images from their pages. By stealing your images in this way they’re using up your site’s bandwidth without notifying their visitors of your site, which means you get no credit and a bigger bandwidth bill at the end of the month. Erk! Luckily, a simple configuration change provides the necessary fix.

The Swindle

So how exactly is this dastardly deed carried out? It’s a simple ruse: the offending webmaster sees an image they like the look of on your site. Smiling craftily, they murmur “I’ll have that,” and proceed to write an img tag like this:

<img src="https://www.yoursite.com/media/image.gif" alt="I eat bandwidth for breakfast">

Your image will then appear on their site as if it was one of their own. This practice is known as “hotlinking” or “leeching” an image. It’s rude, and often infringes on the copyright of the image.

You’ll often see people hotlinking images to use as their » avatar or signature image on messageboards. It is a poor strategy to link to images stored on a separate server than the one your webpages are on, as it slows the loading of the page, not to mention leaving you wide open to embarrassing retribution of the » “switcheroo” variety.

A webmaster could also offer a link to an image on your site, like this:

<a href="https://www.yoursite.com/media/image.gif">Download this image</a>

This is pretty much the same deal, though at least this time people will see that they’re getting the image from a different server than the one that referred them to it. However, this is poor form, and it would be much better for the webmaster in question to either take a local copy of the image (save it on their own server and link to that image, provided there’s no copyright infringement), or link to a page on your site that has the image on it.


What we want to do is to stop images from loading on remote sites by redirecting all requests for them to another location.

Locking the Door

As with most configuration changes in this section, this technique requires that your site is hosted on a computer running the Apache web server. The vast majority of servers do run Apache, since it’s free and excellent, although those of you on IIS or whatever could consider this » PHP solution.

So, how are we going to work this? Well, whenever an image is requested from a server, the page that referred to this image is sent as part of the request. This is the page that linked to the image or the page that contained the img call to it. We can look at this referrer, and if it doesn’t match a list of sites that you allow to link to your images, you can block the image from being sent.

Let’s Do This Thing

Open your .htaccess (or create a new one), and add these lines:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^https://(www\.)?yoursite\.com [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} ^https://.*$
RewriteRule \.(jpe?g|gif|bmp|png)$ /media/nohotlinks.png [L]

We’re using URL rewriting to redirect any unwanted image requests. If you’ve done any redirecting before this should seem straightforward enough. Let me step through this, line by line:

• Before we do any redirect, we set down some conditions — those are the twoRewriteConds. The first checks if the variable HTTP_REFERER does not start with either https://yoursite.com or https://www.yoursite.com (the question mark meaning “zero or one occurrences of the preceding parentheses,” and the exclamation mark negating the match). The [NC] flag simply makes the match case-insensitive.
• The second condition checks if no referrer was sent, which may occur if a visitor typed the image’s address into the location bar. We don’t want to block those requests.
• The third condition checks if the referrer header does actually contain another website’s URL. This is to guard against doing the wrong thing in the case of users with special software on their computers that replace all referrer headers they send with text like “Blocked by personal firewall.” Again, we don’t want to block those requests.
• If all of these conditions are true, we know that the image is being requested from a remote site, and can go ahead with the redirect. “HTTP_REFERER” (with one ‘r’) is not a mistake; some joker on the HTTP team just couldn’t spell, and this has survived as a geeky joke ever since.
• The RewriteRule itself is a simple one. It simply looks at the file extension of the file being served. If the file has any of the extensions listed, it is rewritten to our ‘nohotlinks’ image.

sourcetip: Don’t try to redirect blocked image requests to a HTML page instead of this ‘nohotlinks’ image. It won’t work, because the browser is expecting a file with the MIME type of an image, and so will only accept another image.

The image you redirect to should obviously be small or you’re defeating the purpose. What you put in the image is up to you — people have had past success with retina-searing animations or the aforementioned » humourous replacement strategy.

If you would like instead to simply block the images completely and not redirect to another image, you can send back a “403 Forbidden” error message by replacing the RewriteRuleabove with this:

RewriteRule \.(jpe?g|gif|bmp|png)$ - [F]


Nobody’s Perfect...

There are some isolated cases when this won’t work. Some tools that allow people to surf “anonymously” will not send proper referrer headers, meaning that images will become broken on your own site for these visitors. Some proxies and firewalls will have the same effect. However, this won’t affect the vast majority of your visitors, and those who use referrer-hiding services are likely well aware of the side-effects.