Direct Link

Why It Matters

Anything that embeds a file needs a direct address, and giving it the wrong kind fails in a way that is hard to diagnose. Point an img tag at a viewer page and the browser receives text/html where it expected image/png, so it draws a broken-image icon and reports nothing useful. The same mistake in a podcast feed means every player tries to play an HTML document. Direct links carry a cost as well as a use: because anything at all can fetch them, they are exactly what another site uses when it decides to hotlink your file, and every one of those fetches is billed to your traffic rather than theirs.

How It Works

The request goes to the object's own path and the host answers 200 with the bytes. Three headers decide what the browser does next: Content-Type declares the type so it knows whether to render or save, Content-Length gives the size so a progress bar is possible, and Content-Disposition, when present, can force a save instead of inline display. Range requests work against direct addresses too, which is how a video player seeks into the middle of a file without downloading everything before it. Since the response is identical for every caller, it caches cleanly at the edge — and that same property is what makes it trivially embeddable on somebody else's page.

Real-World Example

Common Mistakes

• ✕Using a viewer page address as the src of an img or video tag — the browser gets HTML instead of the file and shows nothing at all
• ✕Expecting a password to protect a direct address — there is no page in which to ask, so the bytes go to whoever holds the URL
• ✕Assuming any URL ending in .pdf must be direct — plenty of hosts serve a viewer at that address and keep the real file one click further in

Related Terms