If you want to protect premium videos in a web browser, you do not necessarily need to build a native video app.
A browser-based Video DRM solution can protect encrypted video while allowing users to watch it through Chrome, Safari, Edge, and other supported browsers. The basic idea is to encrypt the video, store the encrypted video on your server or CDN, and give the browser a DRM license only after the user passes your access rules.
For a multi-platform solution, three DRM technologies are especially important:
- Google Widevine for Chrome, Android, and many other platforms
- Apple FairPlay Streaming for Safari and Apple platforms
- Microsoft PlayReady for supported Windows and other devices
These technologies use different DRM systems, but they can be combined into one video delivery architecture.
This article explains how to build that architecture and how to combine DRM, authentication, license control, watermarks, and screen protection.
1. What a Browser-Based Video DRM Solution Should Do
A useful Video DRM system should do more than simply encrypt an MP4 file.
A complete solution normally needs to handle:
- Video encryption
- Video packaging
- Secure video delivery
- User authentication
- DRM license requests
- License expiration
- Access control
- Device restrictions
- Domain restrictions
- Dynamic watermarks
- Screen capture protection
- Playback logs
- License revocation
- CDN delivery
- Browser compatibility
The basic architecture looks like this:
Your Website
|
v
User Login System
|
v
Access Control
|
+---------+---------+
| |
v v
Video Player DRM License Server
| |
v |
Encrypted Video <---------+
|
+----+----+----+
| | |
v v v
Widevine FairPlay PlayReady
Chrome Safari Edge/Windows
Android Apple Supported devicesThe important point is that the browser does not simply download a normal MP4 file.
The video is encrypted, and the browser’s DRM system obtains permission to decrypt and play it.
2. Do Not Protect the Original MP4 Directly
One common mistake is to upload an ordinary MP4 file to a public URL and then try to hide the URL with JavaScript.
That is not real DRM.
If the browser can download the original MP4 file, a user can potentially copy it.
A better architecture is:
Original Video
|
v
Encoding
|
v
DRM Packaging
|
v
Encrypted HLS / DASH
|
v
Private Storage / CDN
|
v
Browser Video PlayerThe original video should remain on your private storage.
Users receive encrypted media segments rather than the original unprotected video.
For PlayReady, Microsoft describes the same basic concept: content is encrypted and associated with DRM information before being delivered to the client. PlayReady also supports Common Encryption, which is useful when several DRM systems need to protect the same media.
3. Use HLS or MPEG-DASH for Video Delivery
For a modern browser-based DRM system, you normally want adaptive streaming rather than a single MP4 download.
Two important formats are:
| Streaming format | Common use |
|---|---|
| HLS | Apple devices, Safari, many other platforms |
| MPEG-DASH | Chrome, Edge, Android and other platforms |
You can encode one source video into several qualities:
1080p
720p
480p
360pThe player can then select the appropriate quality according to network speed and device capability.
For example:
movie.m3u8
|
+-- 1080p segments
+-- 720p segments
+-- 480p segments
+-- 360p segmentsThe actual media segments are encrypted.
The browser needs an appropriate DRM license before it can decrypt and play them.
4. Widevine for Chrome and Android
Widevine is one of the most important DRM technologies for browser-based video.
It is widely used with Chrome and Android and works through browser DRM mechanisms such as Encrypted Media Extensions.
A typical Widevine workflow is:
User opens protected video
|
v
Chrome detects Widevine content
|
v
Player requests Widevine license
|
v
Your License Server checks user
|
v
License is returned
|
v
Browser decrypts video
|
v
Video playsYour license server can check things such as:
- Is the user logged in?
- Does the user own the video?
- Is the subscription active?
- Has the video expired?
- Is this device allowed?
- Is the IP address allowed?
- Has the maximum device count been reached?
Only after these checks should the license be issued.
This is much more useful than simply protecting the video URL.
5. FairPlay for Safari and Apple Devices
Apple uses FairPlay Streaming for protected HLS content.
Apple describes FairPlay Streaming as technology for securely delivering content keys and protecting HLS media on Apple platforms, including iOS, tvOS, and Safari on macOS.
A simplified architecture looks like this:
Safari
|
v
Encrypted HLS
|
v
FairPlay DRM
|
v
Your License / Key Server
|
v
Access Check
|
v
Content Key
|
v
Protected PlaybackFairPlay is particularly important if your customers use:
- iPhone
- iPad
- Mac
- Safari
- Apple TV
A browser-based solution therefore should not assume that Widevine alone is enough.
6. PlayReady for Windows and Other Supported Platforms
PlayReady is Microsoft’s DRM technology.
It can be used in web browsers through the Encrypted Media Extensions interface, and Microsoft documents PlayReady support for web applications using modern HTML5 and JavaScript.
A PlayReady workflow is similar:
Browser
|
v
Encrypted Video
|
v
PlayReady Client
|
v
License Request
|
v
PlayReady License Server
|
v
License + Policy
|
v
Video PlaybackPlayReady licenses can contain rights and restrictions such as expiration and output limitations.
Microsoft also documents a PlayReady License Server that receives license requests and issues licenses to clients.
7. Use One Video with Multiple DRM Systems
You do not need three different versions of the video for Widevine, FairPlay, and PlayReady.
A better architecture is to use a common encrypted media workflow and provide the appropriate DRM information for each platform.
For example:
Master Video
|
v
Video Encoder
|
v
DRM Packager
|
+----------+----------+
| | |
v v v
Widevine FairPlay PlayReady
| | |
+----------+----------+
|
v
Encrypted Video
|
v
CDNThis gives you one central video platform while supporting multiple DRM systems.
PlayReady documentation specifically describes Common Encryption and the ability for encrypted content to contain multiple DRM headers.
8. Build One License Service Behind the Three DRM Systems
You should not necessarily build three completely independent access-control systems.
Instead, create one central authorization service.
For example:
User
|
v
Authentication
|
v
Access Control
|
+--------+--------+
| | |
v v v
Widevine FairPlay PlayReady
License License License
Server Server ServerYour application decides whether the user can watch the video.
The DRM-specific license service then generates the appropriate license.
For example:
User ID: 12345
Video ID: 67890
Device: Chrome / Windows
Subscription: Active
Expiration: 2026-12-31
Allowed: YESThe authorization layer can then allow the DRM license request.
This separation is important.
Your business rules should not be mixed into the video player.
9. Add Login and Access Control Before DRM
DRM should be one layer of your security system, not the entire system.
For example:
Login
|
v
User Authentication
|
v
Video Permission
|
v
Device / IP Check
|
v
DRM License
|
v
Video PlayYou can support different rules for different customers.
For example:
| Rule | Example |
|---|---|
| User | customer@example.com |
| Video | Training Course 2026 |
| Expiration | 30 days |
| Devices | 2 |
| Country | Portugal |
| IP | Company network |
| Download | Disabled |
| Screen capture | Protected |
| Watermark | User email |
This is especially useful for paid courses, private training, company videos, medical training, financial reports, and other high-value content.
10. Add Dynamic Watermarks
DRM makes it much harder to obtain the usable video stream directly, but you should still assume that someone may point a camera at the screen.
This is why dynamic watermarking is useful.
For example:
-----------------------------------------
| |
| PROTECTED VIDEO |
| |
| frank@example.com |
| |
| 28 Sep 2026 10:35 |
| |
-----------------------------------------The watermark can include:
- User email
- User ID
- Company name
- IP address
- Date
- Time
- Session ID
The watermark should move or change position periodically if your application supports this.
This does not mathematically prevent recording, but it can make unauthorized redistribution easier to trace.
11. Add Screen Protection
Screen recording is a separate problem from DRM.
A DRM system protects the content path and controls playback. It does not mean that every operating system will allow a website to completely control every possible screen capture method.
Therefore, a practical system should combine:
DRM + Dynamic Watermark + Screen Protection + Access Control
For example:
Video Security
|
+----------+----------+
| | |
DRM Watermark Screen
Protection
| | |
+----------+----------+
|
Protected
PlaybackFor browser playback, screen protection can include browser and platform capabilities where available, visual screen shielding, watermarking, and other controls.
For stronger system-level screen capture controls, a native application can provide additional platform-specific controls.
12. Browser First, Native App Optional
One of the biggest advantages of a browser-based DRM system is that customers do not need to install an application.
This is important for:
- Online courses
- Paid videos
- Training companies
- Business reports
- Medical training
- Private company videos
- Customer portals
- VDR systems
- M&A data rooms
- Short-term video access
A typical customer experience can be:
Receive Link
|
v
Open Browser
|
v
Login
|
v
Watch Protected VideoThere is no requirement to download a special player.
For customers who require stronger device-level controls, you can later provide an optional native application.
This creates a useful hybrid model:
Video DRM Platform
|
+----------+----------+
| |
v v
Web Browser Native App
| |
Easy Access Stronger Controls13. What the Complete Architecture Looks Like
A practical production architecture could look like this:
User
|
v
Your Website
|
v
Authentication API
|
v
Access Control
|
+-------------+-------------+
| | |
v v v
Widevine FairPlay PlayReady
License License License
Server Server Server
| | |
+-------------+-------------+
|
v
Encrypted Video
|
v
CDN
|
v
Browser Player
|
+-------------+-------------+
| |
v v
Dynamic Watermark Screen ProtectionBehind this system, you can have:
User Database
Video Database
License Database
Device Database
Access Logs
Payment System
Key Management
DRM Packaging
CDNThis gives you a complete video security platform rather than simply a DRM player.
14. How to Control Video Expiration
One useful feature of a DRM system is time-based access.
Suppose a customer purchases a video for 30 days.
Your server can create a license with an expiration time.
For example:
Purchase:
2026-09-28
Access expires:
2026-10-28After October 28, your license server stops issuing a valid license.
The encrypted video can remain on your CDN.
The important part is that access to the decryption key is controlled by the license system.
This is one of the major differences between DRM and simply hiding a video URL.
15. How to Revoke Access
You may also want to revoke a user’s access before the normal expiration date.
For example:
Customer purchases video
|
v
Customer shares account
|
v
Admin detects abuse
|
v
Disable account
|
v
New DRM licenses deniedYour central authorization server can reject future license requests.
This is especially useful for:
- Employee training
- Corporate customers
- Subscription services
- Paid reports
- Private videos
- VDR systems
The DRM layer handles protected playback, while your application controls who is allowed to obtain a license.
16. Device Limits
Another useful feature is limiting the number of devices.
For example:
Account
|
+-- Windows PC
|
+-- Android phone
|
+-- iPadYou could allow a maximum of three registered devices.
When a fourth device requests access:
Device #4
|
v
Device Limit Check
|
v
Limit Reached
|
v
License DeniedThis helps reduce account sharing.
17. IP and Country Restrictions
For business customers, you may also want to restrict access based on network or geographic rules.
For example:
Allowed Countries:
Portugal
Spain
France
Blocked:
Other countriesOr:
Allowed IP:
203.0.113.0/24These rules should be implemented in your authorization layer rather than relying only on the DRM technology.
18. Do You Need a Third-Party Multi-DRM Provider?
There are two main approaches.
Option 1: Use a Multi-DRM Service
A third-party provider can handle much of the DRM infrastructure.
Advantages:
- Faster deployment
- Less DRM server development
- Less operational work
- Easier scaling
Disadvantages:
- Ongoing service costs
- Vendor dependency
- Less control over the DRM infrastructure
- Additional cost as video usage increases
Option 2: Build More of the DRM Infrastructure Yourself
You can build your own application, packaging pipeline, authorization system, and appropriate license-server components.
Advantages:
- More control
- Lower dependency on one vendor
- Easier integration with your existing system
- Potentially lower recurring service costs at scale
Disadvantages:
- More development work
- More security responsibility
- More testing
- More maintenance
- DRM licensing and platform requirements still apply
“No third-party service fee” does not mean “zero cost.”
You still need servers, bandwidth, storage, video encoding, packaging, security work, monitoring, and maintenance.
For example, Microsoft documents licensing requirements for companies developing or operating certain PlayReady products and services, while content providers using third-party PlayReady clients and servers have different requirements.
19. A Practical Development Plan
You do not need to build everything at once.
A better approach is to build the system in stages.
Stage 1: Browser Video Player
Start with:
- HTML5 video
- HLS/DASH
- Login
- Video database
- CDN
- Basic access control
Get normal playback working first.
Stage 2: Video Encryption
Add:
- Encoding
- Encryption
- DRM packaging
- Private storage
- Signed URLs
At this stage, users should no longer receive the original MP4.
Stage 3: Widevine
Add Widevine support for the main Chrome and Android use cases.
Test:
- Chrome on Windows
- Chrome on macOS
- Android Chrome
- Different video resolutions
- License expiration
- License denial
Stage 4: FairPlay
Add FairPlay for:
- Safari
- iPhone
- iPad
- macOS
- Apple TV where applicable
Apple’s FairPlay Streaming documentation covers secure key exchange and protection of HLS content on Apple platforms.
Stage 5: PlayReady
Add PlayReady where your target devices and customers require it.
Test:
- Edge
- Windows
- Supported browsers and devices
- License policies
- Expiration
- Output restrictions
Stage 6: Security Features
Then add:
- Dynamic watermark
- Device limits
- IP restrictions
- Country restrictions
- Session control
- Access logs
- License revocation
- Screen protection
This development order keeps the project much easier to manage.
20. VeryPDF DRM Protector as the Higher-Level Solution
If you do not want to build every part of this infrastructure yourself, a higher-level product such as VeryPDF DRM Protector can be used as the starting point for a protected video delivery system.
The idea is to provide customers with a browser-based protected viewing experience instead of asking every customer to install a special application.
A typical workflow is:
Upload Video
|
v
Protect Video
|
v
Configure Access Rules
|
v
Create Protected Video Link
|
v
Send Link to Customer
|
v
Customer Opens Browser
|
v
Login
|
v
Protected PlaybackThe platform can combine DRM with other controls such as:
- User authentication
- Expiration
- Dynamic watermark
- Screen protection
- Access control
- Device control
- Playback statistics
- Protected sharing
This approach is especially useful when your main goal is not to become a DRM technology company, but to deliver protected videos to real customers.
21. Browser DRM vs Native App
| Feature | Browser DRM | Native App |
|---|---|---|
| No installation | Yes | No |
| Easy customer access | Yes | Less convenient |
| Chrome support | Yes | Yes |
| Safari support | Yes | Yes |
| Android | Yes | Yes |
| iPhone/iPad | Yes | Yes |
| System-level controls | Limited by platform/browser | Stronger |
| Screen capture controls | Limited | Stronger |
| Deployment | Easier | More difficult |
| Updates | Server-side | App updates may be required |
| Good for external customers | Yes | Depends |
| Good for high-security environments | Yes, with additional controls | Often useful |
For many commercial video services, browser-first is a practical starting point.
A native app can be added later for customers who need stronger platform-specific controls.
22. What You Should Not Promise Customers
A Video DRM system should not promise that nobody can ever record a video.
There is always a fundamental limitation:
If a person can see the video, another device can potentially record the screen.
Instead of promising impossible protection, a better security strategy is to combine multiple layers:
Encryption
+
DRM
+
Authentication
+
License Control
+
Device Restrictions
+
Dynamic Watermark
+
Screen Protection
+
Access LogsThis makes unauthorized copying much harder and gives you better control over how protected content is used.
23. Recommended Browser-Based DRM Architecture
For a new system, a practical architecture is:
| Component | Recommended role |
|---|---|
| Video format | HLS + DASH where appropriate |
| Encryption | Common Encryption where supported |
| Android/Chrome DRM | Widevine |
| Apple/Safari DRM | FairPlay |
| Windows/other supported DRM | PlayReady |
| Player | HTML5 + EME-compatible player |
| Authentication | Your own user system |
| Authorization | Your own access-control API |
| License service | DRM-specific license services |
| Storage | Private object storage |
| Delivery | CDN |
| Watermark | Dynamic user/session watermark |
| Screen protection | Browser/platform controls + visual protection |
| Logging | Playback and license logs |
| Access expiration | Server-side + DRM license policy |
| Revocation | License authorization checks |
24. Final Architecture
The final system can be summarized like this:
CUSTOMER
|
v
Browser / Player
|
v
Login / Session
|
v
Access Control
|
+--------------+--------------+
| | |
v v v
Widevine FairPlay PlayReady
| | |
+--------------+--------------+
|
v
License Service
|
v
Encrypted Video
|
v
CDN
|
v
Protected Playback
|
+-----------+-----------+
| |
v v
Dynamic Watermark Screen ProtectionThis architecture gives you a browser-based Video DRM solution that can support multiple platforms without forcing every customer to install a native application.
The most important design principle is to separate video encryption, DRM licensing, user authorization, and application-level security controls.
Widevine, FairPlay, and PlayReady handle the DRM side. Your application controls the business rules. Dynamic watermarking and screen protection add another layer of protection around the actual viewing experience.
For companies that want to build a commercial protected-video service, this is a much more practical direction than simply trying to hide MP4 URLs or block the browser’s download button.
Frequently Asked Questions
1. Can I build a Video DRM system that works in a web browser?
Yes. Modern browsers can use DRM through browser media APIs such as Encrypted Media Extensions, with the actual DRM technology depending on the platform.
2. Do I need a native application?
No. A browser-based DRM solution can provide protected playback without requiring customers to install a native application.
3. What is Widevine used for?
Widevine is commonly used for protected playback on Chrome, Android, and other supported platforms.
4. What is FairPlay used for?
FairPlay Streaming is Apple’s DRM technology for protected HLS content on Apple platforms, including Safari and iOS-related environments.
5. What is PlayReady used for?
PlayReady is Microsoft’s content protection technology. It can be used for supported Windows devices and browsers and provides license policies such as expiration and output restrictions.
6. Can one video support Widevine, FairPlay, and PlayReady?
Yes. A multi-DRM architecture can package encrypted media with the information required by different DRM systems. Common Encryption is an important part of this architecture.
7. Can I use DRM without a third-party Multi-DRM platform?
It is possible to build more of the infrastructure yourself, but this requires DRM licensing/agreements where applicable, license servers, packaging, key management, security engineering, and ongoing maintenance.
8. Does DRM completely prevent screen recording?
No DRM system should be described as an absolute guarantee against every form of recording. Platform-level protections can reduce some capture methods, while watermarking can help identify the source of unauthorized recordings.
9. Can I prevent users from sharing their accounts?
You can reduce account sharing by using device limits, concurrent-session limits, IP controls, geographic restrictions, and other access policies.
10. Can a DRM license expire?
Yes. DRM license policies can include expiration and other usage restrictions. PlayReady, for example, supports license policies and expiration conditions.
11. Can I revoke access after a customer has received the video?
You can control future license issuance from your authorization and license infrastructure. The exact behavior of already-issued licenses depends on the DRM system and license policy.
12. Can I use a CDN with DRM?
Yes. A common architecture is to keep encrypted video on private storage or a CDN while keeping license issuance behind your application and DRM license services.
13. Can I add a dynamic watermark?
Yes. A dynamic watermark can display information such as the user’s email address, company name, user ID, date, time, or session information.
14. Is browser-based DRM better than a native application?
They solve different problems. Browser DRM is easier for customers because there is no application installation. Native applications can provide additional platform-specific controls. A hybrid system can support both.
15. What is the simplest way to start?
Start with browser playback, authentication, encrypted streaming, and one DRM system. Then add FairPlay and PlayReady as your customer and platform requirements grow.
16. Can VeryPDF DRM Protector provide a browser-based protected video solution?
Yes. VeryPDF DRM Protector is designed to provide protected video access through an online/browser-based workflow, with additional controls such as watermarking and screen protection.
17. Should I build my own DRM system or use an existing solution?
If DRM itself is not your core business, using an existing solution can reduce development and maintenance work. If you have large-scale requirements and a dedicated security engineering team, building more of the infrastructure yourself may provide greater control.
18. What is the most important part of a Video DRM system?
The most important part is not a single DRM technology. A strong system combines encrypted media, license control, authentication, authorization, secure key handling, access policies, and monitoring.
A browser-based DRM system should be designed as a complete security platform rather than just a protected video player.