Play S3 Video in the Browser: A Presigned URL Video Player Guide
Play S3 Video in the Browser: A Presigned URL Video Player Guide
You uploaded a render to an Amazon S3 bucket—or an S3-compatible store like Cloudflare R2, Backblaze B2, MinIO, or Wasabi. The bucket is private, as it should be. Now you just want to watch the video, or send a teammate a link that plays without making them install the AWS CLI or hunt through a console.
There's a clean way to do this that doesn't involve downloading the file or making your bucket public: a presigned URL, dropped into a browser-native player. This guide explains what a presigned URL actually is, how to play an S3 video straight from one in the browser, and the single rule—format—that decides whether it'll play at all.
What a Presigned URL Actually Is
A presigned URL is the key to playing private S3 content without loosening your bucket. It's a normal HTTPS link to an object, with a temporary, cryptographically signed token baked into the query string. That signature says, in effect: "whoever holds this link may read this specific object until it expires."
Two properties make it perfect for video playback:
- Time-limited. You set the expiry—minutes, hours, days. After that, the link is dead. You're not creating permanent public access; you're handing out a temporary pass.
- Object-scoped. It grants access to that one object, not your whole bucket. Your other files stay private.
You generate one with the AWS SDK, the CLI (aws s3 presign s3://your-bucket/video.mp4 --expires-in 3600), or your provider's equivalent. The result is a long URL ending in signature parameters. That URL is all a browser-native player needs to fetch and play the object—no AWS credentials in the browser, no public bucket.
Why the Browser Can Just Play It
Here's the part that makes this effortless: a presigned URL is, to the browser, just a URL that returns video bytes over HTTPS. And modern browsers are already video players. Chrome, Edge, Safari, and Firefox decode H.264 and AAC natively, with hardware acceleration, and play MP4, WebM, and HLS streams directly.
So if the object behind your presigned URL is a browser-native format, there's nothing to convert, transcode, or download. You hand the URL to a player, the player requests the bytes from S3, and the browser's video engine plays them. The file stays in your bucket; only the stream reaches your tab. This is the same direct-playback model our play-video-from-URL guide covers in depth—S3 presigned URLs are simply one well-behaved source for it.
Crucially, nothing gets re-uploaded to a conversion service in the middle. The presigned URL points at your S3 object; the player just reads from it. Your video isn't copied to a third-party host to be watched.
How to Play an S3 Video from a Presigned URL
- Generate the presigned URL. Use the AWS CLI, an SDK, or your S3-compatible provider's tooling. Pick a sensible expiry—long enough to watch, short enough to stay safe. (Example:
aws s3 presign s3://my-bucket/clip.mp4 --expires-in 3600.) - Open the player. Go to the online video player.
- Paste the URL. Drop the full presigned URL—signature parameters and all—into the URL field.
- Play. If the object is a browser-native format, it streams and plays immediately on the original, no download.
To share it, send a colleague the same presigned URL and the player link; they paste and watch, no AWS access required on their end. When the URL expires, the link simply stops working—access revokes itself.
A small but real gotcha worth getting right: when you generate the URL, make sure the object's stored Content-Type is correct (e.g. video/mp4). If S3 serves your MP4 as application/octet-stream or binary/octet-stream, some browsers get confused about what they're receiving. Setting the right content type on upload keeps inline playback smooth.
Direct S3 Streaming vs. The Alternatives
| Approach | Download the object | Make bucket public | Presigned URL + browser player |
|---|---|---|---|
| Watch start time | After full download | Instant | Instant for native formats |
| Bucket stays private? | Yes | No—exposed to the world | Yes—scoped, temporary access |
| Leftover local copy? | Yes, on disk | No | No—stream in place |
| Re-upload to a host? | N/A | N/A | No—reads your S3 object directly |
| Shareable without AWS? | Send the file (huge) | Send a link (but public) | Send a link (private, expiring) |
Presigned URLs hit the sweet spot: instant playback, private bucket, expiring access, nothing downloaded, nothing re-hosted.
The Honest Limit: Native Formats Only
Time to be precise, because this is where "stream any S3 video" pitches overpromise.
Direct playback means the browser decodes the stream. That works for the formats browsers natively support:
- MP4 / H.264 (AAC audio): Plays everywhere. The dependable choice for S3-hosted video.
- WebM (VP8/VP9): Widely supported.
- HLS (
.m3u8): Plays where supported—handy if you've packaged adaptive streams in your bucket. - HEVC / H.265 in MP4: Works on recent Chrome, Edge, and Safari with hardware support; less universal elsewhere.
It will not play a format the browser can't decode. If your S3 object is an MKV container or uses an exotic codec, the browser has nothing to render it with, and there is no server in this flow quietly transcoding it for you. That's deliberate: the value here is reading your private object directly and playing it untouched, not running it through a conversion farm.
So if you need to watch a non-native S3 object, the honest path is: download it to your own machine and play it with a local player that can decode the format. (If you'd rather decode locally in the browser than install desktop software, the on-page player and the URL playback guide handle local files with full format support—a separate mode from streaming a remote URL.) Better still, for video you intend to stream, store an MP4/H.264 version in your bucket from the start; it plays anywhere with zero friction.
Two more practical notes. First, original-quality streaming needs a real connection—a full-bitrate 4K object will buffer on weak networks; that's the cost of playing the source instead of a downscaled proxy. Second, mind your expiry: if a link goes dead mid-watch, the object isn't gone, the token expired—regenerate the URL with a longer window.
FAQ
Do I have to make my S3 bucket public? No. A presigned URL grants temporary, object-scoped read access while your bucket stays private. That's the entire reason to use one.
Does my video get uploaded to a third-party server? No. The presigned URL points at your own S3 object; the player reads from it and plays in your browser. Nothing is re-uploaded to a conversion host.
Why won't my MKV file play from the URL? Browsers don't natively support the MKV container, and there's no behind-the-scenes transcoding in this flow. Download it and play it locally, or store an MP4 version in your bucket instead.
My MP4 won't play inline—what's wrong?
Most often the object's Content-Type is wrong. Make sure it's served as video/mp4 (set it on upload) rather than a generic binary type.
Does this work with R2, B2, MinIO, or Wasabi? Yes. Any S3-compatible store that issues presigned (signed) URLs works the same way—the player just needs a URL that returns the video bytes.
What happens when the URL expires? The link stops working—access revokes itself automatically. Regenerate a fresh presigned URL to watch again.
The Bottom Line
A presigned URL plus a browser-native player is the cleanest way to watch S3 video: instant playback on the original file, your bucket stays private, access expires on your schedule, and nothing is downloaded or re-hosted along the way—as long as the object is a format the browser can decode. For everything else, download and play locally, or store an MP4 in the bucket up front. That's the honest boundary, and for S3 video it's an easy one to design around.