The link looks fine when you test it. You paste it into a new browser tab, the photograph appears and there is no obvious sign that anything is wrong.
Then the same address goes into your website, Markdown file or product page and the image disappears. A broken-image icon appears where the photograph should have been, even though opening the URL manually still seems to work.
This usually feels like a website problem at first. In many cases, however, the website and the image are both fine. The link you tested was simply doing a different job from the link the page needed.
A browser tab is happy to open an entire webpage built around an image. An HTML image field normally needs an address it can use as the image source itself. That small difference explains a surprising number of cases where an image "works for me" but breaks after publishing.
Quick answer
If an image link works when you click it but breaks after you place it on a website, first check whether you copied the image source or only a page that displays the image.
A share or preview page can look completely correct in a normal browser tab because the page itself contains the photograph. HTML, Markdown and many CMS image fields need the image response instead of the surrounding webpage.
Your own browser can also hide an access problem if you are already signed in to the hosting service. Test the link in a private window and then use it in the same type of field where it will actually be published.
If you already have the correct direct image URL and it still fails, the problem is no longer simply "wrong link copied". Continue with the deeper image URL troubleshooting checks instead of repeatedly uploading the same file.
Why did the link look correct when you tested it?
Clicking a link is a very forgiving test because the browser can show much more than an image file.
A hosting service may open a full page where the photograph sits between a header and a download button. Another link may return only the photograph. From your side, both tests seem successful because the thing you wanted to see is visible on the screen.
The difference only matters when another part of the website tries to use that URL for a particular job. An image field is not asking, "Can somebody eventually see this photograph?" It needs an address from which the browser can load the image for that part of the page.
That is why a quick click can give you false confidence even when nothing is technically broken.
Seeing the image on a page does not make that page the image source
Imagine a hosting page that looks like this:
https://example.com/photo/mountain-lake
The page may contain the photograph, its name and a download option. Sending that address to another person can be completely fine because the person is meant to open the page.
A website image field may instead need something like:
https://cdn.example.com/media/mountain-lake
The second address does not need to end in .jpg or .webp. What matters is that the receiving website can use the response as the image source it needs.
So the useful distinction is not "link with an extension vs link without an extension." It is "page built around the image vs address that can be used as the image source."
[!NOTE] Do not judge the link from its ending alone. A long CDN URL without
.jpgcan still be a valid image source, while a URL that looks likephoto.jpgcan still lead to an error page or another response.
Direct image URL vs page link
A page link is normally created for somebody to open in a browser. The hosting service can show the photograph along with whatever viewing or download controls belong on that page.
A direct image URL serves a different job because another website or tool can use it as the image source.
The distinction becomes important only when the next place expects one type and receives the other. That is why a perfectly usable share link can still be the wrong address for HTML.
If you want the full comparison between these outputs, continue with our guide on Direct URL vs Share Page URL: Which Link Should You Copy?.
| Link you copied | What normally opens | What happens on a website |
|---|---|---|
| Direct image URL | The image source | Works when the field can use that image response |
| Share page | A webpage around the image | Useful for people but may be wrong for an image source |
| Preview/viewer link | A service-specific file viewer | May open normally when clicked without acting like the image source |
| Private image link | Image or access screen | Can work for you while another visitor is blocked |
Why upload tools can make this confusing
An upload can finish successfully and still leave you with several different URLs.
One button may be meant for sharing the file with another person. Another may open a preview. Somewhere else on the result screen, the service may provide the address intended for using the image as a source.
Those outputs can look almost identical because they all begin with https:// and may all show the photograph when clicked. The labels and the next action matter more than the appearance of the address.
This is where the wrong link often gets copied. The first Copy link button looks like the obvious choice, even though the website you are working on may actually need the direct image output.
Your own browser can make the link look more public than it really is
There is another reason the link can pass your test and fail for everybody else.
Your browser may already be signed in to the service where the image is stored. A saved session or existing permission allows the photograph to appear when you open the URL, so nothing looks restricted from your side.
The live website does not carry your personal login session. A visitor on another device may therefore receive a login page or access error from the same address that seemed completely normal to you.
A private browser window is useful here because it removes much of the account context from your normal session. If the image stops working there, check the sharing permission before changing the website code.
A preview page is useful, but for a different job
A preview page is not a bad result. It is often the better link when somebody needs to view the image manually because the page can include a filename, download option or other useful context.
The problem begins only when that same address is pasted somewhere that expects the image itself. The surrounding webpage then becomes part of the response rather than something the image field can ignore.
This is why the safest habit is not to classify one output as "good" and another as "bad". Match the output to what happens next.
What HTML and Markdown are actually asking for
In HTML, the image address sits inside the src attribute:
<img
src="YOUR_IMAGE_URL"
alt="Mountain lake"
>
Markdown looks different:
The syntax changes, but the requirement is similar. Both workflows need an image source that the renderer can use, so a hosted viewing page may fail even though opening that page manually shows the photograph.
If the same image breaks in both HTML and Markdown, checking the copied URL is usually more useful than rewriting the markup again and again.
Test the link where it will actually be used
Opening the address in another tab tells you that the URL reaches something. It does not prove that the same address will work as an image source.
A better test is to copy the link into the type of field where it will finally live. If the destination is HTML, try it inside a small <img> element. If the image is for Markdown, test the actual Markdown rather than assuming that a successful browser click is enough.
Then repeat the basic check in a private browser window. This helps expose links that only appeared to work because your normal browser was already signed in.
These two tests answer different questions: one checks whether the link works for the intended use, while the other checks whether your personal session was hiding an access problem.
If the behaviour is still unclear, Link Doctor can check a supported public URL and show where it finally goes. A final HTML response is a useful clue when you expected an image, while the redirect path can explain why clicking the address looked normal even though another tool struggled with it.
Link Doctor does not make a private file public or repair a deleted source. It helps you understand what the reachable URL is doing before you decide whether the image needs another hosting workflow.
What if you definitely copied the direct image URL?
At that point, stop treating the problem as a simple direct-link vs preview-page mistake.
A correct image source can still fail because the file is private, the URL has expired or the host does not allow the way another website is trying to use it. Your own website can also introduce restrictions that have nothing to do with the upload itself.
Those cases need a different troubleshooting path because copying another version of the same URL may not change anything.
The guide on why an image URL does not work in HTML covers those deeper causes. Use that next when you have already confirmed that the address is the right kind of image URL.
A common product-image example
Suppose a seller uploads a product photograph to an image host and copies the large Share button shown after upload. The link looks fine because it opens a neat page containing the product image.
The same URL is then pasted into an e-commerce field labelled Image URL. Instead of the product photograph, the listing shows an empty image area because that field was trying to fetch the image source rather than send a customer to the hosted page.
Once the direct image output is used, the product field can request the photograph in the way it expected.
Nothing was wrong with the original photo or the upload. The wrong output was simply used for the next job.
If the photograph exists only on your device and you still need a hosted image source, Image to Link can create the online copy first. After the upload finishes, use the direct image output for a field that specifically asks for an image URL rather than copying the share page by habit.
Final thought
When an image works on your screen but disappears after publishing, do not start by assuming that the photograph itself is broken.
First look at the link you copied. A share page or preview can show the image perfectly to a person while still being the wrong address for HTML, Markdown or another image field.
Then test the same URL without relying on your normal signed-in browser. If the link is definitely the correct image source and still fails, move on to the deeper access and website checks instead of uploading the same file again.
The useful question is not simply "Does this link open?" Ask "What does this link give to the place where I am using it?" That usually gets you to the real problem much faster.
Guide review note: This guide was reviewed on August 19, 2026 against current browser rendering behaviour, direct-link outputs and image embed troubleshooting workflows.