Widevine vs FairPlay vs PlayReady: DRM Explained for Video

Most Widevine vs FairPlay vs PlayReady comparisons stop at a platform list: Widevine on Android, FairPlay on Apple, PlayReady on Windows. That is true, and it leaves out the parts that shape a real multi-DRM build: how a license request flows, how security levels decide the resolution a device receives, and an encryption-format mismatch that once made protected video fail on Apple devices. The previous article covered whether you need DRM at all. This one assumes you do and explains what differs once you build it.

TL;DR:

• Widevine (Google) covers Chrome, Firefox, Edge, Android and most non-Apple TVs. PlayReady (Microsoft) covers Windows, Xbox and many smart TVs. FairPlay (Apple) is required for protected video on iOS and tvOS and in Safari on a Mac.
• Every system grades the device by where decryption happens, and the license server releases the HD or 4K key only to hardware-backed grades: Widevine L1, PlayReady SL3000, FairPlay on Secure Enclave hardware.
• FairPlay reads only the cbcs encryption scheme. Widevine and PlayReady started on cenc, which is why protected video could play on Android and Windows and fail on Apple devices.
• Widevine on Android reads cbcs from version 7.1 and PlayReady from client version 4.0, so the common default is now one cbcs encryption, packaged as CMAF, serving all three systems. Older PlayReady clients are the exception.
• AIOZ Stream's documentation mentions none of the three systems, rechecked on 2026-10-14.

Platform ownership and reach

Each system belongs to the platform vendor that built it, so reach follows platform share. Widevine runs in Chrome, Firefox, Edge and Samsung Internet, on Android devices, and on most non-Apple smart TVs and streaming sticks. PlayReady covers Windows, Xbox and many smart TVs. FairPlay stays inside Apple's ecosystem: per Mux, it is required for any DRM-protected video on iOS and tvOS, and Kinescope lists it as the DRM for Safari.

On a Mac, the browser picks the system. Fora Soft notes that FairPlay-licensed content can stream 4K HDR on a Mac while Widevine in Chrome on the same Mac caps at 720p. Full audience coverage still means running all three, since each one is the only option on at least one platform you want to reach.

What happens when a viewer presses play

The vocabulary differs, but the sequence is shared. At packaging time the video is encrypted with a content key, and the stream carries PSSH boxes (Protection System Specific Header) naming the DRM systems that can decrypt it. In a browser, the player finds that data through the Encrypted Media Extensions (EME) API and sends a license request to the system it picked. The license server authenticates the request and returns an encrypted license holding the content key, and the Content Decryption Module (CDM) opens it and decrypts segments as they arrive. In EME code the three systems appear as key system strings: com.widevine.alpha, com.apple.fps.1_0 and com.microsoft.playready (all per Mux).

FairPlay changes the envelope. The device sends a Server Playback Context (SPC) blob to your license server, where your Key Server Module decrypts it with your team's private key, checks its integrity and replay window, finds the requested key ID and returns a Content Key Context (CKC). On modern Apple hardware the key never leaves the Secure Enclave. A PlayReady request carries a copy of the device's client certificate, which is what the next section depends on.

Security levels gate the resolution, not just the vendor

All three systems grade a device by where decryption happens, and studios tie the resolution they permit to that grade. The license server reads the grade and decides what to release.

Widevine rows are from Kinescope, PlayReady rows from Microsoft's security level page, and the FairPlay row from Fora Soft.

PlayReady enforces the grade twice. The server can read the tier from the client certificate in the request and send different licenses to different clients. Every license also carries a MinimumSecurityLevel of 150, 2000 or 3000, and a client refuses to bind a license whose minimum is above its own level. Multi-key encryption applies the same idea to the files: renditions are encrypted with different keys, such as an SD key and a separate HD or 4K key, and the license server releases the high-resolution key only to hardware-backed devices. A weaker device plays SD and never holds the 4K key.

The historical gotcha: cenc vs cbcs

Common Encryption, standardized as ISO/IEC 23001-7, sits under all three systems. It defines four modes, and Microsoft notes that two of them, cens and cbc1, are allowed but not supported in PlayReady. The two that matter are cenc, AES in counter mode, and cbcs, AES in cipher-block-chaining mode with a 1:9 encryption pattern. FairPlay reads only cbcs. Widevine and PlayReady began with cenc: the Android ExoPlayer documentation lists Widevine cenc from Android 4.4 (API 19) and cbcs only from Android 7.1 (API 25), and Microsoft says PlayReady clients before version 4.0 supported only cenc.

That gap produced the classic multi-DRM failure. Content encrypted once with cenc played on Android and Windows and then failed on Apple devices, because FairPlay cannot read it. Teams that hit it kept two encrypted copies of every title, one per scheme, which doubled storage and packaging work.

The convergence: cbcs everywhere via CMAF

Most of that gap has closed. PlayReady clients from version 4.0 can take cbcs, and so can Xbox One units on version 1709 or later. Fora Soft calls cbcs packaging the production default for single-encode multi-DRM: one CMAF asset feeds FairPlay, Widevine and PlayReady, with HLS and DASH manifests built from the same segments. On the HLS side, fMP4 segments need protocol version 6 or higher. The result is one set of encrypted segments, two manifests and three license types. The segment structure is the one covered in video container formats.

Three limits in Microsoft's content encryption modes page keep that from being universal:

• Support is optional for PlayReady clients and signaled to the license server inside the license request. Asking for a CBC key from a client that did not signal support throws an exception.
• Before PlayReady 4.4, a license server could not issue a CBC key to a Windows client at SL2000, because Windows clients supported CBC only on SL3000 units.
• A title must not be encrypted in both CTR and CBC mode with the same key ID and key. A client acquiring both would not function, and an attacker holding both versions could decrypt more easily. If you keep both versions during a migration, give each its own key.

Offline playback and license expiry

Offline playback depends on how long licenses last. FairPlay added persistent licenses in iOS 10 (2016), with two clocks: a storage duration, the time a license stays valid before playback starts, and a playback duration, the time it stays valid after playback starts. Fora Soft's example of 30 days to start and 48 hours to finish is a rental. On Android, the ExoPlayer documentation loads an offline key set by ID and states a known limit: only one offline key set can be specified per playback, so offline playback of multi-key content works only with one particular license-server configuration. Mux adds that offline licenses need explicit setup, or a product that promises downloads breaks.

Build, buy or bolt on

Kinescope lists three routes to multi-DRM: build it in-house (license servers, FairPlay certificates, CDM updates), hire a vendor that charges per stream (it names DoveRunner, BuyDRM and castLabs), or use a platform with DRM built in. The in-house route has a lead time on the Apple side. Fora Soft reports that FairPlay deployment credentials need Apple's manual approval, with reviews running two weeks or more in 2026, and that a team holds at most two FairPlay certificates at a time.

AIOZ Stream is not in the third group today. A check of its documentation on 2026-10-14, covering the 47 pages in the docs sitemap plus the import and MCP pages, found no mention of Widevine, FairPlay, PlayReady or DRM, the same result as in the previous article. Adding DRM to an AIOZ-hosted workflow means layering a license service on top, so four questions are worth asking any provider:

• Does it encrypt once with cbcs and CMAF and serve all three systems from that, or does it keep separate encodes? The difference shows up in storage bills and in how many places a bug can hide.
• Does it expose which security tier a client negotiated, so a resolution cap is enforced on purpose instead of found during a studio audit?
• Where does the license server sit relative to viewers? License requests run before playback, so Mux flags that a server adding 500 ms or more is felt as startup delay, and recommends geographic distribution and player-side license pre-fetching.
• Was it tested on Safari for macOS and on real iOS devices? Mux notes that teams testing only in Chrome ship broken FairPlay, and that simulators behave differently from devices.

Frequently Asked Questions

Do I need to support all three DRM systems, or can I pick one?
Full audience coverage requires all three, since each is the only option on at least one platform: FairPlay on iOS and tvOS, Widevine on Android and Chrome, PlayReady on Windows and Xbox. Picking one excludes whichever platforms it does not cover.

What's the difference between Widevine L1, L2 and L3?
L1 decrypts inside a hardware Trusted Execution Environment and allows HD and 4K. L2 is a hybrid that is rare on real devices and tops out at HD. L3 is software only, and its ceiling is SD, set by license policy.

What's PlayReady's equivalent to Widevine L1?
SL3000, available from PlayReady 3.0, which runs in the processor's trusted execution environment and receives the highest-quality licenses. SL2000 is the software-DRM tier, comparable to L3.

Why did my DRM-protected video fail only on iPhone?
The likely cause is a cenc and cbcs mismatch. FairPlay reads only cbcs, and a title encrypted only with cenc plays on Android and Windows but cannot play on Apple devices.

Do I still need to encrypt my content three separate times?
Not with modern clients. Encrypting once with cbcs and packaging as CMAF serves all three systems. The exceptions are PlayReady clients older than version 4.0, and Windows clients at SL2000 before PlayReady 4.4.

Can I encrypt the same title with cenc and cbcs using the same key?
No. Microsoft says a service must not encrypt one piece of content in CTR and CBC mode with the same key ID and key, for both functional and security reasons.

Does Chrome on a Mac use FairPlay or Widevine?
Widevine. Safari uses FairPlay. Fora Soft reports that FairPlay content can reach 4K HDR on a Mac while Widevine in Chrome on the same Mac caps at 720p.

Does AIOZ Stream support Widevine, FairPlay or PlayReady?
No. None of the three appears in AIOZ Stream's documentation, rechecked on 2026-10-14.

Related Reading

• What Is DRM and Do You Need It for Video Streaming: whether a project needs DRM at all, and what AIOZ Stream offers instead today
• HLS vs WebRTC: the delivery protocol FairPlay's cbcs requirement is tied to
• Video Transcoding Basics: H.264 vs H.265 vs VP9: the encoding layer DRM's encryption wraps around
• How Video Segmentation and M3U8 Manifests Work: the segment structure CMAF packaging builds on
• Video Container Formats Explained: the fMP4 and CMAF container side of packaging
• AIOZ Stream vs Livepeer vs Theta: how AIOZ Stream's infrastructure compares more broadly, content protection aside

References

• Microsoft Learn: PlayReady security levels: SL150, SL2000, SL3000 and MinimumSecurityLevel
• Microsoft Learn: PlayReady content encryption modes: cenc and cbcs support by client version, and the CBC limits
• Android Developers: ExoPlayer DRM support: Widevine cenc and cbcs by Android version, offline key sets
• Fora Soft: FairPlay Streaming deep dive: key flow, Apple approval, persistent licenses, cbcs and CMAF
• Mux: Multi-DRM for Widevine, FairPlay and PlayReady: license lifecycle, key system strings and common mistakes
• Kinescope: Multi-DRM explained: Widevine tiers, multi-key encryption and the three routes