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

Developer and privacy tools, including hashing, key generation, encoding, and other local utilities, 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 (upload.encrypt.click). That path is limited (about 50 MB) and availability is guaranteed for about 24 hours. If it fails, your browser posts ciphertext only to encrypt.click's upload API, which may relay server-side to temporary Send-compatible hosts. 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.

Encrypted chat, calls, whiteboard, and files

Chat messages, typing indicators, and call signaling are encrypted in the browser (AES-GCM) before they reach the PartyKit relay. The relay forwards ciphertext and does not store chat message history.

Live calls use WebRTC with a TURN-only ICE policy so peer IP addresses are not exchanged directly. Media is protected by DTLS-SRTP between participants; TURN only relays encrypted packets. TURN credentials are fetched from encrypt.click (/api/turn).

Chat file attachments are encrypted client-side before upload, using the same ciphertext-first approach as Encrypt & share (first-party storage when available, otherwise server-side relay of ciphertext only).

If you skip a room password, the encryption key is derived from the room name alone. Anyone who can guess that name can join and decrypt. Relays can still observe presence and timing metadata even when payloads are encrypted.

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

Optional URL shortening

When a share link is shortened, your browser calls /api/shorten on encrypt.click. The backend then sends a server-side request to the selected shortening service.

The shortening service receives the full URL. For encrypted share links, that URL may include encrypted payload metadata. For maximum privacy, avoid third-party shortening services for sensitive links.

A short link you share may still use an encrypt.click domain. When someone opens it, encrypt.click may resolve the destination server-side and redirect to an encrypt.click URL. The shortening service sees infrastructure requests rather than a direct request from the visitor's browser, but it may still log that a particular encrypted link was resolved.

Cookies and browser storage

The site does not set tracking or analytics cookies and does not use third-party trackers or advertising pixels. Your browser may use localStorage for preferences such as theme and language and, when local chat history is enabled, encrypted message envelopes on your device. Session storage may briefly hold a room password while you join.

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.
• A client-side deployment integrity check compares loaded build assets to a published manifest and, when reachable, to the latest GitHub main commit.

Third-party infrastructure

The site is hosted on Cloudflare Pages. Real-time chat and the whiteboard use PartyKit. 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 [email protected]. 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.