How browser encryption protects shared text
Browser-side encryption changes what a message-delivery service needs to receive. Instead of sending readable text and asking the server to protect it, the browser encrypts first and uploads ciphertext.
By SecretLink Editorial Team · Published August 23, 2026 · Updated August 23, 2026
Encrypt before upload
In a conventional web form, text is protected in transit by HTTPS but arrives as plaintext at the application server. Server operators and server-side software may be able to read it before it is encrypted for storage.
With SecretLink, the browser creates a random key and encrypts the text using AES-GCM through the Web Crypto API before upload. The server receives ciphertext, an initialization vector, and delivery settings such as expiration and one-time status. It does not need the plaintext to store and deliver the encrypted payload.
Why the key is placed after the # symbol
A SecretLink URL has a fragment: the portion after #. Under normal browser behavior, fragments are handled by the browser and are not included in HTTP requests to the web server. SecretLink uses that property to deliver the decryption key to the recipient's browser without placing it in the server's message record or ordinary request logs.
The complete URL still contains everything needed to reach the ciphertext and, subject to any access password, decrypt it. That makes the full link a secret. Copying it into a public ticket, analytics tool, shared bookmark service, or untrusted app can disclose the key even though the SecretLink server did not receive the fragment.
What AES-GCM contributes
AES-GCM provides confidentiality and authentication. Confidentiality hides the original text without the key. Authentication lets the browser detect if the ciphertext or associated encrypted data was altered; tampered content should fail to decrypt rather than produce a silently modified message.
Security depends on correct key generation, unique initialization values, sound implementation, and trustworthy browser code. Naming a strong algorithm is not enough by itself. SecretLink relies on modern browser cryptography rather than implementing the AES primitive from scratch.
Example: sharing an API key
A developer needs to hand a short-lived API key to a teammate. They create a restricted key with only the required scope, place only that key in a SecretLink, set a one-hour expiration, and send the link in a private channel. They provide a separate access password during a call.
The teammate opens the link in a trusted browser and stores the key in the team's approved secret manager. After the task, the developer revokes the API key. Browser encryption reduced exposure during delivery; limited scope, secure storage, and revocation controlled the risk after delivery.
What remains visible
Encryption does not hide every piece of metadata. A service may still need to process message identifiers, creation and expiration times, one-time status, view counts, account information, and network data required to operate and defend the service. The size of ciphertext may also reveal an approximate range for message length.
HTTPS remains necessary even when content is encrypted in the browser. It protects the application code and request metadata in transit and helps prevent network attackers from replacing the page with code that steals plaintext or keys.
The endpoint is still part of the trust boundary
Browser encryption cannot protect text from a compromised sender or recipient device. Keyloggers, malicious extensions, clipboard managers, screenshots, browser developer tools, or a person with access to an unlocked device may capture plaintext before encryption or after decryption.
Recipients should open sensitive links on a device they trust, keep browsers and operating systems updated, review extensions, and avoid shared computers. For high-impact secrets, use purpose-built organizational controls, hardware-backed authentication, and formal key-management procedures.
- Protected: readable message content in SecretLink's stored payload.
- Protected: detection of ciphertext changes during decryption.
- Not hidden: operational metadata needed to deliver and secure the service.
- Not protected: plaintext on a compromised sender or recipient device.
- Not prevented: copying, screenshots, or disclosure of the complete URL.
Related guidance
When an encrypted delivery link is appropriate, create a free SecretLink account.