Images & embeds
Direct Link vs Share Link: What Is the Difference?
A direct link points at the file itself, so a browser or tool receives the file bytes when it fetches the URL. A share-page URL points at an HTML page that wraps the file with extra interface, which is useful for humans but breaks most embeds.
Updated
What each link type actually returns
When something fetches a URL, what matters is the response body, not how the URL looks.
- Direct link: the server responds with the file bytes. An image URL returns image data, a PDF URL returns the PDF document. The browser then decides to render it inline or download it, depending on the Content-Type header, format support, and browser settings. A direct link does not force a download.
- Share page: the server responds with an HTML page. That page might show a preview, download button, file details, or account prompts. A person opening it in a browser sees a usable page, but an
<img>tag or script fetching it gets HTML, not an image.
This is why a link that "works when I click it" can still fail in Markdown or a forum post: your click rendered the wrapper page, while the embed expected raw file bytes.
Hypothetical examples
These are made-up URLs to show the shapes, not real files:
https://files.yoink.zip/your-upload-path/image.png (direct file URL pattern)
https://example.com/share/item123 (typical share-page URL)The extension at the end is a hint, not proof. Plenty of share pages end in .png while still serving HTML, and plenty of direct URLs have no extension at all. The test that matters is what the response actually contains, which is why you verify in a fresh tab and in the recipient app rather than trusting the URL's appearance.
Which one to use where
| Situation | Link type |
|---|---|
<img> src in HTML | Direct |
BBCode [img]URL[/img] | Direct |
Markdown image  | Direct |
| API or tool expecting file content | Direct |
| Sending a person a page with controls or context | Share page, if the host offers one |
If you paste a share-page URL into an <img> tag, the common symptom is a broken image icon, because the browser received an HTML document instead of image data. See the guide to image links not displaying for that specific failure.
Getting a direct link from Yoink
Yoink returns a public direct URL for every completed upload, starting with https://files.yoink.zip/.
- Open the Yoink uploader, select your file, and start the upload with the main upload button.
- Wait for the upload to complete.
- Copy the link from the completed result.
- Open it in a fresh browser tab. You should see the file itself (or a download, depending on type and browser), not a wrapped page.
Two things that are not public direct links:
- A copied browser blob or local file URL (
blob:...orfile:///...) only exists on your machine. Nobody else can fetch it. - A presigned upload URL is temporary PUT permission for sending a file to storage. It is not the file's address, and its expiry says nothing about how long the uploaded file stays available.
Because Yoink URLs are public, anyone with the link can access or forward the file, and there is no published permanence promise. Keep your own originals; see limits and retention for the current policy.
Quick verification checklist
- Open the URL in a fresh tab with no login. Does the raw file load?
- Paste it into the actual destination (Markdown preview, forum post editor, chat) and check the result there.
- If fidelity matters, download the file back and compare it with your original rather than trusting a thumbnail.
For format and markup details, see image embed formats and images in Markdown.