HLS encryption: how AES-128 video encryption works
What HLS encryption protects, why it's so often bypassed through the key every player receives, what it can't do, and what to ask your video platform.
On this page 11 sections
HLS encryption protects a streamed video by encrypting its segments, usually with AES-128, and telling the player where to fetch the decryption key; the player gets the key from a server that should check who is asking, then decrypts each segment as it plays. It stops anyone who copies the segment files from watching them. But every viewer's player receives the same working key, so HLS encryption is routinely bypassed wherever that key can be captured, and its protection is only as strong as the rules around who gets it.
What HLS encryption is
HTTP Live Streaming, developed by Apple and published as RFC 8216 in 2017, delivers video as a playlist plus a series of short media segments fetched over ordinary web connections. Two kinds of encryption can apply, and they're often confused:
- Transport encryption is HTTPS. It protects playlists, segments and keys on their way across the network, and it no longer applies once they arrive.
- Content encryption is what "HLS encryption" means. The segments themselves are stored and delivered as ciphertext, so a copied segment file is useless without the key.
The playlists stay readable. They list the segments and tell the player which encryption method is in use, but they never contain the key itself, only a pointer to where the player can request it.
AES-128 vs SAMPLE-AES
| AES-128 | SAMPLE-AES | |
|---|---|---|
| What is encrypted | Each segment file as a whole, with AES in CBC mode and a 128-bit key | Only the audio and video samples inside each segment |
| Typical use | Simple protection with a key server | DRM, most notably Apple's FairPlay |
| Where the key ends up | With the player | With DRM, inside the device's protected decryption module |
The specification is being revised. The latest draft of HLS second edition, from May 2026, keeps NONE, AES-128 and SAMPLE-AES as the methods every player must support and lets players also support SAMPLE-AES-CTR and whole-segment AES-256-GCM. A longer key doesn't change where the weakness lies, though; see whether AES-128 is secure.
Why HLS encryption is so often bypassed
Nobody breaks AES to copy an HLS video. They get the key, and plain HLS encryption makes that the easy part:
- The key goes to every player. A video can't play without being decrypted, so every student's player must receive the key. Whatever the player can fetch, other software in the same logged-in session can often fetch too.
- One key for everyone. The same key typically decrypts a lecture for every viewer. Capture it once, together with the segments, and the whole lecture can be decrypted offline into a clean, shareable file.
- Stream-saving tools expect it. Tools that save streams from web pages commonly handle encrypted HLS by requesting the key the same way the player does. For them, plain HLS encryption is a routine step, not a barrier.
- Key servers that barely check. The specification recommends protecting key delivery with HTTPS plus a secure realm or session token. A key server that checks only for a login, or nothing at all, hands keys to anyone.
- Keys in the wrong places. A key file uploaded alongside the segments, a key built into an app, or a key link that lasts for days turns encryption into a formality.
- Unencrypted leftovers. An old upload, a preview clip or a quality level that was never encrypted skips the protection entirely.
What HLS encryption can't do
- It can't protect what's on the screen. Decrypted video can be screen-recorded, or filmed with a second phone.
- It can't stop shared logins. Five friends using one student's password all receive valid keys.
- It can't trace a leak. Encryption says nothing about who shared a copy.
- It can't take back a key. Once a key has been captured, it keeps decrypting everything it was used for, unless the video is encrypted again.
One key, one point of failure
The more a single key protects, the more a single capture exposes. If one key covers a whole course, one leak exposes the whole course. If keys never change, a key captured months ago still opens everything it ever protected. HLS itself allows a playlist to switch keys part-way through, which matters most for live classes, but the format can't decide how much each key should cover; that's a choice your platform makes. Our guide to key rotation explains why that choice matters.
HLS encryption vs DRM
DRM exists because of exactly these weaknesses: it delivers keys inside licences that only a protected decryption module can open, and on hardware-backed devices neither the app nor the operating system ever sees them. It has gaps of its own, from software-only devices to the analogue hole, as our comparison of DRM vs encryption and our guide to multi-DRM explain.
| Leak route | Plain HLS encryption | DRM on a hardware-backed device |
|---|---|---|
| Copying the segment files | Stops it, unless the key is captured | Stops it |
| Capturing the key during playback | Often possible | Very hard |
| Screen recording | No | Mostly: captures come out black |
| Filming the screen, shared logins | No | No |
Warning signs and questions for your platform
Signs that your encrypted lectures aren't as protected as you think: complete courses appear online soon after a batch opens, leaked copies are clean and in full quality with no recording artefacts, or someone on your team can't say where the keys are kept. Then ask your video platform:
- Is every lecture encrypted, including old uploads, previews and every quality level?
- Who can obtain a decryption key, and what is checked before one is released?
- Can software running in a student's browser or phone capture the key during playback?
- Does access stop the moment a student's enrolment ends, including in the apps?
- How much of the library would one captured key expose?
- What protects the video after decryption: recording detection, leak tracing, device limits?
Expiring links usually sit in front of keys and segments; our guide to signed URLs covers how those get bypassed too.
The legal position
Capturing keys or otherwise getting around encryption to copy a paid course can be a crime as well as a breach of terms. Circumventing an effective technological measure with the intention of infringing copyright is an offence under Section 65A of the Copyright Act, punishable with up to two years in prison and a fine; see our guide to copyright infringement punishment in India. This is general information, not legal advice. For your situation, speak to a lawyer.
Key takeaways
- HLS encryption encrypts segments; playlists stay readable and point the player to a key server.
- The cipher isn't the weak point; the shared key that every player receives is.
- Stream-saving tools routinely fetch HLS keys the way the player does, so weak key checks give everything away.
- Keys stored in the wrong place, unencrypted leftovers and keys that cover too much are common failures.
- Even perfect key handling can't stop recording, filming or shared logins.
Where VidSafe fits
VidSafe protects course videos with VidSafe proprietary encryption, screen- and camera-recording detection and account-sharing prevention, and it adds visible and invisible watermarks that are extremely hard to remove, even after heavy re-encoding, so a leaked copy can be traced back to the account it came from. See our LMS for coaching institutes.
Frequently asked questions
What is HLS encryption?
HLS encryption is content encryption built into the HTTP Live Streaming format. Each video segment is encrypted, usually with AES-128, and the playlist tells the player where to request the key. The player fetches the key from a server that should check who is asking, then decrypts and plays each segment. It protects stored and copied segments, but not a key that others can obtain.
Is HLS encrypted?
Not by default. HLS segments are ordinary files unless the video was packaged with an encryption method such as AES-128 or SAMPLE-AES. Serving HLS over HTTPS encrypts it in transit only, so anyone who can reach the segment addresses still gets playable files. Content encryption has to be switched on when the video is prepared for streaming.
What is HLS protocol?
HTTP Live Streaming (HLS) is a streaming protocol developed by Apple and published as RFC 8216 in 2017. It splits video into short segments listed in playlists, with several quality levels so players can switch as bandwidth changes. It runs over ordinary web servers and CDNs, plays natively on Apple devices, and works in other browsers through player libraries.