How it works
WebRTC peer-to-peer chat, explained
After the handshake there is no server in the path, so there is nothing to store and nothing to hand over. Here is exactly what the backend sees, and the three things peer-to-peer does not buy you.
Open a peer-to-peer room
Open a peer-to-peer roomThe server's only job is the introduction
Every chat app you have used works the same way underneath: your message goes up to a company's server, the server keeps it, and the server hands it down to the other person. Encryption arguments are about who can read that copy. The copy still exists.
A WebRTC DataChannel skips the middle step. Two browsers negotiate a direct encrypted connection, and once it is open your message goes from your machine to theirs with nothing in between. FadeChats does run a server, but it works like a switchboard operator: it passes along the details the two browsers need to find each other, then it is out of the conversation.
That is the whole trick, and it is why this site has no "delete my data" button. There is no message table to delete from.
What happens between opening the page and typing
- Your browser writes an offer
It builds an SDP offer describing the transport it supports, plus the fingerprint of a certificate it generated for this session. The offer goes to the FadeChats server, parked under a random room id.
- The other browser answers
Your guest opens the one-time invite link, picks up the offer and posts back an answer. Both sides also trade ICE candidates: the network addresses each might be reachable on, discovered with help from a STUN server.
- The two ends shake hands directly
ICE tries candidate pairs until one connects, then the browsers run a DTLS handshake over it. They derive the keys themselves and check each other against the fingerprints committed to in step one.
- The channel opens, the server is done
Text, images, GIFs and stickers ride an SCTP stream inside that DTLS session, browser to browser. The setup records expire on a 10-minute TTL that activity renews.
Who can see what
| The person you invited | FadeChats' server | A TURN relay, when needed | |
|---|---|---|---|
| Messages, images, GIFs | Yes, that is the point | Never | Encrypted bytes only |
| The room id | Yes | Yes | Yes |
| Your IP address | Yes, on a direct connection | Yes, during setup | Yes, while relaying |
| That the room was active | Yes | Until the TTL expires | While relaying |
| Anything after the room fades | Only what they captured | Nothing was ever written | Nothing |
Each side learning the other's address is a property of the transport, not a setting you can turn off.
Three things peer-to-peer does not buy you
- Your peer sees your IP address
A direct connection has two real endpoints, so the person you invited learns roughly your city and your ISP. Signal hides that by relaying everything through its own servers. FadeChats cannot, because relaying everything is the thing it refuses to do.
- Sometimes there is a relay anyway
Symmetric NAT, corporate networks and some mobile carriers block a direct path. WebRTC then falls back to a TURN relay, which forwards DTLS-encrypted bytes it holds no key to. Still a third machine in the path, and worth saying out loud.
- The handshake trusts the signaling channel
Each side verifies the other's certificate fingerprint, but the fingerprint arrived over the server. A compromised signaling server could in principle swap it and sit in the middle. Signal solves this with safety numbers you compare out of band; FadeChats has no such check.
Where this shape fits
Peer-to-peer is right when two people need to say something once and want no copy of it anywhere: a password with a follow-up question, an address, a diagnosis, a number. It is the wrong shape for a group, for anything that has to survive a closed tab, and for a situation where being wrong about your adversary has real consequences.
The address you never negotiated
One honest line from the table above: peer-to-peer means the other end learns your IP, which points at a city and an ISP. That is small next to the disclosure most people already carry without knowing it, on people-search pages that publish a street address under a real name.
Disclosure: the link below is an affiliate link. If you subscribe through it, FadeChats earns a commission at no extra cost to you. FadeChats itself stays free, ad-free and account-free — this is what pays for the writing.
Optery scans hundreds of those sites, files the removals and re-checks monthly, since brokers relist anyone whose record they can still sell. The free tier returns the report with screenshots before you pay anything. It has nothing to do with your chat and will not touch your IP, and coverage is US, Canada, Australia, New Zealand and South Africa only.
See your exposure report
Frequently asked questions
Does a WebRTC chat need a server at all?
Yes, but only to introduce the two browsers. A signaling server carries the offer, the answer and the network candidates; a STUN server tells each browser what its public address looks like. Once the DataChannel opens, neither one is in the path of a single message.
Can the signaling server read my messages?
No, it never receives them. The channel is negotiated between the browsers and the keys are theirs. FadeChats' server holds only the setup records, and those expire on a 10-minute TTL renewed by activity.
Does the other person see my IP address?
On a direct connection, yes, and so do you see theirs. That is what makes it direct. If you need it hidden from the person you are talking to, use a VPN, or use a tool that relays everything, like Signal.
Is a WebRTC DataChannel end-to-end encrypted?
The transport is: SCTP inside DTLS, with keys the two browsers derive themselves. The caveat is the fingerprint exchange above. End-to-end encryption in WebRTC is only as trustworthy as the channel that carried those fingerprints.
Do I need to install anything to try it?
No. WebRTC ships in every current browser, so FadeChats is just a page you open. No account, no phone number, no app. The room exists when the page loads and it holds two people.