Most WordPress sites protect paid video three ways at once. A membership plugin decides who may load the lesson page, a player plugin puts the video behind a nicer interface, and a script turns off right-click. All three act on the page and none of them acts on the file, so the file URL still sits in the page source on every load that gets through.
That URL is most of the attack surface, and it survives every page-level control stacked in front of it. Protection is really five jobs rather than one: keeping a non-member off the page, stopping a copied URL working later, and stopping a paying viewer keeping a copy. The other two are stopping the video playing on someone else's site, and knowing whose account leaked it. Four tools exist for the five jobs, and none covers more than two.
TL;DR
Page gating stops a non-member reaching the lesson and nothing else. Signed playback stops a copied URL working later, never the session holder saving the file. DRM is the only thing that stops the file grab and the stream ripper. It stops neither a phone pointed at the screen nor, on some platforms, a screen recorder. Watermarking prevents nothing; it names the leaker afterwards. On token lifetime: 15 minutes is a sane default, 2 minutes breaks a paused learner, 24 hours is an open URL. Protecting a video removes it from video search, so protect what is sold and leave marketing video public.
What each protection mechanism actually stops
Attacks run down the rows and the mechanisms run across the columns. Find your own threat on the left, then read across to see what answers it.
| Attack | Page gating | Signed playback | Domain lock | DRM | Watermarking |
|---|---|---|---|---|---|
| Non-member opens the lesson page | Stops | Nothing | Nothing | Nothing | Nothing |
| File URL copied from page source, shared later | Nothing | Stops after expiry | Slows | Stops | Nothing |
| Video embedded on another site | Nothing | Slows | Stops | Stops | Nothing |
| Paying member saves the file from the network tab | Nothing | Nothing | Nothing | Stops | Nothing |
| Stream ripped with a download tool | Nothing | Slows | Slows | Stops | Nothing |
| Screen recording software | Nothing | Nothing | Nothing | Varies by platform | Identifies the source |
| Phone camera pointed at the screen | Nothing | Nothing | Nothing | Nothing | Identifies the source |
| One login shared between ten people | Partly | Nothing | Nothing | Nothing | Identifies the source |
Three things stand out. Page gating and signed playback solve different problems, so a membership plugin on its own leaves the file open.
Watermarking never appears in the "stops" column, and that is not an oversight. A watermark cannot stop anything, by design. It is a marker burned into the picture, so you can trace a copy that is already out there back to an account. It answers "who leaked this" weeks later, on content the leaker still has. Useful for an investigation, useless as a control.
The bottom two rows have almost no defences, which is the honest answer to "can I stop people copying my course". You can raise the cost of copying, but you cannot reach a phone held up to a monitor.
Why a membership plugin does not protect the video
A membership plugin decides who can load a page. That is useful, and it is a different job from deciding who can load a video.
If the player points at a file URL, that URL is in the markup. Anyone who views source on one allowed page load has a link that works for anyone, from anywhere, for as long as the file exists. No membership setting closes that, because the plugin never saw the media request.
Right-click blocking fails for the same reason, and it fails harder. It runs in the viewer's browser, so turning off JavaScript or opening devtools ends it in seconds. It is the only control here that stops nobody, and the one person it reliably annoys is a paying member. FastPix ships nothing of the kind, deliberately. Hotlinking follows the same logic, covered in understanding CDN leeching and stream protection.
How signed playback works on WordPress
Signed playback swaps the permanent file URL for a short-lived pass, created while the page renders. First the server checks whether this visitor is allowed to read this post. Only then does it hand out a token, which the player trades for the stream.
Three details decide whether that holds up, and the FastPix WordPress plugin settles all three at render time. One RS256 signature covers the stream, the thumbnail and the spritesheet together, so poster images and hover-scrub previews keep working. When a protected video plays but looks wrong in a listing, a signature that missed the thumbnail is usually why.
The token is also built per render and never written into post content, so it cannot leak through revisions, the REST API or a feed. And it is scoped to the post it sits in, so the video refuses to play on a page the visitor may not read.
That last one is the difference between protecting a video and protecting a page. The framework-agnostic version of the model is in how to protect video content with signed URLs.
Choosing a token lifetime
Lifetime is the one real design decision here, and almost nobody treats it as one. Too short breaks normal viewing, too long leaves a leaked URL useful.
| Lifetime | What it buys | What it breaks |
|---|---|---|
| 2 minutes | A leaked URL is dead before it can be pasted anywhere | A learner who pauses for lunch returns to a dead stream. Long seeks can fail mid-session |
| 15 minutes | Covers a normal lesson start, seeking and short pauses | A URL shared immediately still works for the rest of the window |
| 1 to 4 hours | Survives a long recording watched in sittings | A link in a group chat is live for the whole evening |
| 24 hours | Almost never breaks playback | Functionally an open URL for the day it was issued |
The rule is short: make the token outlive your longest single playback session, and nothing more. Fifteen minutes is the FastPix default, configurable from 2 minutes to 24 hours. If your longest lesson runs fifty minutes, the answer is not a 60 minute token. It is a player that renews mid-playback, worked through in signed video URLs in a React app.
This is worth testing rather than reasoning about. Set a two minute lifetime on one video, start playing it, pause for three minutes and resume. The free plan covers 10 videos, which is enough to run that test before you set a policy for a whole library.
What DRM adds, and what it costs
DRM changes the problem instead of the URL. The stream is encrypted, and it is decrypted inside a licence module in the browser or the operating system. What comes over the network is not a playable file, even if someone captures every byte.
That closes the two rows signed URLs leave open: the paying member saving the file, and the stream ripper. It does not close the camera. Screen recording depends on the platform's own output protection rather than on anything you set up. The full mechanism is covered in DRM explained.
The costs are worth naming before you commit. DRM needs a configuration ID, and you pick it per video rather than once for the site. In the FastPix plugin the choice depends on the quality tier picked at upload, which locks once the file transfers. A browser that cannot complete the licence exchange shows a message instead of a blank frame. That is the right behaviour, and it is still a viewer who did not watch.
What locking a video down costs you in search
Protection and search discovery pull against each other, and you cannot split the difference. You cannot let a crawler into a protected stream, so that video should carry no VideoObject markup at all.
Without the markup the video is not eligible for video rich results. Publishing it anyway advertises a video that nobody arriving from search can watch. FastPix emits structured data for public video and suppresses it for private and DRM, with a fastpix_structured_data filter where a site needs to change that. What the markup buys you is covered in how to create a video sitemap.
Caching causes a related problem. A full-page cache stores the HTML one visitor received and serves it to everyone else. If that page carries one member's access, the next anonymous visitor gets it too. So protected pages have to be kept out of the page cache. An edge cache outside WordPress cannot see a no-cache header set in PHP, which is why this breaks quietly on sites that added a CDN later.
Deciding which videos to protect
Most sites need two policies, because your marketing video and the thing you sell need opposite treatment.
- Public, with structured data. Previews, trailers, testimonials, the free first lesson. These exist to be found, so they keep
VideoObjectmarkup, stay cacheable, and may be embedded elsewhere. - Signed, short-lived. The paid lessons. Access tied to the post, token minted per render, no structured data, page excluded from caching.
- DRM. Only material where a circulating copy costs you a sale: exam preparation, certification content, anything with a resale market.
The common mistake is running the whole library at the strictest setting. It costs you the search traffic that fills the funnel, and protects free content nobody was going to steal. How to protect online courses from piracy covers the same decision from the course-business side.
Set the access policy before you upload the video
Access is easiest to get right at upload, because one choice there is permanent. The quality tier locks once a file transfers, and DRM depends on it. Read the FastPix upload and access guide for the three access levels and what each writes into the page. Then set private link lifetime to match your longest lesson, before you migrate a library. The free plan covers 10 videos, no card. Changing access later is one click. Changing tier means re-uploading.
Frequently Asked Questions (FAQs)
Do signed URLs stop someone downloading a video?
No. A signed URL stops the link working for someone else after it expires. The session holder already has an authorised URL and can save the file from the network tab while it is valid. Signed URLs defend against re-sharing, not the first download. See how to protect video content with signed URLs.
What does DRM stop that signed URLs do not?
DRM encrypts the stream. Decryption happens in a licence module inside the browser or the operating system, so what arrives over the network is not a playable file. That stops the file grab and the stream ripper. It does not stop a camera pointed at the screen. DRM explained covers the licence exchange.
How long should a signed video URL last?
Long enough to outlive one playback session, short enough that a leaked URL is useless by the time it is shared. Fifteen minutes is a common default. Two minutes breaks a learner who pauses and returns, and twenty-four hours means a URL pasted into a group chat works all day.
Does protecting a video hurt its SEO?
It removes it from video search entirely. A crawler cannot be let in to a protected stream, so VideoObject markup should not be emitted. Without that markup, the video is not eligible for video rich results. Keep marketing video public and protect only what is sold. See how to create a video sitemap.
Is blocking right-click enough to protect a video?
No. Right-click blocking runs in the viewer's browser, which the viewer controls. Disabling JavaScript, opening the network tab, or reading the page source defeats it in seconds. It stops an accidental save and nothing else.
Can a membership plugin protect the video file itself?
Not on its own. A membership plugin controls who can load the page. If the video is a file URL in that page's markup, the URL works for anyone who has it, regardless of whether they can reach the page. Page access control and media access control are separate problems.
Does watermarking prevent video piracy?
No, and it is not meant to. Watermarking is forensic: a marker identifying which account a leaked copy came from. It changes the incentive to share, but it never blocks the copy. How to protect online courses from piracy puts it next to the other controls.
