DTLS-SRTP on every stream
Every WebRTC media stream is encrypted in transit using DTLS-SRTP with per-session keys negotiated inside your browser.
Security & Privacy
Private by architecture, not by promise.
Most video platforms encrypt calls in transit and then decrypt them on a server they own so they can re-encode, record, or transcribe. 4K Chat has no such server. Media never leaves the browsers on the call.
Per-frame E2EE on video
Not a toggle: wherever the browser supports encoded transforms, every video frame is sealed with a sender key only your peers hold, automatically. Audio is carried by DTLS-SRTP straight between devices — with no server in the path, there is nothing in between to decode it.
4-emoji Safety Number
Verify you're talking to the right person out-of-band with a short emoji fingerprint derived from the DTLS handshake.
Host-approved camera admission
Extra camera sources can't publish until the session initiator — or a delegate the host names — approves them. The check is enforced server-side on identity, at the publisher, and at every receiver.
No media servers, no recordings
There is no SFU, no TURN relay, and no cloud recording pipeline. Your call literally cannot leak from an infrastructure we don't have.
Local-only recording
If you record, the WebM file is written to your device via MediaRecorder. Nothing is uploaded.
Zero standing data
Signaling rows and connection logs are auto-deleted on a rolling window. There is no long-lived history of who called whom.
What we can and can't see
We can see
- Room codes while a call is active (auto-deleted afterward)
- Anonymous ICE candidate exchanges during connection setup
- Subscription email addresses for paid tiers (via Stripe)
We cannot see
- Any video or audio frames — they never touch our servers
- Peer data beyond video and audio — not shipped. When a P2P A-to-B pipe lands (control, telemetry, files, LUT, timecode), it stays between peers.
- Who is talking to whom after the call ends
- Recordings — they exist only on the recorder's device