Element

What Is Element?

You want encrypted messaging that doesn’t lock you into one company’s server—and you don’t want the “add a phone number, trust us” model. Element is built for that exact problem: it’s a chat app that can run on the open, federated Matrix network, so you can use a public server, join an organization’s server, or run your own—without changing apps.

Element’s target audience is broad, but the sweet spot is teams and communities that need Slack-like rooms, threads, and file sharing plus end-to-end encryption (E2EE) and deployment flexibility. If you’re comparing it to Signal/WhatsApp, Element’s differentiator isn’t “better crypto marketing”—it’s that Matrix is an open standard and Element is one of the flagship clients, designed to work across different servers and even different Matrix clients.

The trade-off is also clear: because Element rides on Matrix’s federated architecture, you have more control and interoperability than centralized messengers—but you also inherit Matrix’s complexity (devices, key backup, server choice, federation boundaries). Element tries to paper over that with device verification and secure backup flows, but the system is still more “power tool” than “one-button messenger.”

Element Features and Performance

Element’s core feature set is what you’d expect from a modern team messenger: rooms, threads, read receipts, reactions, polls, attachments, voice messages, and location sharing. It also supports “Spaces” (room grouping) for organizing large communities or multi-team workspaces.

Protocol and architecture (what matters)

Element is a client for Matrix, an open standard for real-time communication. Practically, that means:

• You log into a homeserver (your org’s, your own, or a public one) and your account is a Matrix ID like @name:server.
• Messaging works across servers via federation (if allowed), so different organizations can communicate without sharing one vendor’s infrastructure.

For privacy and security, the headline is E2EE. Element’s docs describe how encrypted direct messages and private room creation default to encryption, while still allowing configuration to disable encryption by default (depending on server configuration).

Key management: device verification + secure backup

Element pushes you toward two practices that are non-optional if you care about staying encrypted across devices:

• Cross-signed device verification (QR/emoji verification) so new logins can access encrypted history safely.
• Secure Backup to preserve your encryption keys so you don’t lose access to encrypted history when you change devices or reinstall. Element’s support docs explicitly describe being prompted to set up Secure Backup after sending your first encrypted message.

This is good security hygiene, but it’s also where many “Element feels complicated” complaints come from. If you skip backup/verification, you can lock yourself out of your own history.

Voice and video calling (Element Call, MatrixRTC)

Element includes voice/video calling, with two important eras:

• Older group calling historically relied on Jitsi integration (server-mediated). Element’s current direction is to replace Jitsi-based calling with Element Call, described in Element’s docs as the “next generation of video calling.”
• Element Call is built around MatrixRTC work. The Element Call repository documentation describes how it discovers MatrixRTC transports via an unstable Matrix client-server API endpoint and uses a MatrixRTC Authorization Service to provide LiveKit SFU connection details and a JWT for WebRTC media exchange.

Element’s privacy policy states that Element Call is end-to-end encrypted and also notes the kinds of network/usage information processed to provide the service (including IP addresses), plus references to LiveKit usage (self-hosted LiveKit by default for Element Server Suite; LiveKit Cloud for call.element.io).

Performance notes: “it depends” (server + sync tech)

Performance in Element is not just “app speed.” It’s a combination of client efficiency, your homeserver performance, and—if federating—other servers.

Matrix.org’s “Try Matrix” page describes Element X (the next-generation mobile client) as focused on a fast modern experience, calling out Sliding Sync for more efficient login and messaging, native OIDC, and MatrixRTC for calls.

Element also publicly markets Sliding Sync as a major improvement for joining/syncing large encrypted rooms. That’s a real pain point in Matrix clients historically, so this is one of the more concrete performance-oriented differentiators in the Element ecosystem—especially for people in big workspaces.

Open-source posture (real, not vibes)

Element’s client code is published on GitHub, and Element’s site emphasizes its open-source development and contributions.

Licensing matters for enterprises and integrators: Element has moved major components to AGPL licensing and also discusses a dual-licensing approach (including GPLv3 for Element Web/Desktop in some contexts and a commercial alternative license). This is not “open source as a sticker”—it’s a licensing model designed to force downstream modifications back upstream unless you buy a commercial license.

Known specs (VPNSpotter database, verified):

• Jurisdiction: United Kingdom
• Pricing model: Free

Element’s own “About” page also states Element is headquartered in the UK (via Element Creations Limited).

Pricing and Plans

For typical individuals, the Element apps can be used for free (especially when connecting to a Matrix homeserver you choose, including self-hosted). Element’s pricing page explicitly lists a Community tier for non-professional deployments and evaluations and describes it as “Free of charge frontend and backend.”

For professional/enterprise use, Element sells a commercial server bundle: Element Server Suite Pro (and related enterprise offerings). The pricing page does not publish a simple public price list; it describes the enterprise plan as “Priced per seat/month” and routes you to sales.

Element also offers hosted and add-on services in the broader ecosystem. For example, Element’s own blog has described EMS-era hosted/on-prem pricing in terms of monthly active users (historically presented as a per-MAU monthly price). That said, treat older blog pricing as historical context, not a guarantee of today’s exact pricing unless you confirm it on the current pricing page or contract.

Refunds: Element’s publicly accessible legal terms include subscription billing language for “Element One” (billing date alignment for monthly/annual subscriptions), but this document alone does not clearly establish a universal refund window for all Element offerings. Without an explicit refund policy statement tied to the product you’re buying, don’t assume one.

Privacy and Security Assessment

Jurisdiction: United Kingdom

Element is headquartered in the UK, and its legal documents identify Element Creations Limited as a UK company. UK jurisdiction doesn’t automatically mean “bad,” but it does mean you should assume the company can be subject to UK legal demands.

Two key points keep this grounded:

1. Element is a client and a platform; what data exists (and who controls it) depends heavily on which homeserver you use (self-hosted vs hosted by someone else). Element’s privacy policy explicitly distinguishes between data responsibilities when the Matrix server is not provided by Element.

2. In encrypted rooms, E2EE aims to ensure the server can’t read message content, but that doesn’t erase metadata realities (see below).

E2EE: strong default, but not “everything is hidden”

Element’s documentation indicates encrypted DMs are created by default under certain conditions and private room creation defaults to encryption (with an opt-out unless forced by server policy).

However, Matrix’s architecture exposes some metadata to servers by design. Element has an explicit blog post explaining that in encrypted rooms, room name, topic, avatar, and other metadata are stored on the homeserver in plaintext as state events, and why encrypting that metadata is complex.

So the “No BS” version is:

• Message contents in encrypted rooms are meant to be unreadable to the homeserver.
• Some room metadata and structural events are visible to the server.

If your threat model includes hiding who talks to whom, room names, or the existence of sensitive rooms, Element/Matrix may not satisfy you today.

Secure backup: protection vs foot-guns

Element’s own support docs say Secure Backup safeguards against losing access to encrypted messages and that if you don’t set it up, new sessions may not be able to see your messages. That’s an honest admission of how easy it is to lose encrypted history in a multi-device system.

Known incidents and vulnerability disclosures

Element and the Matrix ecosystem have had real vulnerabilities—and they have published real coordinated disclosures.

• Matrix.org disclosed CVE-2021-40823 and CVE-2021-40824, describing a critical issue affecting multiple Matrix clients including Element (Web/Desktop/Android). The post explains that exploitation requires gaining control over the recipient’s account (credentials or homeserver compromise) and that the risk is highest in encrypted rooms containing malicious servers.
• Element also published a coordinated Matrix security update in 2025 describing federation vulnerabilities and upgrade guidance (including references to CVE-2025-49090 and a Matrix spec update introducing a new room version).

This is the right pattern (disclose, patch, publish guidance). But it also reinforces that Matrix is a complex stack: client + server + federation + cryptography + multiple implementations.

Audits and crypto implementation work

Matrix’s E2EE relies on the Olm/Megolm ratchets. A relevant audit in the Matrix cryptography ecosystem is Least Authority’s audit of vodozemac, a Rust implementation of libolm, published with a public report.

Also note Element’s own product messaging: Element has stated its end-to-end encryption is now written in Rust (and Element X uses matrix-rust-sdk libraries). That aligns with broader efforts to reduce memory-safety risk from C/C++ crypto code.

Data processing (calls, push, maps)

Element’s privacy policy is unusually specific about some non-message data flows:

• For Element Call, Element processes network/usage info including participant IP addresses and usernames (Matrix ID + device ID), timestamps, and call type; it still states Element Call is end-to-end encrypted.
• The policy also discusses push notifications and notes OS providers can see certain metadata like roomID or eventID for push-related functionality, while decryption is local on the device.

Strengths and Limitations

Strengths

• Federation and self-hosting are first-class. You can run your own homeserver and still communicate with others on Matrix if federation policies permit. This is the opposite of the closed-garden model.
• E2EE is built in and defaults are pro-encryption. Encrypted DMs and private rooms default to encryption behavior described in Element’s docs, and the platform positioning is “E2EE by default.”
• Open-source code with serious upstream investment. Element publishes code, and its licensing changes indicate it treats sustainability and contributions as a strategic priority.
• Modern calling roadmap. Element Call and MatrixRTC work are clearly documented as the direction for native calling, rather than bolting everything onto third-party conferencing forever.

Limitations

• Metadata exposure is real. Element itself explains that encrypted rooms still store state metadata (like room names/topics) on the homeserver in plaintext today.
• Complexity tax. Multi-device E2EE with verification and secure backup is powerful, but it’s more work than centralized messengers; Element’s own docs warn you can lose access to history without Secure Backup.
• Enterprise pricing isn’t transparent. The current pricing page describes enterprise as per-seat/month but doesn’t provide public numbers—expect sales-led pricing if you need Pro features.
• Security history includes critical issues. Matrix.org’s disclosure confirms Element clients were affected by past E2EE vulnerabilities (patched, disclosed), which matters if you assume “E2EE means no worries.”

Who Should Use Element?

Good fit

1. Privacy-focused communities that want rooms + moderation + encryption without forcing everyone onto one company’s server. Federation and open standards matter here.

2. Organizations that want Slack/Teams-style collaboration but need data control, including the option to self-host and manage identity integrations in enterprise setups.

3. Technical users who value interoperability and open source and are willing to learn device verification, key backup, and server selection.

Not a good fit

1. Anyone who wants maximum simplicity (single app, single identity, no key backup concepts). Element can be smooth once configured, but the model is inherently more complex.

2. Threat models that require hiding room names/topics and other metadata from servers today. Element explicitly notes that room metadata is stored in plaintext as state events in encrypted rooms (at least for now).

3. Buyers who demand a simple, public enterprise price list. Element’s enterprise pricing is described structurally (per seat/month) rather than posted as fixed tiers with published numbers.