A share link that works the moment you make it.
Send it before the upload has finished. Put a password on it that works with JavaScript off. Delete the capture and the link dies with it.
Screenshots share and unfurl today; playback of shared recordings in Chrome is coming soon.
Press Copy link. That part is not a simulation.
The rest of the buttons change the link: let the upload finish, put a password on it, delete the capture behind it. The card a chat app draws and the page a stranger opens both change the way they change in the product.
Nothing is uploaded and no capture sits behind that address, which is reserved for documentation and can never resolve. The buttons change this page and your clipboard, and nothing else.
https://example.com/s/2f8b1c0dPasted in a chat
https://example.com/s/2f8b1c0d
The card is up before the bytes are. It names the link and offers no picture yet, because there is nothing to show for a moment longer.
What opens when they click
Screenshot
Still processing. This page will show it as soon as it is ready. The link already works, so you can send it now.
That is the viewer’s own wording, not a caption written for this page.
Nothing here is uploaded and no capture exists behind that address, which is reserved for documentation and can never resolve. The buttons change this page and your clipboard, and nothing else.
The link is live before the bytes are
The link is registered first and the file follows. You can paste it into a channel while the upload is still climbing, and it is already the right link.
If somebody opens it early, the viewer tells them so in its own words: Still processing. This page will show it as soon as it is ready - the link already works, so you can send it now.
That sentence is reserved. Only a capture that is genuinely still processing gets it; anything else with no player to show is a dead end and says so instead of asking anybody to come back later for something that is never coming.
Demos · coming soon
A link that will
walk them
through it.
The player will open in a browser with no install and no account. Arrow keys will move between steps, and every step will be real text underneath rather than pixels in a video somebody has to scrub.
- Chapters will jump straight to the step somebody needs
- Every step will be in the first byte, server rendered like the share viewer already is
Today
The share link works the moment it is created. Send it before the bytes arrive and the viewer says so itself, then fills in when they land.
A password gate that needs no JavaScript
The gate is a plain form post. Nothing has to run for it to work, which is why it holds up inside an email preview pane and in whatever stripped-down browser the person you sent it to happens to be using.
Ten attempts per link per ten minutes. The unlock is minted per link, so knowing the password for one link proves nothing about the next one, and a shared machine does not quietly open everything you ever sent.
A gated link gives up nothing before it is opened. The chat unfurl and the browser tab title both read Password protected
instead of the real name, because the name of a capture is frequently the whole secret.
Unfurls you can take back
A screenshot link unfurls into a real card in Slack, Teams and Discord: Open Graph tags, a Twitter card that degrades gracefully, and an oEmbed endpoint for the consumers that ask for one.
The embed points at our share page rather than at the video host, and that is an access control decision rather than a shortcut. Chat apps keep an unfurl in a message for ever. An embed aimed straight at the player would go on playing inside every channel it had ever been pasted into, long after the link was revoked. Ours re-checks the link on every single frame load, so revoking it, expiring it or adding a password takes hold the next time anyone looks.
Recording playback in Chrome
Screenshots share and unfurl today. A shared recording will play in Chrome, and the link you already sent will be the one that starts working.
Delete it and the link is dead
Deleting a capture kills its share link straight away, and restoring it from the trash brings the same link back. That round trip is not a promise on a page: an end-to-end test opens the link at each step and asserts all three answers, 200, then 404 while it is in the trash, then 200 again after the restore.
A link that never existed, one that expired, one somebody guessed, one whose capture was deleted: all four land on the same page. Probing tokens teaches nothing, which is exactly what it should teach.
The MP4 is not the file that left your machine
Cloudflare re-encodes it, and the page says so beside the link: MP4 re-encoded by Cloudflare - not the original file.
One sentence, one constant, printed identically wherever a download appears.
The download link stays put even when the player area is showing a notice. A file can be finished while the player is not, and in that state the link is the only thing on the page with the capture behind it.
Nobody is counting
Whoever opens your link is not measured. The share viewer mounts no counter and no third-party script, and a build check keeps it that way.
There is no view count on your side of it either. Nothing on this page is built on knowing who watched.
Sharing is a switch you turn on
None of this happens until you ask for it. Sharing is off in the desktop app until you turn it on and fill in both address fields, and captures stay on your computer in the meantime. A single card can still be uploaded on its own, to the address in Settings, which is how you share one recording with the switch still off.
With it on, a finished recording is registered with the address you gave, and the file itself goes to whatever upload address that server hands back, which may be a video host rather than the server you typed. The share link is copied to your clipboard. Anyone holding it can watch, so treat one like a password.
The privacy notice names everything that ever leaves your computer.