Hotlinking — or inline linking — occurs when a third-party site displays your images by directly linking their URLs from your server. The result: their site consumes your bandwidth, depletes your transfer quota and puts load on your server, without you gaining any benefit. In 2026, hotlinking remains one of the most common abuses on the web. Here are all the methods to protect yourself effectively.
Understanding hotlinking and its consequences
When a site embeds an image via an <img src="https://yourdomain.com/photo.jpg"> tag on its own pages, your server responds to every load of their page. In practice:
- Your bandwidth is consumed to feed a third-party site
- Your monthly transfer quota runs out faster
- Your server bears additional load with every visit to the offending site
- You pay for hosting images that serve to enrich other sites' content
In extreme cases, a heavily visited site hotlinking your images can cause server overload or quota overage that makes your own site inaccessible.
Method 1: blocking hotlinking via .htaccess (Apache)
This is the most classic and effective method on Apache servers. The .htaccess file allows you to check the HTTP Referer header of each request — if the request does not come from your domain, it is blocked or redirected.
Add these lines to your .htaccess file at the root of your site:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www.)?yourdomain.com [NC]
RewriteRule .(jpg|jpeg|png|gif|webp|svg|avif)$ - [F,L]This rule blocks any image request whose Referer is not your domain. You can replace [F,L] (403 error) with a redirect to a warning image:
RewriteRule .(jpg|jpeg|png|gif|webp|svg|avif)$ https://yourdomain.com/no-hotlink.png [R,L]Good to know: the condition RewriteCond %{HTTP_REFERER} !^$ allows requests with no Referer (direct access, bookmarks, developer tools). If you want to block these too, remove this line — but be aware this can prevent your images from displaying in some legitimate contexts such as HTML emails or RSS aggregators.
Method 2: blocking hotlinking via Nginx
On an Nginx server, protection is configured in the server or location block of your configuration file:
location ~* .(jpg|jpeg|png|gif|webp|svg|avif)$ {
valid_referers none blocked yourdomain.com *.yourdomain.com;
if ($invalid_referer) {
return 403;
}
}The valid_referers none blocked directive allows direct access (none) and requests without a Referer (blocked). Only the listed domains are allowed to embed your images.
Method 3: using the Referrer-Policy header
The HTTP Referrer-Policy directive controls what Referer information is sent with requests from your site. By setting a restrictive policy, you reduce the information available to third-party sites — but this method does not actively protect your images, it only limits the propagation of your site's URL.
For basic protection, add to your .htaccess:
Header set Referrer-Policy "same-origin"Method 4: CDN-based protection
If you host your images via a CDN (Cloudflare, AWS CloudFront, Fastly…), hotlinking protection is generally available natively in the admin panel:
- Cloudflare: enable the "Hotlink Protection" rule in the Scrape Shield tab of your dashboard. It automatically blocks image requests from unauthorised domains
- AWS CloudFront: use a Lambda@Edge function to check the Referer header and block unauthorised requests
- Bunny CDN: hotlinking protection is available directly in the storage zone settings
The CDN advantage is twofold: protection is handled at the distribution network level, before even reaching your origin server, and it applies to all your assets without modifying your server configuration.
Method 5: regularly renaming and moving your images
A less technical but complementary approach is to periodically change your image URLs. Any external direct link immediately becomes invalid. This can be automated via a renaming script or content-hash-based asset management (as Webpack or Vite do natively for CSS and JS files).
Method 6: using temporary access tokens
For sensitive or high-traffic images, generating signed URLs with expiry is the most robust protection. The principle: each image URL contains a cryptographic token valid for a limited duration (1h, 24h…). After this time, the URL is no longer valid.
- AWS S3: Presigned URL generation via the AWS SDK
- Cloudflare R2: signed URLs with configurable expiry
- Bunny CDN: URL signing with secret key and timestamp
| Method | Difficulty | Effectiveness | CDN compatible |
|---|---|---|---|
| .htaccess (Apache) | Easy | Good | Partial |
| Nginx config | Intermediate | Good | Partial |
| Native CDN (Cloudflare…) | Very easy | Very good | Yes (native) |
| Periodic renaming | Variable | Average | Yes |
| Signed URLs / tokens | Advanced | Maximum | Yes |
Good to know: no anti-hotlinking protection is completely foolproof. A determined site can always download your images and re-host them on its own servers — in that case, it becomes a copyright issue, not a hotlinking one. Protection via .htaccess or CDN covers the vast majority of abusive cases and is sufficient to protect your bandwidth on a daily basis.