Hotlinking is when another site embeds your images by linking directly to the files on your server. Their page displays your image; your bandwidth pays for it, on every visit they receive.
Hotlink protection refuses those requests. The image loads on your own pages and fails on theirs.
Whether you have a problem
Do not enable this speculatively. Check first.
Look at bandwidth usage against your allocation. If it is unremarkable, hotlinking is not costing you anything worth acting on.
If it is high, the access log shows which files are being requested and where from. A referrer that is not your own domain, appearing repeatedly against the same image, is hotlinking. Viewing website statistics covers reading the log.
Most sites never need this. It matters when one image is being embedded widely, and it matters most when that image is large.
Enabling it
In cPanel, open Hotlink Protection under Security.
URLs to allow. Your own domains, and cPanel usually pre-fills them. Include every form the site is reached by. The bare domain, www, and any subdomain that displays these images. Missing one means your own pages stop showing images, which is the most common way this setting backfires.
Extensions to protect. Image formats by default. Add PDF or video formats if those are what is being consumed.
Allow direct requests. Leave this on. It permits requests with no referrer at all, which is what happens when someone opens an image URL directly, and also what some legitimate clients send. Turning it off blocks more than you intend.
What it also blocks, which you may not want
The mechanism cannot tell a thief from anyone else fetching your image from elsewhere. So it blocks several things people rely on.
Search engine image indexing. If image search sends you traffic, this reduces it.
Social media link previews. Platforms fetch the image to build a card. Blocked, and your links lose their thumbnail.
Images in newsletters you sent. The recipient's mail client fetches from your server with no useful referrer.
CDNs and caching services that pull the file to distribute it.
None of these are hotlinking, and all of them look identical to it from the server's point of view.
A gentler alternative
Rather than refusing the request, serve a different image to external referrers. cPanel offers a redirect URL for blocked requests.
Point it at a small image saying where the picture came from. The other site's page still works, your bandwidth cost drops to almost nothing, and their visitors see your name.
That is often a better outcome than a broken image, particularly when the embedding site is not malicious. Most hotlinking is thoughtless rather than deliberate.
Watermarking instead
If the concern is attribution rather than bandwidth, hotlink protection is the wrong tool entirely.
A visible watermark travels with the image wherever it is copied, including when someone downloads and re-uploads it, which hotlink protection does nothing about, since the file is then on their server.
Decide which problem you actually have. Bandwidth is a hosting setting; attribution is an image-preparation habit.
Test both directions after enabling
Load your own site in a private window and confirm images still appear: on the homepage, on a deep page, and on any subdomain.
Then check that a social preview still works by pasting a link into a chat or a post editor.
If your own images break, a domain is missing from the allow list. That is the failure this setting produces, and it is easy to miss because your browser has the images cached.
If bandwidth is the real problem
Hotlinking is rarely the largest cause. Oversized images are.
An image uploaded at camera resolution and displayed at 400 pixels wide costs bandwidth on every one of your own visits, which is a far larger number than any hotlinker generates. Resizing before upload and using a modern format usually saves more than this setting ever will. There is more in optimizing WordPress performance.
Read the referrers before deciding
The question is not whether other sites link to your images. It is how much traffic that costs, and the log answers it.
awk '$9 ~ /200/ && $7 ~ /\.(jpg|jpeg|png|webp|gif)$/ {print $11}' ~/logs/example.com \
| sed 's|https\?://||; s|/.*||' | sort | uniq -c | sort -rn | head -20
That lists which domains requested your images, most frequent first. Your own domain should dominate. Search engines, social networks and mail providers will appear and are wanted.
What you are looking for is a single unfamiliar domain with a large count. If nothing like that exists, hotlinking is not your problem and the rule will only cost you. Where server logs live explains finding the file.
Empty referrers are now normal
The protection works by reading where the request came from, and browsers have spent years sending less of that information.
A visitor arriving from a search result, a link in a document, an app, or any site sending a restrictive referrer policy may present nothing at all. Blocking empty referrers therefore blocks real people, and the reports are hard to reproduce because it depends on where the visitor came from.
curl -sI -o /dev/null -w '%{http_code}\n' https://example.com/image.jpg
curl -sI -o /dev/null -w '%{http_code}\n' -e 'https://example.com/' https://example.com/image.jpg
The first request has no referrer. If it answers with a redirect or a refusal while the second succeeds, the rule is set to block empty referrers, and that is the setting to reconsider first.
A CDN changes where the rule belongs
With a cache in front, most image requests never reach your server, so a rule on the origin sees a fraction of the traffic and blocks almost nothing.
Worse, the first request populates the cache and every subsequent one is served by the CDN regardless of who asked. The rule appears to work when you test it and does not work in practice.
Where a CDN is in use, the restriction has to be configured there. Most offer it directly, and it is applied at the edge where the request actually arrives. Choosing and setting up a CDN goes into that layer.
When the file genuinely must be protected
Referrer checks are a courtesy control. Anyone who wants the file can send whatever referrer you require, and it takes one command.
For material that has real value, the answer is a link that expires. The file lives outside the web root, and a script issues a time-limited address after checking whatever condition matters, such as a login or a completed order.
That is more work and it is the only version that holds. Watermarking sits between the two, since it does not prevent copying and it does keep your name attached. Selling digital and downloadable products deals with the delivery side.