Back to Blog
Tech

Images Break When Posted Elsewhere? The 403 & Hotlink Debug Tree (2026)

Published on13 min read
Share

You paste an image link into a blog post. Local preview looks perfect. You publish, and what everyone else sees is a broken-icon frame. Or worse — the whole image slot goes blank, nothing there at all.

I've fallen into this hole more than once. One production blowup was migrating images for a friend's forum: all green locally, and after going live a third of the homepage thumbnails were broken. I assumed it was a stale cache. Three days of debugging later, the problem wasn't mine at all — the source site had hotlink protection on, and any request not coming from its own domain got blocked, full stop.

From an architecture standpoint, "the image won't display on another site" is really three completely different failures jammed under one label. To fix the right one, step one is figuring out which you've got.

First, separate them: 403, broken icon, and blank-200 are three different things

Plenty of people see a missing image, call it all "broken," and start flailing. But these three symptoms have very different root causes and very different debug paths.

Symptom HTTP status Most likely root cause Debug direction
Cracked-icon frame 403 / 404 Hotlink protection blocked it, or the link is just wrong Check Referer and URL correctness
Cracked-icon frame 200 but not an image You got an HTML error page, not the image file Check Content-Type
Blank slot (no cracked icon) 200 CSS covered it, or CSP blocked the load Check DevTools Console and CSP
Icon spins then vanishes Timeout / CORS Cross-origin policy or server timeout Check the request details in Network

Status code first, Content-Type second, the visual last. Reverse that order and you'll chase your tail.

Under the hood: how Referer and hotlink protection work

To get why another site's image is blocked, you first need to know what the browser quietly does when loading an image.

When page A uses <img src="https://B.com/photo.jpg"> to load B's image, the request the browser sends carries a Referer header (yes, that word was misspelled historically — one 'r' short — and the typo stuck to this day). That header tells B: "this image was requested by a page on A."

Here's the mechanism: B's server or CDN gets the request and matches the Referer domain against an allowlist. The logic runs roughly like this —

1. Referer is empty (opened directly, bookmark) → config decides: allow or block
2. Referer domain is on the allowlist → allow
3. Referer domain is NOT on the allowlist → return 403 Forbidden

That's hotlink protection. Its purpose is simple: nobody wants strangers freeloading their bandwidth. When you embed B's image on your site, every visitor to your page bills the traffic to B — and B, understandably, isn't thrilled.

A detail a lot of people miss: modern browsers default Referrer-Policy to strict-origin-when-cross-origin. On a cross-origin request it sends only the origin (e.g. https://a.com/), not the full path. So hotlink protection still gets your domain name — enough to match the allowlist, and enough to block you. That's exactly why hotlink protection can defeat a hotlink.

Why your image breaks on another site: a debug tree

Unfold that mechanism and the root cause collapses into a tree. Just walk down it.

Branch 1: Is the status code 403?

If yes, it's hotlink protection nine times out of ten. B saw your Referer isn't on its allowlist and refused outright. You can't change B's config, so the only fix is to stop hotlinking its image (the real fix is below).

Branch 2: Status is 200, but the image is broken?

Open that "image's" raw content. Odds are you got a page of HTML — some sites don't return 403, they return a "no hotlinking" notice page with a 200 status. The browser tries to parse HTML as an image and, naturally, cracks. Check Content-Type and it's exposed: a real image is image/jpeg or image/png; an error page is text/html.

Branch 3: Did you paste a "page link" instead of a "direct image link"?

This is the classic beginner trap. https://imgur.com/aBcDeFg is a page; https://i.imgur.com/aBcDeFg.jpg is the image file itself. Load the former with <img src> and you get a whole page of HTML, not an image. One i. and a file extension apart, worlds of difference in the result.

Branch 4: Did Referrer-Policy shoot you in the foot?

The sneaky one. If your page sets Referrer-Policy: no-referrer, the browser sends no Referer at all when loading images. Some hotlink setups are "block all empty Referers" — so your own privacy setting gets you blocked. In practice this shows up on privacy-conscious sites that lock down the meta referrer completely.

Hands-on diagnosis: DevTools and curl, two moves

Enough theory. How do you actually check? I use two tools that pin down 90% of broken images inside five minutes.

Move 1: The DevTools Network panel

Open dev tools (F12), switch to Network, reload the page, and type the image filename in the filter. Click that request and look at three things:

  • Status: 403, 404, or 200?
  • Response header Content-Type: image/* or text/html?
  • Request header Referer: what actually went out — empty, or your domain?

Three checks and the root cause usually surfaces.

Move 2: curl to control the Referer by hand

DevTools shows you the symptom, but to verify whether it's really hotlink protection, curl is cleaner. You can stuff in any Referer and watch how the server reacts:

# No Referer at all (simulates opening the image directly)
curl -I "https://example.com/photo.jpg"

# A Referer "pretending to come from the source site itself"
curl -I -H "Referer: https://example.com/" "https://example.com/photo.jpg"

# A Referer "from your external site"
curl -I -H "Referer: https://your-blog.com/" "https://example.com/photo.jpg"

Reading it is straightforward. If requests one and three return 403 but two returns 200 — congratulations, that's a hotlink-protection lock. The server only honors the source site's own Referer and blocks the rest. If all three return 200, the broken image has nothing to do with hotlinking; go back and check your URL or CSP.

My habit is running all three at once — comparing results beats reading one line in isolation. That's why curl is more efficient than clicking around blindly in the browser.

Hotlink behavior across common hosts and CDNs

Different services have very different default tempers. Below is what I've observed over years of moving images around; actual settings can change any time, but the general shape holds.

Service type Hotlink protection by default Empty-Referer behavior Good for cross-site embedding?
Self-hosted Nginx / Apache However you set it Usually allowed Depends on config
Enterprise CDN (Cloudflare, allowlist-capable) Can be on or off Configurable allow/block Yes, if configured right
Some free image hosts Often on Often blocked Often blocked
Social platform image domains Almost always on Almost always blocked No, don't even try
Sharing-first image host Usually off Allowed Yes — that's its whole point

The last row is the key one. Images on social platform CDNs are almost 100% un-embeddable via the URL you copied out, because their business model is to keep you locked inside the app. Try to lift those images and post them elsewhere — dead end.

A sharing-first image host, by contrast, keeps hotlink protection off by default — its entire reason to exist is letting your images load reliably from other sites. Never confuse these two categories.

A word on WordPress and Cloudflare specifically

Two setups English-speaking readers hit constantly: WordPress and Cloudflare. On WordPress, the usual hotlink defense is an .htaccess mod_rewrite rule checking HTTP_REFERER — misconfigure it and you block search-engine image crawlers and your own CDN along with the leechers. On Cloudflare, hotlink protection is a one-click toggle (Scrape Shield) plus optional WAF rules; the gotcha is that turning it on can silently break legitimate embeds you wanted, like your images showing in a Discord or Slack unfurl. If your images stopped previewing in chat apps after enabling a CDN feature, that toggle is the first suspect.

The Referrer-Policy trap: even the browser can turn on you

I mentioned this hidden case earlier; let me expand it, because it's the one that debugs people into existential despair.

Referrer-Policy is a header the requesting page can set. It decides how much Referer info the browser sends. Several values:

  • no-referrer: sends nothing.
  • origin: sends only the origin domain.
  • strict-origin-when-cross-origin: cross-origin sends only the origin, downgrade to HTTP sends nothing (modern default).
  • unsafe-url: sends the full path too (not advised — leaks privacy).

Here's the contradiction. Hotlink protection needs Referer to judge the source, but privacy policy encourages sending less, or none. When a site sets no-referrer for privacy, and it loads any image with hotlink protection that "blocks all empty Referers," everything breaks.

I blew this up in production once — a very privacy-focused site ran no-referrer site-wide, and every external image broke. I assumed the host was down and spent ages checking before realizing my own meta setting had strangled the Referer. This trap is hard to anticipate, because "strengthening privacy" doesn't sound like it would hurt you.

The correct fix: don't hotlink other people's images

Debug all the way down and you hit a hard truth: as long as an image isn't hosted by you, any "other site's image" can vanish at a moment you don't control. They change hotlink settings, swap the URL, delete the file, or shut the whole site — and your page breaks along with it.

Only two moves are actually stable.

One: re-host the image somewhere you control. Don't embed someone else's URL. Download the image, upload it to your own space or a host that allows embedding, and switch to that stable URL. Architecturally, this reclaims your page's availability from someone else's server back into your own hands — any hotlink tweak, URL restructure, or shutdown on their end otherwise lands directly as a broken image on your page, with no warning; usually a reader tells you it's down. A source you control is the only stable source. If you already have a batch of old links scattered across other domains to clean up at once, I wrote a full SOP for batch-replacing image links — script out every old URL site-wide and swap in one pass, far less painful than editing them by hand.

Two: pick a host with hotlink protection off by default. Many free hosts block embedding to save bandwidth, so posting to a forum or blog breaks. For cross-site embedding, choose a service that explicitly allows direct linking.

That's one of the principles behind lpic.cc: what you get after upload is a stable direct image URL, embedding not blocked by default, so pasting into a forum, blog, or Discord displays normally without mysteriously turning into a 403. For images you want kept private, password protection controls who can see them. Want to try it? Upload one free, paste the link into another page, and see whether it holds.

Honestly, the limits deserve a straight answer too: the free tier's images have a 30-day retention window, not permanent archival, and the service runs on ad revenue. For long-term archives or a large commercial image library, evaluate a paid professional plan or self-host with backups. A tool only earns its place when matched to the right scenario — a lesson I learned the hard way.

FAQ

Q: Why does the same image link open for me but break on another site?

Because when you "open the image directly," the Referer is empty or from an allowed source, so hotlink protection lets it through. Posted to another site, the Referer becomes that external domain, isn't on the allowlist, and gets blocked as 403. Same URL, different Referer, completely different result.

Q: Are 403 and a broken image the same thing?

No. 403 is the server explicitly refusing (status 403); a broken image is just the browser's visual for "can't draw the image." 403 causes broken images, but broken images can also come from a wrong URL, wrong Content-Type, CSP blocking the load, and more. Check the status code first to know which.

Q: Does setting Referrer-Policy: no-referrer bypass hotlink protection?

Sometimes, sometimes it's worse. If their protection is "allow empty Referer," sending none does get through. But if it's "block all empty Referers," you break everything instead. Unreliable — don't treat it as the real fix.

Q: My script (Python / Node) also gets 403 fetching an image. What now?

Same principle as the browser — your script isn't sending the right Referer. Use curl first to find which Referer the target accepts, then add the same header to your HTTP request. Note, though: bypassing someone's hotlink protection to scrape images may violate their terms of service — use your own judgment.

Q: How do I quickly tell whether a host allows cross-site embedding?

Upload a test image, grab its direct URL, and run curl -I -H "Referer: https://google.com/". Returns 200, embedding is allowed; returns 403, it has hotlink protection — don't use it for external posts. Thirty seconds to verify.

Q: Does this affect GDPR or privacy compliance at all?

Indirectly. The unsafe-url policy leaks the full referring URL cross-origin, which can expose path-level info about your users — a reason EU/GDPR-minded sites lock referrer down. The catch is that the stricter your referrer policy, the more likely you trip empty-Referer hotlink blocks. Re-hosting your own images sidesteps the whole tension.

References

#hotlink protection#403 Forbidden#Referer#Referrer-Policy#CDN#direct image link#image embedding
H

Written by

Harvey Zhang

Co-Founder & CTO

Backend engineer turned architect, offering deep technical analysis of image hosting infrastructure.