Can my users copy or download my videos?
An honest answer separates three different actions: fetching media files, receiving authorised playback, and recording what appears on screen. Video hosting controls can make the first two harder or refuse them; no platform can make the third impossible.
Published
The short answer
A user who is allowed to watch a video can always capture what reaches the screen, either with recording software or a camera. That physical boundary does not make protection pointless. The useful goal is to stop a copied URL or pile of media segments from becoming a simple reusable video, restrict where and for whom playback is authorised, limit how long direct access lasts, and add attribution or deterrence where appropriate.
DynTube provides several controls for those jobs, but they are not automatically enabled on every video and they are not interchangeable. HLS AES-128 is a project output choice. Origin rules govern where an embed may load. Viewer gates decide who may watch. Managed private links bound direct access. Certified DRM uses a separate packaging and licensing workflow. Watermarking and Screen Shield affect what appears during playback.
Why HLS is not one downloadable video file
An HLS stream is delivered as a playlist plus many short media segments, often with several quality renditions for an uploaded video. Segmentation by itself is not protection: standard tools understand playlists and can reassemble unencrypted segments. The security question is therefore not whether the viewer can see network requests. A browser must request media to play it. The question is whether copied media is useful without the authorization and keys that accompany legitimate playback.
What optional HLS AES-128 changes
For an eligible on-demand project configured to use HLS AES-128 before processing, the media segments are ciphertext and the player obtains a media key separately. Copying only the segments does not produce directly watchable video. The setting requires HLS output, depends on account and plan entitlement, and cannot be combined with CMAF or certified DRM on the same project.
Timing matters. The project protection choice is captured when new upload or conversion work is created. Enabling encryption later does not rewrite renditions that were already processed, so sensitive and ordinary material should be separated into projects whose defaults are set before upload.
Origin restrictions control the embed, not the person
Origin rules can restrict playback to sites you list. They are configuration, not a universal default: an empty allowlist is unrestricted, and the account can have exceptions that allow empty-origin embeds or widen encryption-key delivery. A copied embed is refused only when the effective account and project configuration says it should be.
Test this instead of assuming it. Publish a representative video on an allowed page, copy the embed to a domain that is not listed, and verify both results. Remember that an allowed origin identifies the page around the player, not the human watching it.
Viewer gates and private links solve access problems
When the viewer must be known, use a password, access code, account login or completed purchase as the gate in front of playback. DynTube does not need to replace your commerce system: your application can keep checkout and subscription billing, then grant or revoke playback access for the customer and content involved.
For direct sharing, a managed private link can have a start time, expiry, maximum number of plays or a single-play rule and can be revoked. Play-limit exhaustion is atomic, so two simultaneous requests do not both consume the final remaining play. Treat the link like a credential while it is active: whoever holds it receives whatever access the link allows.
Where DRM, watermarking and Screen Shield fit
Certified DRM is not another name for HLS AES-128. It uses CMAF packaging and authorizes a compatible player again when a license is requested. It is a separate workflow arranged for content that needs that distribution model, and it replaces the AES path for the project rather than stacking on top of it.
Watermarking works on a different layer. Where the plan and session supply an identifier, a visible watermark can connect a capture to a subscriber or user. An IP address may be shown for an anonymous viewer, but an address is weaker evidence than a known user. Screen Shield adds a moving low-opacity pattern intended to deter recording or make it less clean. Neither feature prevents capture.
A practical protection checklist
- Write down the likely failure: forwarded link, copied embed, stolen segments, shared account or screen capture.
- Choose the project and its output mode before uploading sensitive material.
- Configure the effective origin policy, including account defaults, project overrides and exceptions.
- Add a viewer gate when a person or purchase must be identified; do not use an origin rule as identity.
- Use an expiring or play-limited managed link for time-boxed direct access.
- Enable watermarking or Screen Shield only for the attribution or deterrence job they actually perform.
- Test authorised playback and every refusal path you depend on before publishing the full library.
So, can a protected video still be copied?
Yes, in the broadest sense: anything a person can see can be recorded. The more useful answer is that correctly configured encryption can stop copied HLS segments from being directly playable, origin rules can refuse a copied embed on another site, viewer gates can reject an unauthorised account, private links can expire or run out of plays, DRM can enforce a compatible licensing path, and watermarks can support attribution. Those are meaningful controls when they are configured, entitled and tested—without promising the impossible.