How you're protected

What Wallflower can and cannot see when you broadcast — and the parts we can't protect you from, stated as plainly as the parts we can.

We cannot watch your broadcast. Not as a policy we promise to keep, but because the key doesn't exist on our side. Your browser encrypts every frame before it leaves, using a key derived from a secret that lives only in the part of your share link after the # — and browsers never send that part to a server.

So it never reaches our servers, our database, our logs, or the CDN that carries your video. If we were asked for your stream, by anyone, we would have nothing to give.

What each party sees

WhoSeesCannot see
Us That a broadcast happened, when, and how long Your video, your audio, your chat, your location
The CDN Encrypted bytes, your IP address, timing Anything inside those bytes
Your viewers The stream, if you gave them the link — and the passcode too, if you set one Anything else
Everyone else Nothing at all Even encrypted bytes are out of reach without the link

Your broadcast is also not announced anywhere. There is no directory, no index, no public listing, and nothing published to any outside network that would reveal a stream exists or where it is being carried. The only way anyone learns about your broadcast is because you sent them the link.

You are not an account

There is no sign-up, no email address, no password, and no profile. Broadcasting needs a publish code, which you can request in a few seconds without telling us anything about yourself. We don't store the code, so there is no record connecting you to anything you broadcast — nothing for us to look up, and nothing for anyone to compel from us.

Each broadcast also identifies itself with a fresh cryptographic key that is created in your browser and never leaves it. That means your broadcasts are not linkable to each other, even by us.

We collect no location data

None — not country, not city, not coordinates, for broadcasters or viewers. Earlier versions of Wallflower did record broadcaster location. Those records were deleted, the columns that held them were removed from the database, and the backup taken beforehand was destroyed.

We will never take a cut of what you earn

Wallflower is building a way for viewers to pay for a broadcast directly — fans buy seeds and plant them on a streamer, who spends them on the bandwidth their own viewers use, or cashes them out. It is a preview you can try today — no card is charged and no payout is sent yet.

Seeds only ever move one way: toward being spent, never back toward money. Seeds you buy pay for streaming — your own, or someone else's if you plant them — but they can never be turned back into cash. Only seeds a fan planted on you can be cashed out. A seed given free at sign-up can only be burned on your own bandwidth.

Streamers can also send each other streaming time, and what arrives is different from what left: it pays for that streamer's viewers and can never be cashed out — not by them, and not by anyone they pass it on to. So value crossing between creators always loses the ability to become money, and no chain of hands gives it back.

That is a deliberate restriction rather than a missing feature. A balance that moves from person to person and then out to cash is a payments product, with the licensing that implies; seeds that flow one way and stop are what Twitch and Patreon have always done. Keeping the two apart is also what stops a stolen card being laundered through a vault, and what stops free credit being farmed into somebody's payout.

No ads, ever

We will never run advertising against a broadcast. This is the same commitment as the one above and it rests on the same thing: streamers pay for delivery, so a viewer never has to be the product. There is no third party to sell an audience to, because selling the audience is not how any of this is paid for.

It follows from the architecture as much as from the principle. We cannot see your video — it is encrypted before it leaves your browser — so we could not target an advert against it even if we wanted to, and we hold no profile of a viewer to target with. An advertising business would require undoing most of this page.

The commitment governing it is worth stating before it ships rather than after: we take 0% of what a streamer cashes out, permanently. Not an introductory rate and not a rate that rises with your audience. Zero.

Be clear about what that does not claim, because a promise that overstates itself is worth nothing. It does not mean there are no fees: Stripe charges a flat $0.25 to move money to your bank, and you bear that. The fee for accepting the fan's card is paid by the fan, shown as a line item when they buy — so the person who chose the payment method is the one who pays for it, and a seed in your vault is worth a whole dollar. Our cash-out screen itemises that $0.25 alongside our own line reading $0.00, so you can always see exactly who took what. And it does not mean the service is free to run: a seed costs a dollar and delivers rather less than a dollar of bandwidth, and that difference is our business.

That difference is also why the promise is keepable. We earn on delivery, so we have no reason to reach into your earnings — and no reason to prefer that you cash out rather than keep streaming. It is why the same screen shows you what waiting for a larger payout would save you in Stripe fees: that advice costs us nothing either way, so you can trust it.

What we count

We do record that a broadcast had an audience: for each viewing session, which stream it was, when it began, and when it ended. That is how a broadcaster sees a viewer count, and how we know what our own bandwidth is being used for.

A session is a browser tab, not a person. Nothing attached to it identifies anyone — no IP address, no IP hash, no cookie, no fingerprint, no location. The practical consequence is the part worth checking: because there is no identifier, two sessions can never be shown to be the same human, whether on one stream or across different ones. One viewer who reloads the page is counted twice, and we cannot tell that they were the same person. We accept that inaccuracy deliberately — the only way to fix it is to keep something that identifies a viewer, and that is precisely what must not exist here.

An operator can read and export these counts per stream. What they get is how many sessions watched and for how long. What they cannot get, because it was never recorded, is who.

Controlling who watches

The link is the key

Anyone holding your complete share link can watch. Anyone without it cannot — not even someone who knows your stream's name, and not us. Treat the link the way you'd treat a door key, and send it through a channel you trust.

The passcode is a second lock, and you switch it on

By default, your link is the only thing needed to watch. Anyone you send it to can open it; anyone without it cannot. For most broadcasts that is the whole of what people want, and it is what you get without touching anything.

Under Protect there is a second secret. Switch it on and a viewer needs the passcode as well as the link. It is deliberately not part of the link — send it separately, by a different app or out loud — so intercepting one channel gets an eavesdropper nothing. The control reads Protected for as long as it is armed, because a passcode you have forgotten you set is a room nobody can get into.

Decide before you go live. Once you go live the choice is frozen, because by then every link you have sent already carries the answer, and changing it would strand the people holding those links. Encryption itself is never optional and cannot be switched off; the passcode governs only whether the link is sufficient on its own.

This default has moved twice and it is worth being straight about why it moved back. It was on by default until 28 August 2026, on the argument that a protection nobody enables protects nobody — which we still think is true. What it left out is who pays for it: a second secret has to reach every viewer by a second route, and someone sending a link to five friends does not want a second errand, they want the link to work. It was also put in front of people before they had done anything, as a decision they had not asked to make. A protection that makes the ordinary case harder gets switched off rather than used, and this one mostly was.

Re-keying it mid-broadcast takes effect within a second or two: anyone watching with the old passcode stops being able to decrypt, and your link doesn't change. (The change lands on the next keyframe, so the picture they already have finishes first.)

Or start a new link

If the link itself has gone somewhere you didn't intend, New link is the blunt fix. It ends the current broadcast and starts another one with a new address and a new key, so nothing that was shared before still works. Your camera and microphone stay exactly as you had them — only the address changes — but everyone watching drops, so you'll need to send the new link to the people you still want there.

Chat is protected the same way

Messages and display names are encrypted in your browser under a key derived from the same link. Our chat server relays text it cannot read. That also means we cannot moderate chat — there is nothing there for us to read.

Moderation, and what it costs

Because we can't see what anyone broadcasts, we can't police content. What we can do is stop a stream: viewers can report one, and an operator can terminate it. Terminating takes effect for people already watching — it doesn't merely stop new ones — and it works whether or not the software they're using cooperates.

A report can carry one still picture. It is taken from the reporter's own player — their device already decoded your video in order to show it to them — and they see it and can remove it before anything is sent. That single frame is the only part of any broadcast we ever hold, and we delete it thirty days later while keeping the record that a complaint was made. We built it because the alternative was worse: without it an operator decides whether to end your broadcast on a stranger's word alone.

Beyond that one frame, nothing changes. We cannot say what a terminated stream contained, produce a recording of it, or show a complainant anything more. Stopping is still the whole of what we can do.

The limits

These are real. A page that only listed strengths wouldn't be worth reading.

A link can't be recalled. Once you've sent it, anyone who receives it — or is forwarded it — can watch. We can't revoke it for one person, because we can't decrypt it either. What you can do is cut off everyone: New link starts a fresh broadcast under a new address and a new key, so every copy of the old link stops working — including ours, if we had kept one. If you set a passcode, re-keying it is the finer instrument: it cuts people off without changing your link or interrupting the broadcast. Without one, New link is the only instrument you have.

Anyone watching can record. A viewer's own device necessarily decodes your video to display it, so it can also save it. No system that shows people video can prevent this, and we don't claim to.

Your IP address is visible to the network. The CDN that carries your stream sees the address you connect from, and so does Cloudflare, which serves this site. We don't store it — but we can't hide it from them. If being located matters to you, use a VPN or Tor. That's the one protection we can't provide for you.

We can see that you broadcast, even if not what. Times, durations and how much data moved are visible to us and to the CDN. Encryption hides content, not the fact that something happened.

How to know this is true

None of the above is taken on trust internally either. Each claim is checked against the running service by automated tests, and the ones that matter most are the negative ones — tests that try to break a promise and must fail:

A fuller written assessment, including every known weakness and its severity, is kept as a dated security posture document. Ask and we'll send you the current one.

Last reviewed 28 August 2026. This describes Wallflower as it runs today; it will be rewritten when that changes rather than quietly left standing.