Private — Encrypted in Transit

All sensitive message content is AES-256 encrypted on your WordPress server before transmission through the WebSocket infrastructure. The relay server only handles encrypted data and cannot read message content. Decryption happens in the browsers using your messenger, with a key your site generates and hands only to them, never to the relay.

WebSocket version

This is a WebSocket-version feature. The free version uses AJAX polling against your own WordPress server, so no third-party relay is involved.

What it adds#

AES-256 encryption of all message content on your WordPress server before send
WebSocket relay server cannot decrypt or read messages
Decryption only in the authorized recipient's browser
Message text never reaches the relay in plain form
Identical encryption applied to private DMs, group chats, and chat rooms
Same protection covers attachments, voice messages, and other content payloads

How it works#

When a user sends a message, your WordPress server encrypts the content with AES-256 using your site's own secret key before pushing it to the WebSocket relay. The key is generated on your site and stored in your database, and your server gives it only to the browsers that load your messenger. The relay forwards the encrypted payload to the conversation participants' open connections, and each participant's browser decrypts it locally.

Stage	What's visible
Sender's browser → your server	Plaintext over HTTPS
Your server encrypts → relay	Encrypted ciphertext only
Relay → recipient's browser	Encrypted ciphertext only
Recipient decrypts	Plaintext locally

The relay's role is purely to route encrypted bytes between participants — it has no key, no inspection capability, no ability to comprehend what it's forwarding.

Frequently asked questions#

Is this the same as end-to-end encryption?#

No — this is transit encryption. The WordPress server has the key. For true end-to-end encryption (where only the participants — not even your server — can decrypt), use the optional end-to-end encryption (E2EE) per-thread feature.

Is anything readable on the relay?#

Only the ids it needs for routing (user, thread and message ids) and the text of web push notifications, which by default only names the sender. Better Messages Cloud AI features are a separate service you switch on, and they do read the text they translate, moderate or transcribe, then discard it. See where messages are stored for the full list.

Does this require any setup?#

No — encryption is automatic on the WebSocket version. There's no key management, no user-facing setup.

Does this apply to file attachments?#

File attachments are stored on your server. Their URLs are encrypted in the message payload, and the files themselves are served through your WordPress media library security model. If you turn on end-to-end encryption, the file contents are encrypted too — each file gets its own AES-256-GCM key, applied in the browser before upload.

Are voice / video call streams encrypted?#

Yes — WebRTC uses DTLS/SRTP encryption for all media streams. See Secure for the connection-layer details.

Can attackers intercept messages over the WebSocket?#

The WebSocket connection is itself TLS-encrypted (WSS). Even before AES-256 content encryption, the transport layer is secure. Combined, an attacker would need to break BOTH TLS AND AES-256 — neither is feasible with current technology.