WebRTC is the technology behind every video call on Chatzyo, and it's worth understanding at a basic level — both because it explains why certain things work the way they do, and because it's the actual reason your conversations stay private, not a marketing claim layered on top.
Before two people can connect directly, they need a way to find each other on the internet. Our server's only job here is acting as a go-between, passing a small piece of connection information back and forth — no video or audio is involved at this stage at all.
Most devices sit behind a router or firewall that hides their true address from the open internet. WebRTC uses a protocol called STUN to discover each device's public-facing address, so the two browsers know exactly where to send video directly to each other.
Once connected, the video and audio are encrypted using DTLS and SRTP — protocols built into the WebRTC standard itself, not something Chatzyo added separately. This is mandatory; an unencrypted WebRTC call isn't possible by the standard's own design.
It's worth being precise here, since "encrypted" and "private from the platform" aren't quite the same claim. The encryption protects your call from being intercepted by someone outside the conversation — your internet provider, for instance. The reason Chatzyo specifically can't see or store your video isn't really about encryption at all — it's that the video is routed directly between the two devices and never reaches our servers in the first place. There's nothing encrypted sitting on our infrastructure that we're choosing not to decrypt; there's simply no copy of it on our side to begin with.
There's one honest exception worth naming: on some networks where a direct connection isn't possible — behind certain strict firewalls, for example — a relay server (called TURN) passes the already-encrypted data along. That relay can't read or decrypt what's passing through it, but it's accurate to say the data does pass through a server in that specific situation. We'd rather mention this directly than imply every connection is strictly device-to-device with no exceptions.
WebRTC depends on your actual network conditions, so a couple of genuine limitations are worth knowing:
Some corporate or institutional networks block the kind of direct connection WebRTC needs entirely. This is one of the more common reasons a call won't connect on a work or school network specifically — see our connection errors guide for more on this.
Encrypting and decoding video in real time takes real processing power. On an older phone or laptop, this can be more demanding than it would be on newer hardware.
Because the video itself doesn't need to be routed through a central server, Chatzyo doesn't need large server infrastructure handling video traffic the way a centrally-routed video service would. The signaling step is comparatively lightweight — just enough information to let two browsers find each other — which is part of why this kind of architecture works for connecting people across language rooms and regions without needing a heavy server presence everywhere.
None of this is something you need to understand to use Chatzyo — the signaling, NAT traversal, and encryption all happen automatically in the background every time you start a call. This page exists for the people curious about why things work the way they do, or who want to understand exactly what "peer-to-peer" means rather than taking the term on faith.