Introducing Filarr Sharing: End-to-End Encrypted Files, With or Without an Account

Q: What can the share owner see (audit log)?

Authenticated shares show an audit log. On the /shares page in the desktop app, expand "History" on any active share to see who downloaded it.

Q: What are the plan limits?

Q: How is this different from Proton Drive or Tresorit sharing?

Proton Drive offers similar E2EE sharing but requires the recipient to interact with Proton's web app. Their key model is different — they use Proton's identity infrastructure.

Q: How do I start?

If you have Filarr installed: update to v2.10.0+ (Settings → Check for updates). Right-click any file in your vault → "Share via link". Configure options, copy the URL, send through your preferred channel.

Quick Answer. Filarr now lets you share any file from your vault as a link. The decryption key lives in the URL fragment (the part after #) which browsers never send to the server. Filarr's servers literally cannot decrypt your file — they only see opaque encrypted bytes. There's also Filarr Send at filarr.com/send for sharing without an account: same encryption guarantees, no signup required.

Two weeks ago, Filarr had no way to share a file. If you wanted to send an encrypted document to someone, you exported it from Filarr, encrypted it again with something else, and dealt with the recipient figuring out how to decrypt it.

Today — May 17, 2026 — we ship file sharing. Two flavors:

Share from the Filarr desktop app if you have an account. Right-click any file, get a link, pick expiry and options, send it.
Filarr Send if you don't. Drop a file at filarr.com/send, get the same encrypted link, no account required.

In both cases, the same end-to-end encryption guarantee: the file is encrypted on your device before upload, the decryption key never reaches Filarr's servers, the recipient downloads and decrypts in their own browser. This article explains how the trick works, what we see on the server (almost nothing), and what the trade-offs are.

How does the URL trick actually work?

The whole architecture rests on one detail of HTTP that most people have never thought about: the URL fragment (#) is never sent to the server.

When you type filarr.com/s/abc123 in a browser, the browser sends GET /s/abc123 to filarr.com. When you type filarr.com/s/abc123#k=opaquekeyvalue, the browser still sends GET /s/abc123 — the #k=opaquekeyvalue part stays in the browser's memory and is never transmitted. This is defined in RFC 3986 §3.5.

Filarr uses this for the share key. When you create a share:

Your device generates a fresh random 256-bit key (K_share)
Encrypts your file with AES-256-GCM using that key
Uploads the encrypted bytes to Cloudflare R2 in Europe
Builds a URL like https://filarr.com/s/abc123#k={K_share_base64}
You share that URL through your preferred channel

When the recipient clicks the link:

Their browser loads filarr.com/s/abc123 (no key sent)
Filarr's web app receives this request, returns the recipient page
JavaScript in the page reads the key from window.location.hash
The browser downloads the encrypted bytes from the server
The browser decrypts in-memory using the key

The Filarr server's view: an opaque encrypted blob and a share ID. No key, no plaintext, no filename. Even if our entire infrastructure were compromised tomorrow, the attacker would only have encrypted noise. This is what "zero-knowledge" means in practice — see zero-knowledge encryption explained for the deeper model.

What does the server actually see?

Honest list. The Filarr server (the Cloudflare Worker handling shares) sees:

The encrypted blob bytes (opaque to it — AES-256-GCM)
The share ID
Expiry timestamp, max-downloads counter
For audit log entries: country code (from Cloudflare's IP geolocation) and the recipient's /16 subnet (e.g. 192.168.x.x)
Your account ID, if you're using authenticated sharing
A hash of the creator's IP, for anonymous Filarr Send (for rate-limiting and DMCA traceback)

The server never sees:

File contents (encrypted before upload)
File name (the manifest is also encrypted; the server sees manifest.enc, not report.pdf)
Full file size in clear (chunks are uniform 16 MB)
The decryption key (it's in the URL fragment, never transmitted)
Your password if you password-protect the share (only a stretched HKDF derivative — the server stores a salt but never the password)
The recipient's full IP (we keep /16 subnet only — that's 192.168.x.x granularity, never 192.168.1.42)

This is enforced in code, not by policy. There's no "trust us" — the cryptographic architecture makes server-side decryption mathematically impossible.

How does the password option work?

If you check "password protect" when creating a share, the link still has a key in the fragment, but it's only half the decryption material. The actual decryption key is computed as:

K_actual = HKDF-SHA-256(K_share || password, salt, "filarr-share-v1")

The salt is random per-share, stored on the server (without the password). The recipient needs both the URL and the password to decrypt. Brute-force is rate-limited at the Worker level + slowed down by HKDF cost. Without the password, the URL alone is useless.

This is a meaningful layer if you're worried about the URL leaking via screenshots, browser history, accidental Slack post, etc. The link alone isn't enough.

Caveat: the Free plan can't use the password option — it's Solo/Pro only (and on the anonymous Filarr Send page). This is intentional pricing.

What is Filarr Send, exactly?

A second mode shipped at the same time. Filarr Send is for people who don't have a Filarr account but want to send a single encrypted file.

Go to filarr.com/send, drag-drop a file, configure expiry/password/max downloads, get a link. Same E2EE architecture as the authenticated mode — your browser does all the encryption client-side, the Cloudflare Worker only sees encrypted chunks.

Limits for anonymous Send:

Max file size: 2 GB
Max expiry: 7 days
Max downloads: 10
Max 5 active sends per IP per 24 hours (rate-limit, IP hashed with SHA-256)
Password option available

This is the WeTransfer / Wormhole / Firefox Send slot, but with actual E2EE that the service can't break. Useful when you're at a hotel computer, on a friend's laptop, or you just don't want another account.

Authenticated shares show an audit log. On the /shares page in the desktop app, expand "History" on any active share to see who downloaded it.

What you see:

Timestamp of each download
Country (e.g. France, US — from Cloudflare's IP geolocation)
/16 subnet (e.g. 89.156.x.x)

What you don't see:

Full IP address (only /16)
User agent
Any identifier of the recipient

The /16 subnet is a compromise: precise enough to spot "this got downloaded 12 times from 5 different networks", coarse enough that we never log identifying IPs. A French ISP /16 covers about 65,000 IPs.

The "1 download per IP" option

For when you want one specific recipient. Enable this option in the share modal, and after the first successful download from a /16 subnet, subsequent requests from the same subnet return 403.

Caveat we tell you in the UI: if your recipient is behind a corporate NAT or carrier-grade NAT (mobile networks, big offices), they share the limit with everyone else on that NAT. If multiple coworkers might need the file, don't use this option.

What are the plan limits?

	Anonymous (Send)	Free	Solo (€4/mo)	Pro (€8/mo)
Max file size	2 GB	1 GB	10 GB	50 GB
Max expiry	7 days	14 days	90 days	1 year
Max active shares	3/IP	10	100	unlimited
Max downloads per share	10	50	1,000	unlimited
Password protect	✓	✗	✓	✓
Audit log	✗	✓	✓	✓
1-download-per-IP	✗	✓	✓	✓
Revoke / unshare	✗	✓	✓	✓

The progression is intentional: anonymous is the "try it once" mode (closer to WeTransfer's offer), Free gives you a real account and persistent shares, Solo and Pro are for professional use where you need bigger files and longer expiry.

Real use cases

Concrete scenarios where this is useful.

A designer delivering a project. Final deliverables are heavy — InDesign archives, raw video, layered PSDs. Email won't take it, WeTransfer expires in 7 days unencrypted, Google Drive sees everything. Filarr Pro: 50 GB per file, 1 year expiry, password-protected.

A lawyer sending a contract draft. Confidential, can't go through standard email. Solo plan: encrypted, password-protected, 1-download-per-IP locked to the recipient's office.

A journalist receiving a leak. Source uses Filarr Send (no account, no traceability for them), creates a 7-day link to a single document, sends the URL to the journalist via Signal. The journalist downloads from a clean machine. No Filarr account ever required on either side.

Sending from a hotel computer. You don't have your laptop, you need to send a sensitive document. Filarr Send: drag-drop in browser, get encrypted link, send via your phone. The document never lives on the hotel computer beyond the encryption pass.

What you should be careful about

Honest limits.

The URL contains the decryption key. Anyone with the URL can download. Treat it like a password: don't post it on Slack, don't put it in an email subject line, don't share it on Twitter. If you must share via insecure channels, use the password option.

Browser history captures the full URL, including the fragment. If you opened the share link on a shared machine, the URL might be in someone's history. Use private browsing or clear history when relevant.

Filarr Send shares cannot be revoked. Once the link is out, it's out — you can wait for it to expire or max out downloads, but you can't manually kill it. Authenticated shares can be revoked at any time.

The encryption key for shares you created is cached in your device's localStorage. If you wipe your browser data on filarr.com, you lose the ability to re-copy the URL for shares created on that device. The shares themselves keep working for recipients who already have the link — but you can't reconstruct it from /shares anymore.

Proton Drive offers similar E2EE sharing but requires the recipient to interact with Proton's web app. Their key model is different — they use Proton's identity infrastructure.

Tresorit Send does anonymous-friendly E2EE sharing. Closest analog to Filarr Send. Their service is solid; the main difference with Filarr Send is that we're an open-core company with our client code published on GitHub — you can audit the share crypto. See src/services/sharing/shareCrypto.ts if you want to verify the implementation.

WeTransfer is not E2EE. Your file is encrypted in transit (HTTPS) and at rest with WeTransfer's keys, but they can decrypt it. The free 7-day storage gets indexed, scanned for compliance, etc. Useful, but not what Filarr Send replaces.

How do I start?

If you have Filarr installed: update to v2.10.0+ (Settings → Check for updates). Right-click any file in your vault → "Share via link". Configure options, copy the URL, send through your preferred channel.

If you don't have Filarr: go to filarr.com/send, drop a file. No signup, no install, encrypted in your browser before upload.