In this article
After reading, you'll understand:
- What a signed URL is and what goes inside the token
- How the signature is created and verified
- What signing stops — and what it leaves open
- How it differs from DRM, domain locks and passwords
What is a signed URL?
A signed URL is an ordinary media link with extra parameters appended: an expiry timestamp, optionally a set of constraints, and a signature computed over all of it with a secret key. The edge server recomputes that signature on every request. If it does not match, or the clock has passed the expiry, the request is refused before a single byte of video is sent.
You will also see the same idea called a tokenised URL, a pre-signed URL (the term Amazon S3 uses) or simply link signing. The mechanics are the same: authorisation is carried inside the link rather than in a session on the server. In practice the signature usually covers the manifest and its segments alike.
How signing works
A viewer asks to watch. Your backend checks entitlement — subscription, purchase, seat — and only then decides to issue a link.
An HMAC is calculated over the path, the expiry and any constraints, using a secret key that never leaves your infrastructure or the platform's.
The token and expiry ride along as query parameters. The link is valid from that moment until it lapses — usually minutes, not days.
Every request to the CDN is re-checked against the signature. Wrong key, edited path or expired window all return an error instead of video.
Because verification happens at the edge, signing costs nothing in latency and needs no round trip to your backend during playback. The check is arithmetic, not a database lookup.
What you can bind a link to
| Constraint | What it means | Trade-off |
|---|---|---|
| Expiry | The link dies at a fixed timestamp | Short windows are safer but break resumed playback if too aggressive |
| IP address | Only the requesting IP may play | Mobile viewers switching between WiFi and cellular get cut off |
| User or session ID | The token carries who it was issued to | Requires your backend to mint links per viewer |
| Path or prefix | The signature covers a specific asset or folder | A per-asset signature is stricter; a prefix is easier to operate |
Expiry plus a per-viewer identifier is the combination most teams settle on. IP binding sounds strongest and causes the most support tickets.
What signing stops — and what it does not
Signing controls distribution of the link. It says nothing about what happens to the video once playback has legitimately begun.
| Threat | Does signing stop it? | Why |
|---|---|---|
| A link pasted into a group chat | Yes, after expiry | The token lapses; late arrivals get an error |
| Hotlinking your file from another site | Yes | The signature is bound to your parameters, not theirs |
| Scraping predictable file URLs | Yes | There is no valid link without the secret key |
| Downloading during the valid window | No | The bytes are being served legitimately — only DRM makes them unusable afterwards |
| Recording the screen | No | Nothing in the link layer touches playback |
That last pair is the reason signed links and DRM are not alternatives. Signing decides who may start a stream; DRM decides whether the delivered file is worth anything once it lands.
Signed URLs versus the other controls
Guards the page. Once the player is loaded, the HLS media URL is visible in developer tools and works for anyone who copies it — unless it is signed.
Stops your embed playing on other sites, but does nothing about a direct link to the file itself.
Makes the direct link temporary and non-transferable. The gap it leaves is what happens during the valid window.
Encrypts the payload so a download taken inside that window is still unplayable. The layer below the link.
How Kinescope handles this
Kinescope signs playback links for you: expiry and per-viewer binding are configured per project, verified at our own CDN edge, and combine with DRM and domain rules rather than replacing them. Your backend keeps the entitlement decision — see DRM video hosting for how the layers stack.
Read the Kinescope docsFrequently asked questions
What is a signed URL?
A media link carrying an expiry timestamp and a cryptographic signature. The server recomputes the signature on each request and refuses anything expired or altered, so the link works only for its intended window.
How long should a signed link stay valid?
Minutes rather than hours for the manifest, with the player refreshing as needed. Long windows are convenient and are exactly what gets pasted into group chats; very short ones break resumed playback and long pauses. Most teams land between five minutes and an hour.
Does a signed URL stop people downloading the video?
No. While the link is valid the bytes are served normally, so anything that can play the stream can also save it. Signing controls access to the link; DRM controls whether a saved copy is usable.
Signed URL or DRM — which do I need?
They solve different halves. Signed links stop hotlinking, scraping and sharing after expiry; DRM makes a captured file unplayable. For paid content the sensible answer is both, with signing as the cheap outer layer.
Can I tie a link to a specific viewer?
Yes, if the token includes a user or session identifier your backend supplies. That also makes leaks attributable, since a link that surfaces publicly points back to the account it was minted for.
Should I bind links to an IP address?
Usually not. It sounds like the strongest constraint but breaks the moment a phone switches from WiFi to cellular, or a corporate network rotates its egress addresses. Expiry plus a per-viewer identifier gives most of the benefit with far fewer support tickets.
Further reading
- HMAC — Wikipedia — the signing primitive behind most token schemes.
- DRM — the layer that protects the payload rather than the link.
- Anti-piracy for video — how signing, DRM and watermarking stack.
