Fix Element Web “Failed to Decrypt Event” E2EE Errors

Illustrative example: Maya can read new encrypted messages on her phone, but after signing in to Element Web on a new laptop, several older events show “Unable to decrypt.” This hypothetical case helps separate a missing key on the new browser from a message key that was never shared with her account. The distinction matters because the first problem may be fixable by verifying the browser session and restoring key backup; the second may require another participant or device that actually has the key.

What does “Failed to decrypt event” usually mean?

Element received an encrypted Matrix event but the current session could not decrypt it with the keys available to that session. The text is not stored by the homeserver in a form that Element can simply reveal by reloading. In end-to-end encryption, the needed room key is held by participating devices or in encrypted key backup. Element says key storage supports decrypting history on new devices, and a recovery key can unlock that backup. Element’s encryption and key-storage FAQ

The message can fail for different reasons: the current browser is a new or unverified session without access to backup keys; a key was not delivered to this device; a specific event predates when a device or user could receive the room key; or local browser data or a client issue is interfering. The visible error alone does not identify which cause applies. Start by checking whether the failure affects one event, a range of old history, or all encrypted rooms.

What should you check before changing encryption settings?

In Maya’s example, her phone still opens the conversation. That is valuable: it may be a verified session holding keys that are missing from the new web session. Keep that phone signed in and avoid resetting the cryptographic identity or deleting the key backup while investigating.

• Compare devices. Check whether the same event decrypts on another signed-in Element device. If it does, the key is likely available somewhere in the account’s trusted device/key setup, even though this browser lacks it.
• Check the pattern. If only one old event fails, its session key may be missing or may never have been shared with this device. If many earlier messages fail only on a newly added browser, device verification or key backup is a stronger lead.
• Confirm you are in the right account and homeserver. A different account, server, or browser profile may have a separate device identity and key history.
• Preserve access. Do not sign out of the only device that can decrypt the room. Do not clear browser site data before confirming your recovery key and any important message-key exports.

These checks are non-destructive. They help Maya avoid treating a one-event key gap like a broken account backup.

How do you restore access on a new Element Web session?

Element treats each login session as a separate device, even if two sessions use the same physical computer. A new browser session may need verification before it can access backed-up encryption keys. Element’s current Web instructions place session verification under the profile menu, then All Settings and Sessions. From Current session, select Verify session. The available verification choices can include another device or a recovery key. Menu names can vary between releases and hosted deployments, so follow the labels shown in your installed version. Element’s device-verification guide

1. Keep the working phone or desktop session open. In Element Web, open your profile menu and go to All Settings > Sessions.
2. Under Current session, choose Verify session.
3. If offered, choose Verify with another device. Accept the request on the device you recognize, then compare the verification emoji or numbers on both screens. Confirm only when they match.
4. If you cannot use another verified device, choose the recovery-key option and enter the key you previously saved. The recovery key is not your account password.
5. After verification, leave Element Web open and allow it to retrieve available backup keys. Recheck the affected events.

For Maya, a successful verification and key restore may make backed-up history readable in the browser. It will not recover keys that were never included in the backup or never shared with her device. Element’s documentation notes that verifying a new login connects it to cross-signing and secret storage so it can access backed-up message keys. Element’s guide to verifying a new login

What if you have a recovery key but are unsure it works?

Do not test a recovery key by resetting the backup. Element recommends verifying that a saved key works by using it during the device-verification process in Element Web. If you still have a signed-in, verified device, Element’s current guide also explains how to check the recovery-key status in All Settings > Encryption and obtain or change a key. Save any replacement securely and ensure the new key has been accepted before relying on it. Element’s recovery-key checklist

A recovery key protects access to encrypted key storage; it does not decrypt content by itself if the corresponding room key was never backed up. If you are still signed in on a device that can decrypt the room, keep it available while you follow the official export or backup guidance for your Element version.

Why does just one event—or only very old history—still fail?

Matrix encrypted room messages use group sessions, and devices need the relevant session key. The Matrix implementation guide describes room keys being delivered to specific devices and explains that clients can request missing keys from other clients. Key sharing is governed by device trust and sharing rules; a client should not automatically send keys to every unverified requester. Matrix’s end-to-end encryption implementation guide

There are also legitimate timing cases. For example, a device that joined after an earlier encrypted session began may not have been given that session’s key. Matrix’s guide notes that a newly added user generally receives the current session state for future messages; earlier messages require history sharing where supported and permitted. In Maya’s hypothetical case, if her phone decrypts the old event but the verified browser still does not after backup restore, the phone may have the only copy of that room key. If no device or backup has it, it may not be recoverable.

If Element offers a key-request prompt, use it only after checking which device is requesting access and verifying the session when possible. Ask the sender or room administrator whether a trusted device still has the key. Do not approve an unfamiliar session merely to clear the error.

What should you avoid doing?

• Do not reset your digital identity as a first troubleshooting step. Element warns that resetting without an active session can destroy access to historical encrypted messages. Resetting identity is a last resort when no recovery key or verified device remains, not a routine repair.
• Do not delete or reset key backup before preserving keys. Element’s backup-reset instructions advise restoring keys and exporting them before resetting server-side backup. Some clients may not be able to export the full backup, so check version-specific instructions first. Element’s key-backup reset procedure
• Do not share your recovery key in a chat, support ticket, or screenshot. It can unlock your encrypted key backup. Enter it only into the expected Element verification flow.
• Do not assume clearing cache repairs missing cryptographic keys. A reload may address a temporary display issue, but it cannot recreate a key that the session never received.

Element’s support documentation states that resetting cross-signing without an active session can remove access to historical encrypted messages. That is why Maya keeps her working phone signed in while she verifies the browser. Element’s warning about resetting cross-signing

When should you contact the homeserver administrator or Element support?

Contact the administrator if key backup is unavailable, the backup reports an error, multiple users see decryption failures after a server migration, or the issue began after a homeserver restore. Element’s server backup documentation notes that losing the Synapse database can cause encrypted events to appear as “Unable to decrypt”; this is a server-recovery issue rather than a browser setting. Element Server Suite backup and restore documentation

When reporting the problem, include the Element Web version, browser, homeserver, whether another verified device decrypts the same event, and whether the affected messages are recent or historical. Never send message contents or recovery keys. If only one event remains unavailable and no device has its key, explain that clearly: support may diagnose delivery or server problems, but cannot derive an end-to-end encryption key that no trusted device or backup retains.

How can you tell whether the fix worked?

Return to the same room and event that failed. Confirm that the browser session is shown as verified, that key backup is connected, and that more than one affected historical event opens if the problem involved a range. Then check a recent encrypted message. If recent messages work but a single older event remains unavailable, the browser setup may be fixed while that event’s specific key is still missing.

For Maya, the useful outcome is not merely that the error banner disappears. It is that Element Web can decrypt the history she expects, her new session is verified, and her recovery key is safely stored. If those checks pass except for an event unavailable on every device, preserve the working sessions and ask the sender or administrator whether that event’s room key exists elsewhere.