Zero-Knowledge by Design, Not by Policy
Most URL shorteners treat privacy as an afterthought — a checkbox buried in a settings page, if it exists at all. We built PVTLNK the opposite way: privacy is the architecture, not a feature bolted onto one.
Why zero-knowledge, and not just “we promise not to look”
Every other shortener asks you to trust a promise. We’d rather you not have to. When you create a link with PVTLNK, the destination URL is encrypted in your browser with AES-256-GCM before it ever touches our servers. The decryption key travels only in the URL fragment — the part after # — which browsers never transmit to any server, ours included.
That’s not a policy. It’s math. Even if we wanted to read your links, we structurally can’t.
What “zero-knowledge” actually covers
The phrase gets used loosely across the industry, so we want to be specific about what it means here:
- We store ciphertext, not URLs. Our database has no column that could leak a destination even in a breach.
- Authentication doesn’t require identity. Your username and password never leave your device — we verify a cryptographic commitment, not a password hash tied to who you are. No email required, ever.
- IP addresses are hashed, not logged. Aggregate analytics still work — geography, device type, referrer counts — but nothing traces back to an individual visitor.
- Links can self-destruct. Set an expiration and the link simply stops resolving. There’s no lingering record for anyone to subpoena later.
None of this is unusual cryptography. Commitment schemes, AES-GCM, and PBKDF2 are well-understood, widely audited primitives. What’s unusual is applying them to something as mundane as a link shortener, where the industry default has been “trust us” for two decades.
Verify it yourself
We don’t ask you to take our word for it. Open your browser’s Network tab on the homepage playground and watch the actual request — there’s no url field in the payload we send. Just ciphertext, and nothing else.
POST /api/links
{
"ciphertext": "U2FsdGVkX1+8f3n2q7...",
// no "url" field — we never receive one
}
You can inspect this on every plan, including the free tier, with no account required. If a privacy claim can’t survive being checked, it isn’t a privacy claim — it’s marketing copy.
Who this actually matters for
Encryption sounds like it’s for edge cases until you think through who’s linking to things and why. A journalist sharing a source document. A healthcare worker sending a patient portal link that shouldn’t sit in a marketing analytics dashboard. A business executive circulating board materials who doesn’t want click data leaking into a growth team’s spreadsheet. None of these are exotic threat models — they’re just people who’d rather their tools not become a liability later.
Traditional shorteners weren’t built with any of this in mind. They were built to sell click data. Ours wasn’t, because it structurally can’t be sold — we don’t have it to sell.
What’s next
This is the first in a series where we’ll go deeper into the pieces that make this work: how commitment-based authentication replaces passwords without replacing security, what our Encryption Architecture Guide covers that this post doesn’t, and where we’re taking the product from here. If you want the full technical breakdown now rather than waiting for the series, it’s already written up in our Privacy & Security Whitepaper.