Direct Download Links: Share Files That Auto-Download

Direct Download Links: Share Files That Auto-Download

There is a specific kind of link that behaves exactly the way you want when you send someone a file: they click it, and the file starts downloading. No preview, no landing page to read, no "which button do I press" moment. That is a direct download link, and getting it right is mostly about one HTTP response header plus a couple of decisions on your end.

This post covers what makes a link auto-download, when you actually want that behavior, and how to fetch files programmatically with curl and wget so you can wire downloads into scripts, cron jobs, and CI pipelines.

What makes a link "auto-download"

When a browser receives a response, it decides whether to render the content inline or hand it to the download manager. That decision is driven by the Content-Disposition response header.

• Content-Disposition: inline tells the browser to display the content in the page if it can (a PDF viewer, an image, plain text).
• Content-Disposition: attachment tells the browser to save the content to disk instead of rendering it, usually with a Save dialog or a silent download to the Downloads folder.

The header can also carry the filename to use when saving:

Content-Disposition: attachment; filename="quarterly-report.pdf"

For filenames with non-ASCII characters, the spec defines a separate filename* parameter using RFC 5987 percent-encoding, and clients that understand both should prefer filename*:

Content-Disposition: attachment; filename="report.pdf"; filename*=UTF-8''r%C3%A9sum%C3%A9.pdf

The semantics of this header are specified in RFC 6266, and MDN's Content-Disposition reference is the practical companion. The key takeaway: attachment is what turns a URL into a download instead of a preview.

When you want a direct download (and when you do not)

Auto-download is the right call when the recipient's job is to get the file, not to look at it in the browser: a design bundle, a database export, a signed contract, a 4 GB video that no browser tab should try to render. It removes a step and removes ambiguity.

Inline is better when the file is meant to be read in place, like a PDF invoice you want the recipient to glance at, or a preview image. If you force attachment on everything, you make people download things they only wanted to skim.

A good sharing tool gives you both. On EasyFileUpload, a share link resolves to a delivery page by default, and you can also hand out a direct link that streams the file straight to the recipient's disk with the correct filename preserved. Because the platform is built for delivery rather than storage, those links are meant to be temporary: Free links live for 7 days and Premium links for 30, and the file is gone when the link expires. That is a feature, not a limitation. You are sending a file, not standing up permanent hosting.

Fetching a direct link with curl

curl is the workhorse for programmatic downloads. The two flags you need most often are -O (save using the filename from the URL) and -J combined with -O (save using the filename from the Content-Disposition header instead).

# Save to a filename you choose
curl -L -o report.pdf "https://easyfileupload.io/d/AbC123xyz"

# Save using the server-provided Content-Disposition filename
curl -L -O -J "https://easyfileupload.io/d/AbC123xyz"

-L follows redirects, which matters because a share URL often 302s to the actual file location. -J (--remote-header-name) tells curl to honor the Content-Disposition filename rather than guessing from the URL path. Note that -J deliberately refuses to overwrite an existing file unless you opt in, which is a safety feature worth knowing about. Both flags are documented in the curl manual.

Before scripting against an endpoint, it is worth inspecting the headers so you know what you are dealing with:

curl -sI -L "https://easyfileupload.io/d/AbC123xyz"

Look for Content-Disposition (does it download and with what name), Content-Length (how big), and Accept-Ranges: bytes (can you resume a broken transfer). If a download dies partway, resume it from the last byte you received:

curl -L -C - -o report.pdf "https://easyfileupload.io/d/AbC123xyz"

-C - (--continue-at -) tells curl to figure out the current offset of the partial file and ask the server only for the rest.

Fetching with wget

wget is the other common choice, especially on servers where it is preinstalled. The basics mirror curl:

# Download, following redirects, keeping the server's filename
wget --content-disposition "https://easyfileupload.io/d/AbC123xyz"

# Resume an interrupted download
wget -c "https://easyfileupload.io/d/AbC123xyz"

--content-disposition makes wget respect the attachment filename, and -c (--continue) resumes a partial file left by an earlier run by requesting only the missing bytes. Run it from the same directory as the original attempt so wget can find the partial file. All of this is in the GNU wget manual.

Automating with the API

Clicking links does not scale. When you need to move files as part of a build, a nightly job, or a data pipeline, the API is the right surface. EasyFileUpload exposes a public API on the Premium plan, so you can upload from a script and get back a share URL or a direct download link programmatically.

A typical automation looks like this: your CI job produces an artifact, uploads it, and posts the resulting link to your team channel. The upload half is a normal authenticated request; the download half is the same curl you already saw.

# Illustrative: upload a build artifact, capture the returned link
LINK=$(curl -sS \
  -H "Authorization: Bearer $EASYFILEUPLOAD_TOKEN" \
  -F "file=@dist/app-release.zip" \
  "https://easyfileupload.io/v1/uploads" | jq -r '.download_url')

echo "Build available at: $LINK"

Because links expire on their own, you do not accumulate a graveyard of stale artifacts and forgotten public URLs. Each run produces a fresh link that cleans itself up. Pair that with the platform's built-in extras that ship on every plan, including password protection, one-time-download links, and download analytics, and you have a delivery mechanism that is scriptable and self-cleaning.

The short version

A direct download link is just a URL that returns Content-Disposition: attachment with a sensible filename. Use it when the recipient's goal is to get the file, keep inline for things meant to be read in place, and reach for curl -L -O -J or wget --content-disposition when you want to fetch without a browser. When downloads and uploads become part of a repeatable job, move to the API and let expiring links keep your storage honest.

Ready to hand out clean, self-expiring download links? Try EasyFileUpload and share your first file in under a minute.