Stop someone screen recording a video link.
In a browser, you cannot. Here is what actually works.

The API browsers use for encrypted playback is Encrypted Media Extensions. Its specification opens the discussion by ruling itself out: “This specification does not define a content protection or Digital Rights Management system”, adding that it defines a common API used to discover, select and interact with such systems. That is the W3C, on its own page, fetched 9 September 2026. Mozilla’s reference page for the same API describes interfaces for controlling the playback of content subject to a digital restrictions management scheme, then documents message exchange with a decryption module and key management. It mentions no HDCP, no output protection and no capture prevention anywhere.

There is exactly one output-protection lever a web application gets, and it is a question rather than a command. MediaKeys.getStatusForPolicy() checks whether a decryption module would allow presentation of encrypted media using given keys, and MDN states that the policy restrictions currently only include a restriction on the minimum supported HDCP version. The page can ask whether the path to the display is trusted at a given HDCP version. It gets back a status, and one of the possible answers, output-restricted, is documented as meaning the connection between the source and the output is not trusted. That is information about a display. It is not a hand on a recorder.

The other side of the story is just as plain. MDN’s Screen Capture API page documents the capture direction: its main method asks the user to select a screen or a portion of a screen to capture, and returns it as a media stream. The permission model asks the person doing the recording. Nothing on that page gives a page a way to exclude its own content from what is captured. Both halves were read on 9 September 2026, and both are linked in the sources below.

DRM answers one question: is this player, on this device, authorised to turn these bytes into pictures right now. It is genuinely useful. It stops a downloaded file from being playable elsewhere, it lets a licence expire, and it gives a distributor a defensible answer about how content moved. What it does not do, on a general-purpose computer, is stand between a decoded frame and a utility that reads the framebuffer. Once the frame exists on screen for a human to watch, it exists for software to sample.

Where a blackout does happen, it comes from the operating system, not from the web page or its DRM. Apple documents exactly that behaviour and its limit: the system does not include FairPlay-encrypted video when recording, mirroring or using AirPlay, and yet, in Apple’s own wording, although it blacks out FairPlay-encrypted video content it includes FairPlay-encrypted audio content. So even the strongest documented guarantee on the most controlled consumer platform hands the recorder a black picture with your full soundtrack under it. That is a real protection. It is not the protection people think they are buying.

Apple’s UIScreen.isCaptured is documented as a Boolean indicating whether the system is actively cloning the screen to another destination, with a true value meaning the system is actively recording, mirroring or using AirPlay. Apple’s guidance on that page is to observe the property and optionally take an appropriate action, giving the example of a media app that stops playback and shows the viewer a dialog explaining the pause. The property is deprecated as of iOS, iPadOS and tvOS 27 in favour of UITraitCollection.sceneCaptureState, whose abstract describes it as representing whether a scene is currently being mirrored or recorded.

Read those two pages together and the shape is unmistakable. The current API is a reporting trait. It tells an application that a capture is under way; the application decides whether to pause, blank, warn or carry on. That is worth having, and it is a categorically different promise from making the pixels unrecordable.

Suppose every software path were closed. Suppose the frame never reached a capture utility, on any operating system, in any player. A person can still hold a phone up to the monitor and press record. The result is ugly, it is off-axis, it has a moiré pattern across the fine detail, and it is entirely good enough to spoil an embargo, reach a forum, or get quoted in a review before your release date.

Any security model that treats capture as preventable is theatre, because the last metre of the chain is a human eye and there is no API for that. Once you accept the camera in the room, the question changes usefully. You stop asking how to make a copy impossible and start asking what a copy costs the person who makes it.

The other half is not technical at all. One recipient per link, never one link for a distribution list. An NDA that names the consequence rather than gesturing at confidentiality, signed before the link is issued. An explicit no-forwarding term, so that passing the link on is itself the breach and you do not have to prove what happened after. And revocation as a scheduled task the day a review closes, verified the way you verify a backup, by opening your own link in a private window and confirming it is dead.

None of that is glamorous, and all of it outperforms any promise to block capture. Deterrence plus attribution plus a short window is a defensible programme. Prevention is a claim nobody can honour.

Frame.io is the reference point most people reach for, so it is worth reading its documentation precisely rather than from memory. Its current V4 Content Security page, fetched 9 September 2026, documents the settings available: applying DRM to video assets across the account, controls for internal playback and share links, watermark and forensic-watermark toggles, and a fallback if forensic watermarking fails. It does not state what DRM prevents, and it says nothing at all about screen-recording prevention.

The screen-recording claim appears in one place: a legacy article describing Frame.io V3, which states that DRM safeguards content against piracy or leaks and prevents screengrabs and screen recordings. Read the next part of that article and the claim narrows sharply. It scopes that prevention to Safari on macOS, Edge on Windows, Chrome on ChromeOS, and the native Frame.io apps for iPhone, iPad and Apple TV, while separately noting that DRM playback itself is supported across Chrome, Firefox, Edge and Safari including mobile browsers. Prevention on a named list, playback on a broad one. Those are two different sentences and the marketing version tends to merge them.

We are not going to tell you whether that legacy list still applies to Frame.io V4, because Frame.io does not document it and we will not guess on their behalf. What is fair to take from it is the shape of every honest claim in this category: capture restrictions live in specific clients on specific operating systems, and the moment you hand someone a plain browser link, you are back at the top of this page.

A master under Vault on uncompressed.io is native-app only. Web playback, share pages and browser downloads go dark, and the raw master never reaches a browser. Inside the macOS app the window is excluded from recordings, screenshots and Zoom or Teams shares, and it composites black. Every frame carries a visible session watermark with the viewer, the session and the time. Every frame also carries an invisible per-person forensic mark. The master is stored AES-256 encrypted at rest, links are signed and short-lived, downloads and export are off, and every open, play and capture attempt lands in a tamper-evident view log.

Now the boundary, in plain words, because blurring it is how this category loses trust. The screen-capture block is a property of the native application path. It is not a property of a browser link. A film you share as an ordinary uncompressed.io link plays in a browser, and every limit described at the top of this page applies to it in full, on our platform exactly as on any other. FairPlay DRM appears on our roadmap and has never shipped, so it protects nothing you send today.

What that buys, when the material warrants it, is a viewing your recipient must make a deliberate choice to circumvent, a copy that points back at one person if they do, and a log that tells you when to start looking. It does not buy a guarantee, and you should be suspicious of anyone selling one. The screener guide lines every control up against the leak it addresses, and the security page documents each switch on its own terms.