You upload an image and the service gives you more than one link. One says Direct URL. Another may say Share, View or simply Copy link.
Both links can appear to work when you click them. The image opens in your browser either way, so it is easy to assume that they are interchangeable. The difference usually becomes obvious only after you paste the wrong one into HTML, Markdown or another field that expects the image itself.
A direct URL is meant for places that need the file response. A share page URL opens a normal webpage built around the file so a person can view it with whatever title, preview or controls that page provides.
Neither one is better in every situation. The correct link depends on what should happen after you paste or send it.
Quick answer
Copy the direct URL when a website, CMS field, Markdown block or another application needs to load the image itself.
Copy the share page URL when you are sending the file to a person and want them to open a normal webpage around it.
A useful way to remember the difference is this: the direct URL is mainly for the next system; the share page is mainly for the next person.
The URL does not need to end in .jpg, .png or another image extension to be direct. What matters is what the final request actually returns.
What are you actually trying to do with the link?
The easiest way to choose is to ignore the names for a moment and think about what happens next.
Maybe you are filling an image field in a website builder. The field is not trying to send somebody to another webpage. It needs an address from which it can load the image.
Another time, you may simply want to send a client a photograph in WhatsApp or email. In that case, a share page can be more useful because the person gets a normal browser page instead of being dropped directly onto the image file.
The same upload can therefore need different links for different jobs.
What is the real difference between a direct URL and a share page?
A direct URL eventually gives the browser or application the file response it asked for.
For example, an image URL may return the image data needed by:
<img
src="https://cdn.example.com/images/mountain-lake"
alt="Mountain lake"
>
Notice that this URL does not even end in .jpg. That is fine. A direct image URL does not need a visible file extension as long as the response is suitable for the image being requested.
A share page URL works differently:
https://example.com/photo/mountain-lake
Opening that address may show the same photograph, but it can also include the image title, a download button, branding and other page elements around it.
The photograph may look identical on your screen in both cases. What changes is what the URL itself is returning.
| Link you copied | What normally opens | Best fit |
|---|---|---|
| Direct image URL | The image response | HTML, Markdown, CMS fields and supported apps |
| Share page URL | A webpage built around the image | Sending the image to another person |
| Preview/viewer URL | A service-specific viewer | Human viewing inside that service |
| Download URL | The file with download behaviour | Buttons or actions where saving is the goal |
The important thing is that none of these links is automatically "wrong". A share page becomes the wrong choice only when the place receiving it expects the image itself.
A direct URL does not always mean there are no redirects
Some services send the request through another address before the actual file is returned. That does not automatically turn the link into a share page.
What matters is where the request finally ends. If the browser follows a redirect and eventually receives the file response, the link may still work as a direct source in that workflow (as seen with Dropbox direct-link behaviour).
This is also why testing only by clicking the link can be misleading. Browsers follow many redirects quietly, while another importer or application may handle the same URL differently.
Why the share link is so easy to copy by mistake
The share-page URL is often the most obvious link on the screen.
A large Copy link or Share button naturally looks like the thing you are supposed to use after uploading. The direct URL may be sitting somewhere else under a label such as Direct link, File URL or Copy image address.
Nothing looks wrong during the first test because clicking the share link still shows the image. The mistake appears later when another tool treats that URL as an image source and receives the surrounding webpage instead.
That is why the button name matters less than what the destination field is asking for.
Why a share page can fail inside HTML or Markdown
Imagine pasting a share page into:
<img src="YOUR_LINK_HERE" alt="Mountain lake">
The browser is trying to load an image for that element. If the URL gives it a normal HTML webpage instead, the result is not the image response that the element was expecting.
From your side, this can look confusing because clicking the exact same link works perfectly. You see the photograph in a browser tab and wonder why HTML refuses to show it.
The difference is that your browser tab is happy to display the whole webpage. The image element is asking for the image source.
Markdown creates the same basic situation:
The renderer needs an image source there too, not a page that happens to contain the photograph.
If you already have what looks like the correct image URL and it still refuses to load, continue with why an image URL does not work in HTML. That guide covers permissions, expired links, hotlinking and the other problems that can happen after you have copied the correct type of URL.
Why the direct URL is not always the nicer link to send
A direct URL may be technically correct and still give the recipient a poor sharing experience.
Suppose you send a client the direct image address. They tap it and see only the photograph against the browser background. That may be completely fine if they only need the image.
A share page can be more useful when the recipient also needs a filename, description, download option or another piece of context around the file. This is especially helpful when several similar files are being reviewed and the page itself helps explain what the person is looking at.
So the direct URL should not be treated as the "better" link. It is simply the better link when the next step needs the file response.
One image can need both links on the same day
Imagine an agency has uploaded the final banner for a client's campaign:
- The developer needs the banner inside the website, so the CMS image field gets the direct URL.
- A few minutes later, the account manager sends the same banner to the client for approval. The share page is more useful there because the client is opening the file as a person rather than asking another system to fetch it.
The image has not changed. The correct URL changed because the next action changed.
How can you tell which link you copied?
Start by opening the URL in a private browser window. If you see a full page with navigation, branding or file controls around the image, you are probably looking at a share or viewer page.
Seeing only the image is a good sign, but it is not the only test. Some file URLs pass through redirects, and your normal browser may also have permissions that hide an access problem.
The most reliable test is to use the link where you actually need it. If the address is meant for HTML, place it inside a small <img> example. If it is meant for Markdown, test it inside Markdown rather than deciding from a browser click alone.
When the result is still unclear, check what the URL finally returns instead of trying different links at random. For an unfamiliar public URL, Link Doctor can also help by following redirects and showing the final content type. If the address eventually returns HTML where you expected an image, you know you are still dealing with a webpage rather than the media response you need.
Your own browser can make a bad link look fine
Your normal browser is not always a neutral test.
You may already be signed in to the hosting service or have a permission cookie saved from the upload session. That can make a restricted image appear perfectly normal for you while another visitor receives a login page or access error.
A private browser window removes much of that existing session and gives you a better idea of what somebody else may see.
If the image works privately but still fails only inside the website, the problem is probably somewhere else in the delivery or page setup. That is the point where the dedicated image troubleshooting guide becomes more useful than changing the URL again.
Direct or share is different from public or private
Direct URL and share page describe what kind of destination the link provides.
Public and private describe who is allowed to get through.
Those decisions can exist together. A share page can still require private access, while a direct media URL can be public because the file was intentionally created for broad embedding.
If the main question is whether anybody with the link should be allowed to open the file, continue with our Public Link vs Private Link guide. That is a different decision from choosing between the direct URL and the share page.
Where does the download URL fit?
A download URL is another output you may see after an upload.
Its purpose is usually clearer: the next action should be saving the file rather than opening a presentation page around it.
For example, a website button labelled Download brochure should normally use the output intended for downloading. Sending the same person a share page may be better when you first want them to see information around the brochure.
Again, the right link follows the next action.
Which Media2URL link should you copy?
After an upload, do not copy a link simply because it is the first one on the screen:
- Use the direct URL when another supported website or application needs the media itself.
- Use the share page when you want somebody to open a normal browser page around that file.
- Use the available download output when saving the file is the intended action.
If you only have the image on your device and still need to create these hosted outputs, start with Image to Link rather than trying to turn a local file path into a web address.
Once you already have a working direct image URL, needing a smaller image or a different website crop is a separate problem. Supported Media2URL images can use URL transformations for another size or eligible WebP/AVIF output without requiring another manual upload.
Final thought
The easiest way to stop mixing these links up is to think about who or what receives the URL next.
If another website, editor or application needs to load the media, start with the direct URL. If a person needs a normal page where the file can be viewed with some context around it, the share page usually fits better.
Do not judge the link only by whether clicking it shows the image. A share page can display the photograph perfectly and still be the wrong source for HTML.
Once you start choosing the link based on the next action, the difference becomes much easier to remember.
Guide review note: This guide was reviewed on August 19, 2026 against current HTML standards, browser media rendering behaviours and link-management workflows.