Signed URL
A signed URL is a link that carries a cryptographic signature, and usually an expiry time, so a server can tell it was issued by you and has not been changed. For video, the server or CDN checks the signature before it returns a manifest or segment, and refuses the request if any part of the link was edited or the expiry has passed. Signed URLs let a video stay at a stable address while access to it is granted to one viewer, for a limited time.
How does a signed URL work?
Your backend holds a secret key, or the private half of a key pair. When a viewer is allowed to watch, the backend builds the link from the video path, an expiry timestamp and any other rules, then computes a signature over those parts with the key. The signature is added to the link, usually as a query parameter.
When the request reaches the CDN or origin, the server recomputes or verifies the signature using the matching key. If the path, expiry or any rule in the link was changed, the signature no longer matches and the request fails. If the signature is valid but the expiry has passed, it fails too.
The key never leaves your backend, so viewers cannot mint their own links. Because the check is plain cryptography, it runs at the edge on every request without calling back to your database, which keeps access control fast even at large audiences.
How long should a signed URL last?
A signed URL for video should outlive the viewing session but not much more. Too short, and a student pausing a long lecture or a viewer on a slow connection hits an error mid-playback, because the player keeps requesting new segments with the same signature. Too long, and a link pasted into a group chat keeps working for days.
A common pattern is a lifetime of a few hours for on-demand video, roughly the length of the video plus a margin, and a fresh link each time the viewer opens the page. Live events often use shorter lifetimes with renewal while the viewer stays signed in.
Storage services set their own limits. Google Cloud Storage, for example, allows V4 signed URLs a maximum expiration of seven days. For video, those upper limits are rarely the right choice: expiry is a policy decision about what a leaked link may cost.
Signed URLs vs. signed cookies for HLS video
HLS and DASH complicate signing, because a stream is not one request. The player fetches a manifest, then variant manifests, then hundreds of segments, each with its own address. Signing only the first manifest leaves every segment open.
There are three common answers. Signed URLs can be applied to every segment, with the manifest rewritten so each listed address carries a signature; this is precise but means the manifest is generated per viewer. Signed cookies attach one signature to the browser session, and the CDN checks the cookie on every request under a path; this keeps manifests static but depends on cookie support, which can be awkward in native apps and on TVs. Tokens passed with each request, often as a JWT on the playback URL, sit between the two, and the video platform propagates them to segment requests.
The choice is mostly about which players you support and where verification happens.
Signed URL vs. DRM
A signed URL controls who can request a video and until when. It says nothing about what happens after the bytes arrive. A viewer with a valid link can save segments with a downloader and play them later, because the content itself is not locked.
DRM controls what can be done with the bytes. Segments are encrypted, and the key arrives inside a license that only a trusted player on a trusted device can use. Saved segments cannot be played without a new license, and DRM systems can enforce rules such as output protection on external displays.
The two solve different problems and are usually layered. Signed URLs are simple, cheap to run and stop the simplest leak, a shared link. DRM is heavier, adds a license request at startup and is often required by rights holders for premium films, series and live sports. Course platforms often stop at signed access; OTT catalogs add DRM.
How does FastPix handle signed URLs?
FastPix signs playback at the playback ID. Each playback ID is public or signed. For a signed ID, your backend creates a JWT using a signing key from the FastPix Signing Keys API, sets the expiry, and passes the token with the playback URL. FastPix checks the signature and expiry before serving the stream, and a missing, altered or expired token plays nothing.
Images follow the same rule. Thumbnails, posters and storyboards inherit the playback ID's access policy, so a signed video needs a JWT for its images too, and a poster URL cannot leak a private frame. Signed streams and their images can also be served from your own custom domain.
The key stays in your backend, and expiry is set per token, so a short lesson can get a short window and a film a longer one. An open trailer should be its own clip with a public ID, not a second public ID on the full title. On live streams, the signed policy carries over to the archived recording.
On WordPress sites, including LearnDash, TutorLMS and LifterLMS, the ready-made FastPix WordPress plugin issues signed links that last from 2 minutes to 24 hours, 15 minutes by default, with DRM when needed. Elsewhere, the open-source FastPix Player or any HLS player that can pass the token plays signed streams. FastPix has no geo-blocking and no IP restriction, so territory rules are checked by your backend before it signs.
The videos behind signed URLs bill on usage: encoding per source minute, free on Standard up to 4K, storage per rendition-minute and streaming per minute watched. New accounts start with $25 of credit.
By the numbers
- Google Cloud Storage V4 signed URLs have a maximum expiration of 604,800 seconds (7 days). (Google Cloud Storage: Signed URLs)
