What is a Signed URL?
A signed URL contains cryptographic proof that an authorized party granted access to a resource or transformation. Its signature commonly covers an expiration time and request-specific path or query parameters.
How Signed URLs work
A signer builds a canonical representation of selected URL components and policy data, then appends a token that a delivery service can verify without exposing the secret. The verifier checks both the cryptographic value and constraints such as expiry before serving the object or transformation. This is delegated authorization rather than encryption: anyone holding the URL may use it while it remains valid. Signed URLs sit between an application’s access decision and a CDN, object store, or media transformation endpoint.
A client requests an asset using a URL or playback manifest. A delivery layer evaluates authorization and cache state, serves a cached response when possible, or retrieves the asset from its origin before forwarding and optionally caching it.
Delivery choices determine more than download speed. Cache keys, origin behavior, authorization, geographic routing, invalidation, and egress cost decide whether an asset is fast, current, and available to the right audience.
Key facts
- 1Changing a percent-encoding, parameter order, hostname, or path can invalidate a signature when canonicalization covers that component, even if two URLs appear equivalent to an application.
- 2CDN cache keys must be configured deliberately: including unique signature parameters can reduce cache reuse, while ignoring security-relevant parameters can expose content.
- 3Short expirations reduce the value of a leaked URL but increase sensitivity to clock skew, queued downloads, and clients that request additional byte ranges after expiry.
When Signed URLs matter
Use signed URLs to grant limited access to private media without exposing long-lived credentials. Altering a covered parameter or serving the URL after expiration should fail, so clock skew and cache behavior need consideration.
- Serving image, audio, video, and document derivatives to a geographically distributed audience.
- Protecting private assets worldwide with expiring or signed requests.
- Reducing repeated processing and origin traffic by caching deterministic results.
Working with delivery at scale
Guidance that holds across every delivery term in this glossary, not just Signed URLs.
What you gain
- Edge caching places frequently requested assets closer to viewers.
- Explicit cache and authorization rules reduce avoidable origin work.
- Multiple delivery variants let clients request an asset suited to their context.
What it costs
- Long cache lifetimes improve hit ratio but make replacement and invalidation more difficult.
- Signed access protects private media but adds key management, clock, and cache-partitioning concerns.
- More variants improve client fit while increasing storage, cache fragmentation, and operational complexity.
Answer these before production
- 1Define cache keys, cache lifetime, invalidation, and authorization behavior explicitly.
- 2Measure time to first byte, cache-hit ratio, egress, and behavior after an origin failure.
- 3Test signed and unsigned requests at the CDN edge, not only against the origin.
How Transloadit helps with Signed URLs
When Signed URLs are relevant to your workflow, you can hand the surrounding delivery work to Transloadit instead of maintaining the processing stack yourself. Transloadit connects importing, processing, storage, and delivery in one Assembly. Files can move between cloud services or be exposed through a content-delivery Robot without adding another media-processing backend.
Support for a specific codec, container, parameter, or combination can vary by Robot and processing stack. Check the linked documentation for the exact inputs and outputs available for your use case.