What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
You cannot make a playable video URL completely invisible to the person watching it. The browser must request enough media data to play the video, and that request can be observed or captured. What PHP can do is keep the original file outside the public web root, authorize each media request, and issue a temporary or session-bound response so a copied link is harder to reuse.
What “hide the URL” can mean
These are different security goals:
- Hide the filesystem path: store the video where a normal web request cannot fetch it directly.
- Require authorization: make a PHP endpoint check the logged-in user, entitlement, or session before serving the file.
- Prevent viewers from discovering the media request: this cannot be guaranteed while a browser is receiving a playable resource.
Ryan Reese summarized the last limitation in a SitePoint discussion: “There is nothing you can do to hide the URL of the video completely. If someone wants to get it, they can.” That is a forum participant’s practical observation, not a formal security standard, but it describes the browser constraint accurately.
The pattern that protects the original file
- Place the video outside the server’s public document root. For example, keep it in an application storage directory rather than beside
test.phpor another publicly served page. - Expose a public PHP endpoint such as
video.php?id=..., not the storage path. - Authenticate the request and verify that the current user or session is allowed to watch that particular video.
- Resolve the requested identifier to a server-side file path. Never treat a user-supplied path as a filename.
- Return the media through the endpoint, or hand it to a server-supported protected delivery mechanism.
With this arrangement, requesting the old static path should fail because the file is not in the public tree. The endpoint can still reveal a request URL in browser developer tools; that is expected.
A session-bound identifier: useful idea, not a security guarantee
The 2016 SitePoint thread that prompted this question used a session value and an MD5-derived parameter to look up a video. Its progression was to move the file into a sibling directory, test a PHP endpoint, add a conditional access check, and then point an HTML5 <video controls> element at that endpoint.
#1 Best Overall
The important idea is the server-side lookup: the client sends an opaque identifier, while PHP obtains the real path from trusted session or database data. The MD5/session scheme itself should not be treated as modern security guidance. Use unpredictable, expiring identifiers and enforce authorization on every request instead of relying on obscurity.
Illustrative request flow
<video controls>
<source src="/video.php?id=opaque-token" type="video/mp4">
</video>Conceptually, video.php should:
- Start or validate the authenticated session.
- Read the opaque token.
- Look up the corresponding video record and permitted viewer.
- Reject missing, expired, or unauthorized records.
- Serve only the resolved file through a carefully configured media response.
This snippet is illustrative, not production-ready code. The original thread explicitly leaves PHP streaming functions as “another topic,” so its short example does not implement a complete modern streaming solution.
Rank #2
What a production implementation still has to solve
- Authorization on every request: do not authorize only when the page loads; the media request must be checked too.
- Path safety: map database IDs or random tokens to known files. Do not concatenate raw query-string input into a filesystem path.
- Expiry and revocation: make temporary links expire or bind them to an account/session when that matches your access model.
- HTTP media behavior: seeking and reliable playback can require correct response headers, byte-range handling, conditional requests, and support for interrupted downloads. Verify the behavior required by your PHP version, web server, proxy, and hosting provider.
- Performance: routing large files through PHP can consume application workers and bandwidth. Prefer a server-supported protected-file mechanism when your host provides one, and test concurrency before deployment.
- Transport security: use HTTPS so credentials and media requests are not exposed in transit.
- Logging and abuse controls: record authorization failures and apply rate limits appropriate to your audience and bandwidth budget.
What this approach does not stop
- A viewer can inspect network requests and copy the endpoint URL while playback is occurring.
- A viewer can save received media, use screen recording, or share valid credentials.
- A temporary or session-linked URL can reduce casual reuse, but it is not foolproof against capture or sharing.
Disabling right-click is not a meaningful control. JavaScript-based blocking can be bypassed simply by disabling JavaScript, and it does not prevent access to requests made by the player.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Self-hosting versus managed video delivery
| Approach | Addresses | Limits and questions to verify |
|---|---|---|
| File outside the public directory plus an authorized PHP endpoint | Direct requests to the origin file path and application-level permission checks | The historical forum example is incomplete and old; verify streaming, range requests, server configuration, scaling, and current PHP behavior. |
| Managed video hosting | Delegates storage, delivery, and playback infrastructure to a provider | Features, privacy controls, terms, bandwidth pricing, and suitability vary by current product and region. A historical forum mention of Vimeo Pro is not a current recommendation. |
Choose based on whether you need account-level authorization, how much delivery bandwidth you can operate, the playback features your audience requires, and which protected-delivery methods your hosting provider currently supports.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsQuick Recap
Rank #4
A practical decision checklist
- If your goal is only to stop a visible public filename, move the media outside the document root and remove direct static access.
- If access depends on a subscription or login, enforce that rule in the media endpoint itself.
- If copied links should stop working later, use expiring or revocable server-side tokens.
- If you need dependable seeking or large-scale delivery, do not deploy the short SitePoint snippet unchanged; validate a complete range-capable delivery design.
- If you require absolute secrecy from authorized viewers, change the requirement: a browser-based player cannot provide that guarantee.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
