Video calling is one of the more challenging surfaces to secure. Unlike text messages, which are small and easy to encrypt end-to-end, video streams create real-time encoding and decoding pressure that historically made true E2EE impractical for group calls. That's changed — but not uniformly across every app that markets itself as secure.
The distinctions that matter: whether content is encrypted end-to-end or only in transit, whether the server can see your video, what call metadata is retained, and whether the source code is auditable. These aren't marketing questions — they determine what an adversary (a hacker, a data requestor, a rogue employee) can actually access.
What "Encrypted" Actually Means for Video
Most video platforms use transport encryption — your video is encrypted between your device and the server, decrypted on the server, then re-encrypted for delivery to the other participant. This protects against network interception but means the server operator can see your call content. It's the same model used by HTTPS for web browsing.
End-to-end encryption (E2EE) for video means the server routes encrypted packets it cannot decrypt. Only the call participants hold the decryption keys. For 1:1 calls, this is relatively straightforward. For group calls, it requires a key distribution protocol that doesn't create a single server-side decryptable stream.
Most group video infrastructure uses a Selective Forwarding Unit — a server that receives all participants' encrypted streams and routes relevant ones to each participant. True E2EE over SFU requires each participant to encrypt their stream for every other participant's key, which is architecturally complex. Some services achieve this; others route via an MCU (Multipoint Control Unit) that must decrypt to mix streams, making real E2EE impossible.
Signal: The Strongest Privacy Case
Signal's video calls use the same end-to-end encrypted channel as its text messages, derived from the Signal Protocol. For 1:1 calls, this is straightforwardly E2EE — Signal's servers route SRTP packets encrypted with keys that Signal never holds.
Group video calls (up to 40 participants) use Signal's Selective Forwarding Unit architecture with per-participant encrypted streams. Signal's servers see only ciphertext and routing metadata — not call content. Signal does not retain call records or duration metadata beyond what's operationally required for routing.
The limitations: Signal is tied to a phone number, which is a deanonymization vector. Signal does not support federated servers — you're using Signal's infrastructure. And the desktop and mobile apps, while open source, are not reproducible builds that anyone can independently verify. For most threat models, Signal video is the strongest option among consumer apps. See our analysis of Signal's phone number dependency for the tradeoffs.
Zoom: A Mixed Record
Zoom introduced end-to-end encryption for video calls in late 2020, following significant criticism. The implementation — available when all participants use Zoom clients (not browser-based connections) and the host enables it — uses per-meeting ephemeral keys that Zoom's servers cannot access.
However, E2EE on Zoom is opt-in by the host, not the default. Standard Zoom calls use transport encryption only, with Zoom's servers decrypting and re-encrypting content. Many enterprise Zoom deployments explicitly disable E2EE to preserve recording and compliance capabilities. A call that looks identical to the participant may or may not be end-to-end encrypted depending on the host's settings.
Zoom also collects substantial metadata: call duration, participant IP addresses, device identifiers, and — in non-E2EE calls — meeting content for features like cloud recording and live transcription. Zoom is a Delaware corporation fully subject to US legal process.
FaceTime: Apple's Architecture
Apple's FaceTime uses end-to-end encryption for both 1:1 and group calls (up to 32 participants). The encryption keys are derived on-device and Apple has stated it cannot decrypt call content. Group FaceTime uses a relay server for NAT traversal, but the content passing through it is encrypted with keys Apple doesn't hold.
The important caveats: FaceTime is Apple-only, closed-source, and its E2EE claims are self-reported with no independent cryptographic audit of the group call implementation that's publicly available. Apple is a US company subject to US law, though the technical design — if accurate — means there's nothing useful to hand over from call content. iCloud Backup is a separate concern: if you back up your device to iCloud without Advanced Data Protection enabled, your iMessage history (not FaceTime calls themselves) may be accessible. See our post on iMessage and iCloud backup privacy.
Element / Matrix: Open Federation
Element uses the Matrix protocol for messaging and WebRTC (via Element Call, built on LiveKit) for voice and video. The privacy posture depends heavily on which Matrix homeserver you're using and how calls are routed.
Element Call supports end-to-end encrypted group calls using the MLS protocol (RFC 9420), which provides strong forward secrecy and cryptographic group membership guarantees. This is among the most technically sophisticated group call encryption available in a consumer app.
The complexity is the trade-off. Matrix is federated, which means call routing may traverse servers you don't control. Self-hosting a Matrix homeserver and a dedicated TURN server gives you full infrastructure control — but that's not a consumer use case. If you use matrix.org as your homeserver, you're trusting the Matrix.org Foundation's infrastructure. The metadata exposure depends on your server configuration.
Jitsi Meet: Open Source, Variable Deployment
Jitsi Meet is fully open source and can be self-hosted — which is its primary privacy advantage. The public instance at meet.jit.si is operated by 8x8, Inc., a US company. Self-hosted Jitsi gives you full infrastructure control and no third-party data exposure.
Jitsi's E2EE implementation for group calls uses insertable streams — each participant encrypts their media stream with a per-participant key before it's sent to the SFU. The Jitsi server routes encrypted packets it cannot read. This works, but requires all participants to use browsers supporting insertable streams (Chrome-based browsers; Firefox support has been limited).
Jitsi is the strongest option if you control the server. The public meet.jit.si instance is reasonable for low-sensitivity calls where the convenience of no account creation matters — but don't assume it provides the same privacy as a self-hosted deployment.
Comparison at a Glance
| App | E2EE Video | E2EE Group | Open Source | No Account Required | Metadata Retained |
|---|---|---|---|---|---|
| Signal | ✓ Always | ✓ Yes | ✓ Yes | ✗ Phone number | Minimal |
| Zoom | ~ Opt-in | ~ Opt-in | ✗ No | ~ Join link | Substantial |
| FaceTime | ✓ Yes | ✓ Yes | ✗ No | ✗ Apple ID | Low |
| Element / Matrix | ✓ Yes | ✓ MLS | ✓ Yes | ✗ Account needed | Server-dependent |
| Jitsi Meet (self-hosted) | ✓ Yes | ✓ Yes | ✓ Yes | ✓ Yes | None (self-hosted) |
| Jitsi (meet.jit.si) | ✓ Yes | ~ Browser-dependent | ✓ Yes | ✓ Yes | US company, some metadata |
| ✓ Yes | ✓ Yes | ✗ No | ✗ Phone number | Significant (Meta) | |
| Google Meet | ✗ Transport only | ✗ Transport only | ✗ No | ✗ Google account | Substantial |
What Metadata Reveals Even When Content Is Encrypted
A recurring theme in privacy analysis: metadata can be as revealing as content. For video calls, even with E2EE, the following is typically visible to service providers:
- Who called whom (account identifiers or phone numbers)
- Call duration and timestamp
- IP addresses of participants (often retained for billing or abuse prevention)
- Device identifiers and client version
- Whether the call was answered or declined
For most users in most situations, this is an acceptable trade-off. For journalists, lawyers, activists, or anyone with a sensitive contact network, call metadata can expose relationship graphs that are more dangerous than any specific conversation.
Making the Right Choice for Your Threat Model
There's no universally correct answer — the right video call app depends on what you're protecting against and what constraints your contacts can accept. A lawyer who needs secure client calls has different requirements than a family staying in touch across continents.
The clearest hierarchy: Signal for most high-sensitivity use cases where participants will install an app; self-hosted Jitsi for ad-hoc calls requiring no accounts; Element/Matrix if you need federation or are running privacy infrastructure; FaceTime for Apple-only contexts where you trust Apple's self-reported architecture; Zoom for everything else where privacy isn't the primary concern.
For a broader picture of what encryption protects in messaging and calling, see our post on what end-to-end encryption actually covers.