Send files

Security is not just a feature. It's our mission.

Every design decision in Wormhole begins with the safety and privacy of your data in mind. We can't read your files, and no one else can either. Privacy isn’t an optional mode — it’s just the way that Wormhole works.

Your files are end-to-end encrypted.

Your Wormhole files are end-to-end encrypted, and only you hold the keys to decrypt them. We can’t see your Wormhole files, so we can’t use them, share them, or sell them.

No ads. No trackers. No kidding.

There are no ads and no creepy tracking in Wormhole. So focus on sharing the files that matter with the people who matter to you.

We use state-of-the-art security.

Your Wormhole files are end-to-end encrypted to keep them safe at rest and in transit. Our security starts with AES 128-bit encryption, and we use multiple techniques to make sure only you have access to your information. We're continuously working to make sure our code is rock solid.

Security Design

Wormhole uses state-of-the-art security and end-to-end encryption to protect your files. Your files are always end-to-end encrypted, so they can never be shared or viewed by anyone but you and the intended recipients.

Wormhole encrypts all files with 128-bit AES-GCM encryption before they leave the browser.

Key management

The secret key used for end-to-end encryption is never shared with our servers. It is sent directly to your intended recipient when you send them the "share link". The secret key is added to the URI fragment which is never sent to the server.

When an agent (such as a web browser) requests a web resource from a web server, the agent sends the URI to the server, but does not send the fragment.

The link format looks like this:


Here's an example link:


Streaming Encryption and Decryption

For streaming encryption and decryption, we use Encrypted Content-Encoding for HTTP.

This standard provides authenticated encryption to ensure that your files can't be seen or modified by an attacker once they leave your browser.

Web Crypto API

We use the browser's built in cryptography primitives via the Web Crypto API to encrypt files in the browser before they are sent to the recipient.

File transport

End-to-end encrypted files may be:

  1. Sent directly to the recipient via a peer-to-peer WebRTC connection
  2. Uploaded to our servers (assuming they are within the file size limit)

A fully peer-to-peer transfer is preferred, since it improves speed and privacy. The server copy helps to ensure files continue to be available even after the sender closes their browser. All files are end-to-end encrypted before they are uploaded or sent peer-to-peer.

Encryption at rest

In addition to Wormhole's end-to-end encryption, your files are protected by an additional layer of encryption on our servers.

Transport Layer Security (TLS)

TLS (formerly known as SSL) is the industry-standard encryption protocol used to encrypt communications between your browser and our servers. It ensures that the Wormhole webpage code is not modified by attackers, and provides an additional layer of protection on top of the client-side end-to-end encryption to ensure data uploads and downloads are private.

We support TLS 1.3 for modern devices and TLS 1.2 for all remaining devices. Deprecated versions of TLS and SSL are not used.

Qualys SSL Labs rates our TLS implementation an A+. See report.

Certificate Transparency Logs

We monitor the Certificate Transparency logs for certificate misissuance.

DNS Certification Authority Authorization (CAA) Policy

A Certification Authority Authorization (CAA) policy allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain.

By publishing a CAA record, we reduce the risk of unintended or malicious certificate misissuance.

Domain Name System Security Extensions (DNSSEC)

DNSSEC is a set of extensions to DNS which provide to DNS clients (resolvers) cryptographic authentication of DNS data, authenticated denial of existence, and data integrity.

We deploy DNSSEC to protect DNS records for wormhole.app.

Datagram Transport Layer Security (DTLS)

DTLS is the standard encrypton protocol used to encrypt WebRTC peer-to-peer communications between browsers. It provides an additional layer of protection on top of our own encryption to keep peer-to-peer transfers on Wormhole private.

Web security

Wormhole is configured with state-of-the-art security options to lock down the site as much as possible.

Mozilla Observatory rates our site configuration an A+.

Here are a few of the security features we deploy.


Wormhole uses this header to ensure that your browser always communicates with our servers using the TLS protocol.

We additionally include wormhole.app in all major browser's HTTP Strict Transport Security (HSTS) preload lists. In the case of .app domains, the entire TLD is automatically included in the HSTS preload list.


Wormhole uses this header to prevent other origins from accessing data on wormhole.app. This is a mitigation for side-channel hardware vulnerabilities such as Meltdown and Spectre.


Wormhole uses this header to enable cross-origin isolation. Cross-origin isolation ensures that supported browsers always load Wormhole in a separate renderer process, which protects against side-channel hardware vulnerabilities such as Meltdown and Spectre.


Wormhole uses this header to disable some web browser features that we don't need, like camera and microphone access.


Wormhole uses Content Security Policy to prevent the site from being tricked into accessing resources (such as scripts, webpages, etc.) that could be used in Cross Site Sripting attacks.

We have a very strict policy that blocks execution of inline JavaScript, JavaScript's eval() function, browser plug-ins, active and passive HTTP content, clickjacking attacks, <base> tag attacks, <form> submissions to exfiltrate data, and more.


We plan to publish a more thorough explanation of the protocol in the coming weeks. For now, here's a high-level overview.


  1. A new secret key and nonce are generated with crypto.getRandomValues
  2. The secret key and nonce are used to derive more keys via HKDF SHA-256
    • a series of encryption keys for the file, via ECE (AES-GCM)
    • an encryption key for the file metadata (AES-GCM)
    • a reader authorization token for authenticating download requests (HMAC SHA-256)
  3. The file and metadata are encrypted with their corresponding keys
  4. The encrypted data, nonce, and reader authorization token are uploaded to the server
  5. An owner authorization token and the share url are returned by the server and stored in memory
  6. The secret key is appended to the share url as a #fragment and presented to the UI


  1. The browser loads the share url page, which includes the nonce
  2. The browser imports the secret key from the url fragment using the nonce
  3. The same 2 keys and reader authorization token as above are derived
  4. The browser uses the nonce to request the metadata from the server
  5. The encrypted metadata is decrypted and presented on the page
  6. The browser uses the authorization token again to download the encrypted file
  7. The browser downloads and decrypts the file
  8. The file prompts the save dialog or automatically saves depending on the browser settings

Source code

  • wormhole-crypto - Streaming encryption implementation, based on Encrypted Content-Encoding for HTTP (RFC 8188)

How can I report a security vulnerability?

If you've found a security vulnerability in Wormhole, please report it using our Responsible Disclosure Process.

    • Why We Built This
    • FAQ
    • Roadmap
    • Help Us Learn
    • Security
    • Legal
    • Twitter
    • Discord