--- title: "Client-Side Encryption for Secret Sharing | LinkPilot Blog" description: "When client-side encryption matters for secret links, what guarantees it actually provides, and the trade-offs to be honest about." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "SoftwareApplication", "@id": "https://uselinkpilot.com/#software", "name": "LinkPilot", "applicationCategory": "BusinessApplication", "operatingSystem": "Web", "description": "LinkPilot is a secure link management platform for creating branded short links, tracking engagement, and sharing secrets with expiring, protected, self-destructing links.", "url": "https://uselinkpilot.com", "offers": [ { "@type": "Offer", "name": "Free", "price": "0", "priceCurrency": "USD", "url": "https://uselinkpilot.com/pricing" }, { "@type": "Offer", "name": "Pro", "price": "29", "priceCurrency": "USD", "priceSpecification": { "@type": "UnitPriceSpecification", "price": "29", "priceCurrency": "USD", "billingDuration": "P1M" }, "url": "https://uselinkpilot.com/pricing" }, { "@type": "Offer", "name": "Agency", "price": "299", "priceCurrency": "USD", "priceSpecification": { "@type": "UnitPriceSpecification", "price": "299", "priceCurrency": "USD", "billingDuration": "P1M" }, "url": "https://uselinkpilot.com/pricing" }, { "@type": "Offer", "name": "Enterprise", "priceSpecification": { "@type": "PriceSpecification", "priceCurrency": "USD" }, "url": "https://uselinkpilot.com/pricing" } ] }, { "@context": "https://schema.org", "@type": "Organization", "@id": "https://uselinkpilot.com/#organization", "name": "LinkPilot", "url": "https://uselinkpilot.com", "parentOrganization": { "@type": "Organization", "@id": "https://tetracorehq.com/#organization", "name": "TetraCore", "url": "https://tetracorehq.com/" }, "logo": { "@type": "ImageObject", "url": "https://uselinkpilot.com/logo-512.png", "width": 512, "height": 512 }, "description": "LinkPilot is a secure link management platform for creating branded short links, tracking engagement, and sharing secrets with expiring, protected, self-destructing links.", "sameAs": [ "https://x.com/uselinkpilot", "https://www.linkedin.com/company/uselinkpilot", "https://facebook.com/uselinkpilot" ] }, { "@context": "https://schema.org", "@type": "WebSite", "name": "LinkPilot", "url": "https://uselinkpilot.com", "potentialAction": { "@type": "SearchAction", "target": "https://uselinkpilot.com/blog?q={search_term_string}", "query-input": "required name=search_term_string" } }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://uselinkpilot.com" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://uselinkpilot.com/blog" }, { "@type": "ListItem", "position": 3, "name": "Client-Side Encryption for Secret Sharing", "item": "https://uselinkpilot.com/blog/client-side-encryption-for-secret-sharing" } ] }, { "@context": "https://schema.org", "@type": "BlogPosting", "@id": "https://uselinkpilot.com/blog/client-side-encryption-for-secret-sharing#article", "headline": "Client-Side Encryption for Secret Sharing", "description": "When client-side encryption matters for secret links, what guarantees it actually provides, and the trade-offs to be honest about.", "datePublished": "2026-05-26", "dateModified": "2026-07-14", "image": "https://uselinkpilot.com/logo-512.png", "author": { "@type": "Person", "name": "W. Miller", "worksFor": { "@type": "Organization", "name": "LinkPilot", "url": "https://uselinkpilot.com" } }, "publisher": { "@type": "Organization", "name": "LinkPilot", "url": "https://uselinkpilot.com", "logo": { "@type": "ImageObject", "url": "https://uselinkpilot.com/logo-512.png", "width": 512, "height": 512 } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://uselinkpilot.com/blog/client-side-encryption-for-secret-sharing" } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Does LinkPilot use client-side encryption?", "acceptedAnswer": { "@type": "Answer", "text": "LinkPilot hashes passphrases client-side with SHA-256 before transport and protects payloads with TLS in transit and encryption at rest. We do not currently implement browser-side end-to-end encryption of payloads, and we say so plainly on the Security Architecture page. If E2EE is a hard requirement today, tools like PrivateBin are a better fit." } }, { "@type": "Question", "name": "What's the practical difference between the two models?", "acceptedAnswer": { "@type": "Answer", "text": "With server-side encryption, the server can read the payload to deliver it. With client-side E2EE, the server only ever sees ciphertext. Both protect against external attackers; they differ on whether you have to trust the server operator." } }, { "@type": "Question", "name": "Is client-side encryption the same as zero-knowledge?", "acceptedAnswer": { "@type": "Answer", "text": "Vendors use 'zero-knowledge' loosely. The strict meaning is that the server never holds enough material to decrypt your data. Verify how the key is generated and transported, whether it ever appears outside the URL fragment, and whether the client code is published — not just whether the label appears on the pricing page." } }, { "@type": "Question", "name": "Does the URL fragment really stay off the server?", "acceptedAnswer": { "@type": "Answer", "text": "Yes — per RFC 3986, browsers do not include the fragment (#...) portion of a URL in HTTP requests. But the fragment still lives in the recipient's browser history, bookmarks, sync services, and anywhere someone pastes the full URL, so the key can still leak client-side." } }, { "@type": "Question", "name": "Is E2EE always worth the complexity?", "acceptedAnswer": { "@type": "Answer", "text": "No. It adds friction — key in URL fragment, no server-side preview, no content scanning, weaker admin visibility — that many teams don't need. Pick based on the threat you're actually defending against, not the label." } } ] } ] --- [![LinkPilot](/link_pilot_icon.webp)LinkPilot ](/) [Features](/features)[Tools](/tools)[Blog](/blog)[Pricing](/pricing)[FAQ](/#faq) Toggle theme [Sign In](/login)[Start free](/signup) 1. [Home](/) 2. [Blog](/blog) 3. [Security](/blog/category/security) 4. Client-Side Encryption for Secret Sharing [Security](/blog/category/security) # Client-Side Encryption for Secret Sharing When client-side encryption matters for secret links, what guarantees it actually provides, and the trade-offs to be honest about. By W. Miller · May 26, 2026 · 7 min read Client-side encryption sounds like a silver bullet for secret sharing. It isn't — it's a specific trade-off that protects against a specific threat, and it charges you real capabilities in exchange. This guide walks through what browser-side encryption actually guarantees, where it quietly breaks down, how it compares to the server-side model LinkPilot uses, and how to choose between the two without marketing fog. ## What client-side encryption actually does In a client-side encrypted (often called end-to-end encrypted, or E2EE) secret tool, the workflow looks like this: 1. The browser generates a symmetric key — typically a 256-bit AES-GCM key via the Web Crypto [API](/glossary#api "Glossary: api") (`crypto.subtle.generateKey`). 2. The payload is encrypted in the browser with that key. 3. Only the ciphertext is sent to the server, which stores it under a random [slug](/glossary#slug "Glossary: slug"). 4. The key is appended to the URL as a [fragment](/glossary#fragment "Glossary: fragment") (`#key=…`). Per RFC 3986, browsers never send the fragment portion of a URL in [HTTP](/glossary#http "Glossary: http") requests, so the key does not cross the wire to the server. 5. The recipient's browser reads the fragment, fetches the ciphertext, and decrypts locally. The server only ever sees ciphertext. Even a malicious server operator can't read the secret — provided every other link in the chain holds. ### Anatomy of an E2EE secret URL ``` https://example.com/s/x7Kd93hF2a#key=4fT9wLm2...Qz1 └──────── sent to the server ───┘└── browser-only ──┘ ``` Everything before the `#` travels in the HTTP request and can appear in server logs. The fragment is processed only by the recipient's browser. That one character is doing all of the security work — which is elegant, and also the root of most of the failure modes below. ## What it doesn't do - **It doesn't protect against malicious JavaScript.** The encryption code runs in the browser, and the browser got that code from the server. If the server delivers compromised JS — because the operator turned malicious, was compelled, or was hacked — the secret can be exfiltrated before or after encryption. This is the fundamental limit of browser-based E2EE. - **It doesn't protect against browser extensions.** Extensions with page access see the plaintext after decryption, and can read the URL fragment directly. - **It doesn't make URL leakage harmless.** The fragment is part of the URL. If the recipient pastes the full URL into chat, forwards the email, or has browser history sync enabled, the key travels with it. An E2EE link with a leaked URL is a fully readable secret. - **It doesn't audit, scan, or preview.** Because the server can't read the payload, it can't help with content filtering, malware scanning, data-loss prevention, or meaningful admin visibility. ### The code-delivery problem, spelled out The subtle point worth sitting with: browser E2EE means trusting the same server you supposedly don't trust to deliver honest JavaScript on every single page load. A native app is installed once, signed, and versioned; a web page is re-fetched every visit. Subresource integrity and published source code narrow the gap but don't close it. So the honest reading of "we can't read your secrets" is: "we can't read your secrets _passively_." Turning a passive capability into an active attack that ships modified code is still a meaningful upgrade — active attacks are riskier, targeted, and potentially detectable — but it is not the same as "impossible," and vendors who imply otherwise are overselling. ## Server-side encryption with hashed passphrases The pattern LinkPilot uses, documented in detail on the [Security Architecture](/security-architecture) page: - **[TLS](/glossary#ssl "Glossary: tls") in transit** for all traffic between the recipient, the edge, and the database. - **Encryption at rest** — payloads live in a dedicated `secret_links` table, logically separated from analytics data, on a managed Postgres instance with disk-level encryption. - **Passphrases hashed client-side** with SHA-256 before transport, then compared by hash on the server. The raw passphrase never reaches the database or logs. - **Destructive burn** — when a secret is burned, expires, or is revoked, the stored payload is overwritten with `[REDACTED]` and later reveal attempts get HTTP 410. There is no restore. - **Brute-force resistance** — passphrase attempts are rate-limited to 5 per IP per minute per secret, and every failed attempt lands in the audit log with a hashed IP. The server _can_ read an active secret's payload — that's what lets it enforce atomic [burn-after-read](/glossary#burn-after-read "Glossary: burn-after-read"), feed the audit timeline, and serve a clean reveal flow. It's also exactly the property E2EE removes. Neither is free. ## Trade-off summary Concern Client-side E2EE Server-side + hashed passphrase Malicious server operator (passive) Mitigated Trust required Malicious server operator (serves bad JS) Not mitigated Not mitigated Compromised JS / supply chain Not mitigated Not mitigated External attacker with a DB dump Mitigated (ciphertext only) Mitigated (encryption at rest; burned payloads already redacted) Leaked URL, no passphrase Secret fully readable — key is in the fragment Secret readable until burn/expiry; passphrase closes this Server-side audit log Access events only Full lifecycle: created, viewed, failed passphrase, burned, expired, revoked Recipient UX Slightly worse Native Admin / team visibility None Configurable Neither model is "more secure" in the abstract. They defend different threats with different costs. ## Matching the model to the threat: three scenarios **1\. Sending a contractor a database password.** Threat: the secret lingering in email or chat, or a stray forward. Both models handle this well; the deciding factors are usability, expiry controls, and the [audit trail](/glossary#link-history "Glossary: audit trail"). Server-side with a short expiry, burn-after-read, and an out-of-band passphrase is the pragmatic pick. **2\. A journalist receiving material from a source.** Threat model includes the platform operator being compelled to disclose. Here the operator _is_ part of the threat model, so E2EE (or better, purpose- built tools like SecureDrop) is the right call, accepting the usability cost. **3\. An engineering team doing routine credential hand-offs.** Threat: sprawl, forgotten links, no record of who saw what. The features that matter — audit timelines, revocation, team workspaces, expiry policy — all live server-side. E2EE would trade away the controls this team actually needs. ## How to choose Pick **client-side E2EE** when: - You don't trust the server operator — including yourself running on cloud infrastructure you can't fully verify. - Regulatory or contractual rules require that the provider be technically unable to read the content. - The trade-off of zero server-side features is acceptable. Pick **server-side encryption with hashed passphrases** when: - You need team workspaces, audit logs, or admin visibility. - You want the server to defend against link unfurlers, passphrase brute-force, and abuse. - Your threat model is "external attacker" and "secret left behind in chat," not "compromised operator." ## When not to use either Some secrets shouldn't travel through _any_ sharing link. Long-lived root credentials, production signing keys, and bulk data exports belong in a secrets manager or KMS with access control, not in a URL of any kind. And if the recipient needs the value repeatedly, a password manager vault item beats re-sending links — one-time delivery is for hand-offs, not storage. ## Honest positioning We say this on the [Security Architecture](/security-architecture) page too: LinkPilot does not currently claim end-to-end encryption, and we'd rather state that plainly than ship a misleading label. Don't pick a tool based on which one claims more. Pick based on what you're actually defending against — and verify that the claims on the tin match the architecture underneath. ## Related reading - [How one-time secret links work](/blog/how-one-time-secret-links-work) - [LinkPilot vs PrivateBin](/linkpilot-vs-privatebin) - [Secret links vs password managers](/blog/secret-links-vs-password-managers) - [Why URLs leak sensitive information](/blog/why-urls-leak-sensitive-information) ## Frequently asked questions ### Does LinkPilot use client-side encryption? ### What's the practical difference between the two models? ### Is client-side encryption the same as zero-knowledge? ### Does the URL fragment really stay off the server? ### Is E2EE always worth the complexity? ## Run smarter links with LinkPilot Tracking, UTMs, QR codes, AI insights, and white-label reporting — in one workspace. Free to start. [Create your free account](/signup) ## Read next [ Security ### OneTimeSecret vs Privnote vs Password Pusher: Which Should You Use? A three-way comparison of the most popular secret-sharing tools — encryption, expiry, revocation, self-hosting, and where each one genuinely wins. ](/blog/onetimesecret-vs-privnote-vs-password-pusher)[ Security ### Is Privnote Safe? An Honest Security Assessment (2026) Privnote's core mechanism works, but clone-site phishing, closed source code, and zero auditability are real risks. Here's a fair assessment and safer setups. ](/blog/is-privnote-safe)[ Security ### How to Send a Password Securely (Without Leaving It in Chat Forever) The safest way to send a password is a one-time encrypted link that self-destructs after viewing. Here's every method ranked, with the trade-offs spelled out. ](/blog/how-to-send-a-password-securely) On this page - [What client-side encryption actually does](#what-client-side-encryption-actually-does) - [Anatomy of an E2EE secret URL](#anatomy-of-an-e2ee-secret-url) - [What it doesn't do](#what-it-doesnt-do) - [The code-delivery problem, spelled out](#the-code-delivery-problem-spelled-out) - [Server-side encryption with hashed passphrases](#server-side-encryption-with-hashed-passphrases) - [Trade-off summary](#trade-off-summary) - [Matching the model to the threat: three scenarios](#matching-the-model-to-the-threat-three-scenarios) - [How to choose](#how-to-choose) - [When not to use either](#when-not-to-use-either) - [Honest positioning](#honest-positioning) - [Related reading](#related-reading) ![LinkPilot](/assets/link_pilot_icon-Bslvq5xV.webp)LinkPilot [About](/about)[Features](/features)[Pricing](/pricing)[For Agencies](/url-shortener-for-agencies)[Tools](/tools)[Blog](/blog)[Glossary](/glossary)[Compare](/compare)[Privacy](/privacy)[Security](/security-architecture)[Transparency](/transparency)[Terms](/terms)[GDPR](/gdpr) [](https://x.com/uselinkpilot)[](https://www.linkedin.com/company/uselinkpilot)[](https://facebook.com/uselinkpilot) © 2026 TetraCore. All rights reserved. · LinkPilot is [a TetraCore product](https://tetracorehq.com/)