How-to · 27 Jun 2026 · 5 min read

Public vs private file delivery: signed URLs explained

Not every file should live at a permanent, guessable URL. Marketing images, sure. But invoices, contracts, user uploads and paid downloads usually shouldn't be one shared link away from the whole internet. That's where signed URLs come in.

Public URLs

A public file has a stable URL anyone can open. It's perfect for assets you want widely cached and distributed: logos, public images, static site assets. The upside is simplicity and cacheability; the downside is there's no access control: if someone has the link (or guesses it), they can fetch it forever.

Signed (private) URLs

A signed URL is a temporary, cryptographically-signed link to a private file. It grants access for a limited window (minutes, hours or a few days) and then expires. Your application requests a fresh signed link when a user is authorised to download, so the file is never permanently exposed.

• Use public URLs for assets meant to be shared and cached widely.
• Use signed URLs for anything sensitive, per-user, or paid.
• Keep expiry as short as the use case allows (a download usually needs minutes, not days).
• Generate the link on demand, server-side, when access is granted.

Doing it without the plumbing

On raw cloud storage, signed URLs mean wiring IAM, key management and expiry logic yourself. 1CDN makes it a single call: keep a file private and request a signed link with an expiry from 5 minutes up to 7 days, on demand, from the dashboard or the API, while public files still get a normal CDN URL. Same product, both modes.