Security & Privacy

No accounts, no logins

encrypt.click has no user accounts, logins, or profiles. You do not need to register or provide personal information to use the tools.

Browser-side tools

The privacy tools, such as AES words, Time capsule, Steganography, Photo cipher and Spectral cipher, run in your browser using Web Crypto and other browser APIs. Their inputs are not uploaded to encrypt.click for processing.

When a tool requests public data at your direction, such as drand randomness for Time Capsule through our same-origin proxy, the request does not include your plaintext secrets or passwords.

Encrypted message and file sharing

Encrypt & share runs AES-GCM in your browser before anything is uploaded. The password stays on your device unless you copy or send it yourself.

Automatic upload prefers first-party ciphertext storage (this site's /upload). That path is limited to about 90 MB and a monthly budget, and availability is guaranteed for about 24 hours. If it is full or unavailable, you are asked first; if you agree, your browser posts ciphertext only to encrypt.click's upload API, which relays it server-side to temporary Send-compatible hosts (files up to 50 MB). Those hosts should see ciphertext and server egress - not a direct browser upload of plaintext.

Recipients open links on encrypt.click (often /u). Encrypted material may sit in the URL fragment (not sent to our servers on normal page loads) or point at uploaded ciphertext. Optional PNG wrapping can hide the share link in an image for offline handoff.

Uploads are free, so automated or unusually heavy use is checked. Normal uploads go through without anything extra; when an upload looks automated or a device has uploaded a lot, the browser first has to solve a short proof-of-work puzzle. It runs on your device and involves no third party. Each further puzzle within the hour takes twice as long, and a solved one lets that device keep uploading for an hour, within the same hard daily limits.

Encrypted chat, calls, whiteboard, and files

Chat messages, typing indicators, and call signaling are encrypted in the browser (AES-GCM) before they reach the relay. The relay forwards ciphertext and does not store chat message history, except for saved rooms, where it keeps the encrypted messages (at most 1000 per room, in the European Union) until a member deletes the room or it has gone unvisited for 90 days. In rooms without server history, messages also have forward secrecy: each member's sending key moves on with every message and reaches the others only under keys from short-lived key pairs that are never stored, so recorded traffic stays closed even to someone who learns the password later.

Live calls use WebRTC with a TURN-only ICE policy so peer IP addresses are not exchanged directly. Besides DTLS-SRTP, every audio and video frame is end-to-end encrypted in the browser with AES-256-GCM (SFrame-style insertable streams, VP8 or VP9 for video). Each sender's media key is random, travels only inside the encrypted and signed room channel, is sealed again for each recipient with an ephemeral ECDH P-256 key, and is replaced whenever a participant leaves. Because media keys never pass through the DTLS handshake, recording call traffic now and breaking that handshake later, for example with a quantum computer, does not expose the media to anyone who lacks the room secret. Browsers without frame encryption cannot join calls. TURN credentials are fetched from encrypt.click (/api/turn).

Chat file attachments are encrypted in the browser before upload, the same way as in Encrypt & share. They go to our own storage and are deleted after 24 hours, even in saved rooms. When our storage is unavailable, the encrypted file goes to a public Send instance in the EU instead, where it can stay for up to 7 days.

New rooms always need a password of at least 16 characters that passes a strength check, and they can only be created through the create form. The password is never part of the link, so share it separately.

Whiteboard sessions use the same realtime infrastructure for collaborative strokes and state. Treat room access like chat: use a strong password for anything sensitive.

Saved rooms use a random key carried in the link fragment, which never reaches the server. In every room, each message is signed in the browser with a per-room key, so other members can tell when a name turns up under a different key, and the message mode is bound into the room key, so the server cannot change it. Saved rooms add an ML-DSA-44 signature to every message and chain each author's stored messages, so browsers notice when the server leaves out, reorders or holds back messages.

Link shortening

After encryption, your browser sends the share link to /api/shorten on encrypt.click, which shortens it with our own service at l.encrypt.click. No third-party shorteners are used. If shortening fails, you get the full link instead.

The short link stores the full link including the encrypted payload, but never the password. Anyone with the short link still needs the password, so use the generated passphrase or another strong password.

The short link is created automatically, so the encrypted payload of every share is stored on l.encrypt.click, whichever link you end up sharing. The full link itself carries the payload in the URL fragment, which the recipient's browser never sends to a server.

Cookies and browser storage

The site sets one functional cookie, ec-lang, only after you pick a language in the menu. It holds the two-letter language code, nothing else, for one year, and is not used for tracking. The first visit without it is served in your browser language. Your browser may use localStorage for the theme and, where chat history is kept, encrypted messages, in saved rooms also how far each member's history has been checked. Session storage may briefly hold a room password while you join, and keeps a room key that arrived in a link for as long as that tab is open, so the key can leave the address bar. IndexedDB holds the signing key your browser creates for each chat room and whiteboard and, for saved rooms, the seed of the post-quantum signing key, sealed under a key derived from the room link; the private keys never leave the device.

Cloudflare (hosting) may set cookies for security and abuse prevention depending on traffic and browser settings, under Cloudflare's own policies.

Network and transport security

• All traffic is served over HTTPS with modern TLS.
• HTTP Strict Transport Security (HSTS) is enabled with includeSubDomains and preload.
• Content Security Policy (CSP) restricts scripts, styles, fonts, and connections; inline script hashes are used instead of broad unsafe-inline for scripts.
• Framing is disabled via frame-ancestors 'none' and X-Frame-Options: DENY.
• The deployment check compares freshly fetched assets and the build manifest from this server. It cannot prove the authenticity of the code running in your browser or protect against a compromised host.

Third-party infrastructure

The site runs on Cloudflare Workers. Real-time chat and the whiteboard are relayed by Durable Objects in the same Worker (PartyServer). Calls may be relayed through Cloudflare TURN or another configured TURN provider. Temporary ciphertext hosts, including Send-compatible instances, may receive encrypted blobs when first-party upload is unavailable.

encrypt.click does not maintain a database of your tool inputs. API abuse controls use a salted hash of the IP address held in memory for about 60 seconds. Cloudflare may also apply bot detection or challenges under its own policies.

Responsible disclosure

If you believe you found a security or privacy issue in encrypt.click, email mail@encrypt.click. Include enough detail to reproduce the issue and avoid testing that could impact other users.

Non-legal summary

This page is a human-readable summary of how encrypt.click is designed to handle data. It is not a contract or a complete set of legal terms. Perfect security cannot be guaranteed; you use the tools at your own risk.