DEV Community: anon.li

Add end-to-end encrypted file uploads to your CLI tool: a hands-on walkthrough

anon.li — Sat, 25 Apr 2026 22:00:00 +0000

I have a CLI tool that generates internal reports and I needed a way to share them with a coworker who doesn't use our internal storage. I didn't want to email PDFs (audit trail), Slack files (search history forever), or spin up presigned S3 URLs (configurable, but I'd be the auth boundary).

What I actually wanted: a one-liner in my CLI that hands the user back a URL, where the file is encrypted client-side, the server sees ciphertext only, and the link expires on its own.

This post is the walkthrough of how I built that against anon.li's Drop API. It's about 150 lines of Node, no dependencies beyond node:crypto. By the end you'll have a script you can drop into any CLI tool to add E2EE file sharing.

The shape of the thing

Drop's upload flow has four steps:

Create a drop — POST to /api/v1/drop with metadata (IV, file count, expiry). Get back a drop_id.
Add a file — POST to /api/v1/drop/:id/file with the encrypted file's metadata. Get back a fileId and presigned upload URLs (one per chunk).
PUT each chunk to its presigned URL. Capture the ETag returned by the storage layer.
Finish the upload — PATCH /api/v1/drop/:id?action=finish with the chunk ETags. The drop becomes ready.

Then you build a share URL: https://anon.li/d/<drop_id>#<base64-key>. The fragment carries the AES-256 key, which never reaches the server (browsers strip it from requests — see my other post on why this matters if you're curious).

We'll do everything client-side, in pure Node, with crypto.subtle (Web Crypto, available in Node 16+) and node:crypto for buffer juggling.

Step 1: get an API key

From the anon.li dashboard: API Keys → New. Copy it once, it's only shown at creation. Format is ak_ + 32 hex chars. The server stores only the SHA-256 hash of it, which is why it can't show it again.

For this script, expose it as an env var:

export ANON_API_KEY=ak_yourkeyhere

Step 2: scaffolding and key generation

import crypto from 'node:crypto';
import { readFile } from 'node:fs/promises';
import path from 'node:path';

const API = 'https://anon.li/api/v1';
const KEY = process.env.ANON_API_KEY;
if (!KEY) throw new Error('ANON_API_KEY not set');

const auth = { Authorization: `Bearer ${KEY}` };

// Helper: base64url encoding (RFC 4648)
const b64u = buf => Buffer.from(buf).toString('base64url');

// Helper: derive a unique IV per chunk from a base IV
function deriveChunkIv(baseIv, chunkIndex) {
  const iv = Buffer.alloc(12);
  baseIv.copy(iv, 0, 0, 8);          // first 8 bytes from base IV
  iv.writeUInt32BE(chunkIndex, 8);   // last 4 = chunk index, big-endian
  return iv;
}

The deriveChunkIv helper is the workhorse of this whole script. Drop uses one base IV per file, and every chunk's actual IV is computed deterministically from (baseIv, chunkIndex). That means we only generate randomness once, and we never need to ship per-chunk IVs to the server — they're reproducible from the base IV alone.

Filenames use the same scheme with a reserved chunk index of 0xFFFFFFFF, which is guaranteed not to collide with any real chunk (you'd need 4 billion chunks in one file before hitting it).

async function uploadFile(filePath, { expiry = 7, maxDownloads } = {}) {
  const fileBuf = await readFile(filePath);
  const filename = path.basename(filePath);

  // 256-bit AES key, base IV for this drop, base IV for this file
  const key = crypto.randomBytes(32);
  const dropIv = crypto.randomBytes(12);
  const fileIv = crypto.randomBytes(12);

Three random things, generated locally:

key — the AES-256 key. Goes in the URL fragment, never sent to the server.
dropIv — the base IV for drop-level metadata (title, message).
fileIv — the base IV for this file's chunks and filename.

For larger files you'd chunk by 50 MB (Drop's default) or whatever fits your memory budget. We'll keep it single-chunk for clarity.

Step 3: encrypt the file and the filename

  // Encrypt the file payload (single chunk, index 0)
  const chunkIv = deriveChunkIv(fileIv, 0);
  const cipher = crypto.createCipheriv('aes-256-gcm', key, chunkIv);
  const ciphertext = Buffer.concat([cipher.update(fileBuf), cipher.final()]);
  const authTag = cipher.getAuthTag();
  const encryptedData = Buffer.concat([ciphertext, authTag]); // 16-byte tag appended

  // Encrypt the filename with the reserved chunk index
  const nameIv = deriveChunkIv(fileIv, 0xFFFFFFFF);
  const nameCipher = crypto.createCipheriv('aes-256-gcm', key, nameIv);
  const encryptedName = b64u(Buffer.concat([
    nameCipher.update(filename, 'utf8'),
    nameCipher.final(),
    nameCipher.getAuthTag(),
  ]));

Two things worth noticing:

The encrypted file is ciphertext || authTag — Drop's wire format is "GCM ciphertext, then 16-byte tag." On decryption you split off the last 16 bytes and feed them to setAuthTag() before final(). This is consistent across chunks too: each chunk on the wire is chunk_ciphertext || tag.

The filename is encrypted with the same key but a different IV (the 0xFFFFFFFF one). One key, many IVs, derived from the base — that's the whole pattern.

Step 4: create the drop

  const createRes = await fetch(`${API}/drop`, {
    method: 'POST',
    headers: { ...auth, 'Content-Type': 'application/json' },
    body: JSON.stringify({
      iv: b64u(dropIv),
      fileCount: 1,
      expiry,
      maxDownloads,
    }),
  });
  if (!createRes.ok) throw new Error(`create drop: ${createRes.status}`);
  const { data: drop } = await createRes.json();
  const dropId = drop.drop_id;

expiry is days (max depends on plan: 3 free, 7 plus, 30 pro). maxDownloads is optional. If you wanted to attach encrypted metadata (a description, JSON tags, anything), you'd encrypt it with the same key + dropIv + 0xFFFFFFFF reserved index and pass it as encryptedMessage here. The server stores the ciphertext and can't read it.

Step 5: register the file, get presigned upload URLs

  const fileRes = await fetch(`${API}/drop/${dropId}/file`, {
    method: 'POST',
    headers: { ...auth, 'Content-Type': 'application/json' },
    body: JSON.stringify({
      size: encryptedData.length,
      encryptedName,
      iv: b64u(fileIv),
      mimeType: 'application/octet-stream',
      chunkCount: 1,
      chunkSize: encryptedData.length,
    }),
  });
  if (!fileRes.ok) throw new Error(`add file: ${fileRes.status}`);
  const file = await fileRes.json();

Response shape:

{
  "fileId": "file123",
  "s3UploadId": "upload-id",
  "uploadUrls": {
    "1": "https://r2-presigned-url..."
  }
}

uploadUrls is keyed by chunk number (1-indexed). For our one-chunk file we have one URL. For a multi-chunk file you'd get N URLs and PUT to each.

The presigned URLs go directly to Cloudflare R2, bypassing anon.li's app servers entirely. That means the encrypted bytes don't transit through the API host at all — they go straight to object storage. Cleaner for them, faster for you.

Step 6: PUT the encrypted bytes

  const putRes = await fetch(file.uploadUrls['1'], {
    method: 'PUT',
    body: encryptedData,
  });
  if (!putRes.ok) throw new Error(`upload chunk: ${putRes.status}`);
  const etag = putRes.headers.get('ETag');
  if (!etag) throw new Error('no ETag returned from storage');

Storage hands back an ETag for each chunk. We need it for the finalize step — it's how we prove that what we uploaded matches what the storage backend received.

Step 7: finalize

  const finishRes = await fetch(`${API}/drop/${dropId}?action=finish`, {
    method: 'PATCH',
    headers: { ...auth, 'Content-Type': 'application/json' },
    body: JSON.stringify({
      files: [{
        fileId: file.fileId,
        chunks: [{ chunkIndex: 0, etag }],
      }],
    }),
  });
  if (!finishRes.ok) throw new Error(`finish: ${finishRes.status}`);

This commits the multipart upload on the storage side and marks the drop as ready for download. Without this step the drop is in "uploading" limbo and the share URL won't work.

Step 8: hand back the share URL

  const shareUrl = `https://anon.li/d/${dropId}#${b64u(key)}`;
  return shareUrl;
}

The fragment is the base64url-encoded raw key. The browser will keep it client-side. The server side of anon.li will only ever see dropId.

Glue it together

const url = await uploadFile(process.argv[2], { expiry: 3 });
console.log(url);

$ node share.js ./report.pdf
https://anon.li/d/abc123xyz#nT7l3K9Q...

Done. Send the link, recipient clicks, file decrypts in their browser. Three days later, the bytes are gone.

Things I got wrong the first time

A few stumbling blocks that bit me when I wrote this for real:

Forgetting the auth tag. GCM's auth tag is 16 bytes appended after the ciphertext. If you use cipher.update + cipher.final and forget cipher.getAuthTag(), the receiving end can't verify integrity and decryption fails. Don't separate them — bundle as ciphertext || tag always.

Wrong IV byte order. The chunk index is big-endian in the last 4 bytes of the IV. I wrote writeUInt32LE once and got OperationError: decryption failed and spent fifteen minutes blaming the API. Read your Buffer.write* docs.

Not reading the fragment correctly on the receive side. If you build a Node receiver, new URL(shareUrl).hash includes the leading #. Strip it with .slice(1) before base64-decoding. Browsers do the same with location.hash.

Using chunkSize of the plaintext. The API wants the size on the wire, which is plaintext + 16-byte tag per chunk. For our single-chunk case that's encryptedData.length. Get this wrong and either the upload fails or the receiver chunks the download incorrectly.

What I'd add next

This script is the floor, not the ceiling. Real things you'd want:

Streaming for big files. Don't readFile a 4 GB file. Use createReadStream, encrypt chunk-by-chunk, PUT each chunk as it's ready. Drop's chunk format is designed for this — the IV derivation gives you an explicit chunkIndex to count against.
Password protection. Drop supports wrapping the file key under an Argon2id-derived password key. The receiver enters the password, derives the wrapping key locally, unwraps the file key, and decrypts. You never send the password.
Owner-key recovery. If you want the dashboard to be able to see your own files later (just for management — it still can't decrypt the contents), you can wrap the file key under an account-level vault key and pass ownerKey on creation. Optional, lets you delete files from the dashboard.
Encrypted metadata. Stick a JSON blob (description, tags, source app version) in encryptedMessage so receivers see context after decryption.

Each of those is its own short post. The scaffold above gets you to the point where you can ship E2EE file sharing without a backend you control. For a CLI tool, that's an absurd amount of capability for ~150 lines.

Source for the full script (and the corresponding download/decrypt counterpart) lives in the Drop API docs. Steal it.

How URL fragments make true zero-knowledge file sharing possible

anon.li — Sat, 25 Apr 2026 21:25:39 +0000

Here's a URL:

https://anon.li/d/abc123#U2FsdGVkX1...

The thing after the # is an AES-256 encryption key. The server hosting the file behind abc123 cannot see it, cannot log it, and cannot reproduce it from anything else it stores. If the server gets owned tomorrow, the attacker walks away with encrypted blobs and nothing to decrypt them with.

This isn't marketing copy. It's a property of HTTP that has been there since 1996 and that almost nobody uses for what it's good at. Let's pull on it.

The HTTP fragment is special

When your browser fetches https://example.com/page?foo=bar#section, here's what's actually sent over the wire:

GET /page?foo=bar HTTP/1.1
Host: example.com

The #section part — the fragment identifier - never appears in the request line, never appears in headers, never reaches the origin server. RFC 3986 defines it as client-side only: the browser uses it to scroll to anchors, the JavaScript runtime can read it via location.hash, but it stops at the network boundary.

This is non-negotiable browser behavior. It's not a feature you opt into. It's not a CDN setting. Every conformant HTTP client in existence treats it the same way, because if it didn't, every "back to top" anchor would generate server log noise.

So: you have a side channel that travels with your URL but doesn't reach your server. What can you do with that?

Stick a key in it

The trick that products like anon.li's Drop, Send (RIP), and a handful of others use is roughly:

Generate an AES-256 key in the browser.
Encrypt the file in the browser.
Upload only the ciphertext.
Build a share URL where the path is the file's ID and the fragment is the base64 of the key.
Hand that URL to the recipient.

When the recipient clicks the link, their browser fetches /d/abc123 (the server returns ciphertext + metadata), but the #U2FsdGVkX1... part stays in their browser. Client-side JavaScript reads location.hash, decrypts, and renders.

The server never has the key. Not "promises not to look at the key." Cryptographically cannot have the key. That's the difference between zero-knowledge and just "we encrypt at rest, trust us."

// Sender side
const key = await crypto.subtle.generateKey(
  { name: 'AES-GCM', length: 256 },
  true,
  ['encrypt', 'decrypt']
);
const rawKey = await crypto.subtle.exportKey('raw', key);
const keyB64 = btoa(String.fromCharCode(...new Uint8Array(rawKey)))
                 .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');

// ...encrypt and upload ciphertext...

const shareUrl = `https://anon.li/d/${dropId}#${keyB64}`;
// ↑ Anything after the # never touches the server.

// Recipient side
const keyB64 = location.hash.slice(1);
const rawKey = Uint8Array.from(
  atob(keyB64.replace(/-/g, '+').replace(/_/g, '/')),
  c => c.charCodeAt(0)
);
const key = await crypto.subtle.importKey(
  'raw', rawKey, 'AES-GCM', false, ['decrypt']
);

// fetch ciphertext, decrypt with key

The IV problem (and a clean solution)

Once you decide to chunk large files — which you must, because nobody wants to load a 5 GB ArrayBuffer into RAM to encrypt it — you hit a practical question: how do you give every chunk a unique IV?

AES-GCM is brutally unforgiving about IV reuse with the same key. Reuse one IV across two encryptions and you've leaked enough material to recover plaintext XORs and forge messages. Don't reuse IVs.

The naive approach is "generate 12 random bytes per chunk." That works, but now you have to store every IV server-side, increasing metadata size and adding bookkeeping. Worse, you have to be sure your RNG is good for every single chunk.

The pattern Drop uses is cleaner: derive chunk IVs deterministically from one base IV plus the chunk index.

// 12-byte IV: first 8 bytes from base IV, last 4 = chunk index (big-endian u32)
function deriveChunkIv(baseIv, chunkIndex) {
  const iv = new Uint8Array(12);
  iv.set(baseIv.slice(0, 8), 0);
  new DataView(iv.buffer).setUint32(8, chunkIndex, false); // BE
  return iv;
}

Properties this gives you:

One random thing per file. You only need to generate 12 random bytes once. Every chunk's IV is derived deterministically from it.
Uniqueness within a file. As long as every chunk has a different chunkIndex, every chunk gets a different IV. With Uint32 you've got 4 billion possible chunks per file before you collide — far more than you'll ever upload.
Uniqueness across files. Different files get different base IVs, so the 8-byte prefix is independent. The combined 12-byte IV space is effectively the same as random per-chunk IVs.
No per-chunk metadata needed. The server only stores the base IV. The recipient can reconstruct the chunk IV from (base IV, chunk index) alone.

There's a nice extra trick: reserve a "magic" chunk index for filename encryption. Drop uses 0xFFFFFFFF, the max u32. Since real chunks count up from 0 and you'll never hit 4 billion of them, this index is guaranteed never to collide with a data chunk's IV — so you can encrypt the filename with the same key, derive its IV the same way, and you're done. No separate key, no separate KDF, no IV bookkeeping.

const filenameIv = deriveChunkIv(baseIv, 0xFFFFFFFF);
// guaranteed never to overlap with chunk 0, 1, 2, ...

This kind of design — where you find a way to not need a thing rather than carefully managing it — is the secret to keeping crypto code reviewable. Every piece of state you eliminate is a piece of state you can't get wrong.

Authenticate, don't just encrypt

AES-GCM is an authenticated cipher: every encryption produces a 16-byte tag that has to verify on decryption. Tamper with the ciphertext, change one bit, and the tag mismatches and decryption errors out.

This matters more than people realize for chunked uploads. Without authentication, an attacker who controls the storage layer (or a CDN, or a proxy) could splice or corrupt chunks and the recipient would silently get garbage — or, worse, plausible-looking but altered data. With per-chunk auth tags, each chunk has integrity. Tampering anywhere in the file fails decryption immediately.

You get this for free with crypto.subtle.encrypt({ name: 'AES-GCM', iv }, key, plaintext). The output already includes the auth tag appended. Don't roll your own.

What an attacker who breaks the server actually gets

Let's audit. Here's what a Drop-style server stores:

It stores	It does not store
Ciphertext (chunks of AES-GCM output)	Plaintext bytes
Encrypted filenames	Original filenames
File size, MIME type	Encryption key
Base IV	Password (if used)
Expiry, download counter, owner ID	Anything decryptable from above

If the server is compromised, the attacker walks away with bytes that decrypt to nothing without a key they don't have. The keys are in URL fragments, which only ever exist in (a) the sender's browser at upload time, (b) the URLs the sender chose to share, and (c) the recipient's browser at download time. Steal the database, you get encrypted noise. That's the design.

What can a malicious server still do? Two real things:

Refuse service — delete files, lie about expiry, return errors. This is unavoidable; you trust the server for availability, not confidentiality.
Serve malicious JavaScript — if you trust the server to ship the decrypt code, a compromised server can ship a backdoored decrypt routine that exfiltrates the key after location.hash is read. This is the genuine weakness of any browser-based E2EE. Mitigations include CSP, open-source clients you can audit, browser extensions that lock the JS bundle, and reproducible builds. It's a real concern; be honest about it.

Why this design isn't more common

A few reasons:

It requires real client-side code. Web Crypto isn't hard, but it's harder than multer.single('file').
Big files become awkward without chunking + streams.
Previews are tricky: you have to decrypt to render thumbnails. Drop handles this by treating preview requests as full downloads against the encrypted bytes — and counting them against the download limit, since they expose the same material.
Search is impossible. The server can't index something it can't read. This is a feature, but it's a constraint.
Most products don't actually want zero-knowledge. They want plausible-deniability marketing. A zero-knowledge architecture closes off a lot of "we'll add a feature later" doors.

For consumer file sharing, those tradeoffs are usually worth it. For internal tools where the server has business reasons to read files (virus scanning, OCR, indexing), they're usually not. Pick the right tool for the threat model you actually have.

Try it

If you want to see this pattern in action with code you can read end-to-end, anon.li's Drop API docs include the full Node.js encrypt/decrypt flow, and the client implementation is open source. Read the encryption module, then read the share-link generator, then look at what actually goes over the wire in Network tab. Watching the fragment not appear in any request log is the moment the whole thing clicks.

The next time you see # in a URL, look closer. It might be doing more work than you think.

Build a disposable email alias CLI in 50 lines of Bash

anon.li — Sat, 25 Apr 2026 21:21:58 +0000

I have a rule I keep breaking: never give a website my real email if I'm not sure I want a relationship with them. Five minutes later I'm on some forum, signup form open, and I'm typing me@gmail.com again because firing up a password manager, generating an alias, copying it, pasting it - it's just enough friction that I default to the lazy thing.

So this weekend I built alias - a single shell command that spits out a fresh forwarding address I can paste anywhere. Took about an hour. The whole thing is curl, jq, and one POST request.

I'm using anon.li as the backend because (a) it has a clean REST API, (b) it's open source, and (c) the free tier covers personal use. But the structure here works against any forwarding service that exposes an API - Addy, SimpleLogin, your own self-hosted thing.

The endpoint

The Alias API has a Bitwarden-compatible "just generate me one" endpoint. From the docs:

POST https://anon.li/api/v1/alias?generate=true
Authorization: Bearer ak_...

You can pass an optional domain in the body if you've added a custom one. With no body, it returns a random alias on anon.li. The response is the canonical alias object - id, email, timestamps, the works.

That's literally the entire API surface for what I want. One call, one address.

Step 1: get a key

Sign up, go to Dashboard → API Keys, generate one. It'll look like ak_ followed by 32 hex characters. Copy it once, because anon.li only shows the SHA-256 hash on their side after that - if you lose it, you rotate.

I stash mine in ~/.config/anon/key:

mkdir -p ~/.config/anon
echo "ak_yourkeyhere" > ~/.config/anon/key
chmod 600 ~/.config/anon/key

If you're on a multi-user machine or just paranoid, swap this for pass, 1Password CLI, gpg --decrypt, whatever. Don't put it in .bashrc in plaintext.

Step 2: the function

Drop this into ~/.bashrc (or ~/.zshrc):

alias() {
  local key
  key=$(cat ~/.config/anon/key 2>/dev/null) || {
    echo "no api key at ~/.config/anon/key" >&2
    return 1
  }

  local domain="${1:-anon.li}"
  local response
  response=$(curl -sS -X POST \
    "https://anon.li/api/v1/alias?generate=true" \
    -H "Authorization: Bearer $key" \
    -H "Content-Type: application/json" \
    -d "{\"domain\":\"$domain\"}")

  local email
  email=$(echo "$response" | jq -r '.data.email // empty')

  if [[ -z "$email" ]]; then
    echo "alias creation failed:" >&2
    echo "$response" >&2
    return 1
  fi

  echo -n "$email" | (command -v pbcopy >/dev/null && pbcopy \
                  || command -v wl-copy >/dev/null && wl-copy \
                  || command -v xclip >/dev/null && xclip -selection clipboard)
  echo "$email (copied)"
}

Reload your shell. Now:

$ alias
x7k9m2@anon.li (copied)

That's it. Forty-something lines of Bash, one network call, address on my clipboard. I haven't typed gmail.com into a signup form in six weeks.

Heads up: alias is a Bash builtin (the thing you use for alias ll='ls -la'). Defining a function with the same name shadows it inside your own shell, which is fine for personal use, but if you script anything that depends on alias the builtin, name yours aka or alli or whatever. I personally don't care.

Why not just use the dashboard?

I do, for ones I want to label and track. But for a throwaway - "I just want to read this gated article" - I don't need to think about what to call it. I want it on my clipboard before I've finished alt-tabbing back to the browser. The CLI wins on that exact use case.

The dashboard is also where I go later to disable the alias when the site inevitably starts spamming me. Toggling active: false is one PATCH request, but I rarely bother scripting that part - I'm already in the dashboard reading the spam.

Bonus: domain switcher

If you've added a custom domain (say, mail.example.dev), you can pass it as an argument:

$ alias mail.example.dev
random-suffix@mail.example.dev (copied)

I use this for my "real but disposable" identity - the one I give to recruiters and conference signups. Random-looking but on a domain I own, so it doesn't trip the "is this a burner?" filters that some sites run against known alias domains.

Bonus 2: skip the CLI, use Bitwarden

If you live in Bitwarden anyway, anon.li implements the Addy.io-compatible flow. In Settings → Options → Username Generator, pick Forwarded Email Alias → addy.io, paste your API key, and set the URL to https://anon.li/api/v1. Now the username field on every "create new login" sheet has a generate button that talks to the same endpoint. That's the fully no-friction version.

The CLI still wins for terminal flows - quick test signups, registering API sandboxes, anywhere I'm not in the password manager UI.

What's actually happening behind the curtain

The Alias backend isn't a hosted mailbox. There's no inbox. anon.li's mail server takes the inbound message, optionally encrypts the forwarded copy with your recipient's PGP key, signs it with DKIM, rewrites the envelope sender (SRS) so SPF still aligns, and ships it to your real address. The only state stored per alias is aggregate counters: received, blocked, last-seen-at.

That trust model is what makes me comfortable using disposable aliases for anything moderately sensitive - receipts, account confirmations, the dentist. Even if anon.li got fully owned tomorrow, there's no historical archive of my mail to leak. Just the routing config.

It's not a replacement for E2EE messaging. SMTP is what it is. But it raises the floor by a meaningful amount, and the API makes it easy enough that I actually use it instead of giving up and pasting my real address.

The whole script

For copy-paste convenience:

# ~/.bashrc
alias() {
  local key
  key=$(cat ~/.config/anon/key 2>/dev/null) || {
    echo "no api key at ~/.config/anon/key" >&2
    return 1
  }
  local domain="${1:-anon.li}"
  local response
  response=$(curl -sS -X POST \
    "https://anon.li/api/v1/alias?generate=true" \
    -H "Authorization: Bearer $key" \
    -H "Content-Type: application/json" \
    -d "{\"domain\":\"$domain\"}")
  local email
  email=$(echo "$response" | jq -r '.data.email // empty')
  if [[ -z "$email" ]]; then
    echo "alias creation failed:" >&2
    echo "$response" >&2
    return 1
  fi
  echo -n "$email" | (command -v pbcopy >/dev/null && pbcopy \
                  || command -v wl-copy >/dev/null && wl-copy \
                  || command -v xclip >/dev/null && xclip -selection clipboard)
  echo "$email (copied)"
}

Friction is the enemy of good security habits. The smaller you can make the gap between "I want to do the right thing" and "the right thing is done," the more often you'll do it. A single shell function won me back the habit. Try it.

What do you use for file sharing? Why?

anon.li — Sat, 25 Apr 2026 21:07:30 +0000

Hi!
Developer of anon.li Drop here. We offer end-to-end encrypted file sharing of files up to 250GB in size through our website, API, CLI and even MCP for AI.
What do you use for file sharing? What matters to you the most when it comes to file sharing? Is it privacy, modern UI, pricing...?
Thank you for your answers!

SimpleLogin vs anon.li - a developer's honest comparison

anon.li — Sun, 19 Apr 2026 09:54:08 +0000

If you care about your inbox - and your privacy - email aliasing is one of the best habits you can build. The idea is simple: instead of handing out your real address, you hand out a disposable alias that forwards mail to you. One service gets compromised? Disable the alias, never touch your real inbox.

SimpleLogin is the established name in this space, now owned by Proton. anon.li is a new privacy-focused alternative that launched in April 2026, built with a Liechtenstein jurisdiction philosophy and designed from the ground up for developers and privacy enthusiasts who want more than just forwarding.

Let's go feature by feature.

Quick overview

Feature	SimpleLogin	anon.li
Open source	✅ AGPL v3	✅ AGPL v3
Email forwarding	✅	✅
Send from alias	✅	✅
Custom domains	✅ Premium	✅ Premium
PGP forwarding	✅ Premium	✅ Free
Browser extensions	✅ Chrome, Firefox, Safari, Edge	✅ Chrome, Firefox
Mobile apps	✅ iOS + Android	❌ Web-first
REST API	✅	✅
CLI	❌	✅
MCP server	❌	✅
E2EE file sharing	❌	✅ (Drops)
Independent (no Big Tech parent)	❌ (Proton)	✅

Email aliasing - the core

Both services nail the fundamentals: you create an alias, emails forward to your real inbox, and you can disable or delete aliases at any time. Neither service stores your email content - messages are forwarded and immediately discarded.

Free tier: SimpleLogin requires a subscription to enable PGP encryption. anon.li offers it for free.

Replying from aliases: Both support replying from an alias. Your real address is never exposed - not even in outbound mail.

Custom domains: Both SimpleLogin & anon.li support custom domains.

The developer surface

This is where the comparison gets interesting. SimpleLogin has a solid REST API, and that's it. anon.li ships with a full developer ecosystem out of the gate.

REST API

Both services expose a REST API for programmatic alias management. With anon.li you can create, list, toggle, and delete aliases, manage recipients, and manage encrypted file drops - all from your own scripts and applications.

CLI

SimpleLogin has no official CLI. anon.li ships one. If you live in the terminal - and many developers do - this is a significant quality-of-life difference.

# Manage aliases from the terminal
anonli alias create --note "newsletter signup"
anonli alias list
anonli alias toggle abc123

# Manage encrypted file drops
anonli drop list
anonli drop toggle abc123

The CLI supports all API operations, including encrypted file drop management - useful for quickly sharing a secret, a config file, or a private key with a colleague without spinning up a separate file sharing service.

MCP server - the wildcard

This is something SimpleLogin doesn't offer at all. anon.li ships a native Model Context Protocol (MCP) server, which means AI assistants like Claude can directly manage your aliases.

With the anon.li MCP server connected, you can ask your AI assistant to list your aliases, create a new one for a specific purpose, toggle an alias on or off, list your encrypted drops, or manage recipients - all without leaving your chat interface.

This isn't a gimmick. As AI assistants become part of everyday workflows, having your privacy tooling directly accessible from the assistant that's helping you draft emails, manage sign-ups, and organize subscriptions is genuinely useful. anon.li is ahead of the curve here.

Encrypted file sharing - Drops

This is a feature category SimpleLogin doesn't touch at all. anon.li includes end-to-end encrypted file sharing, called anon.li Drop.

Files are encrypted client-side with the user's vault key before upload. Not even anon.li can read the contents or filenames. You share a drop link; the recipient downloads and decrypts. Drops support expiry dates, download count limits, and can be toggled off remotely and up to 250GB in size.

Feature	Detail
Encryption model	Client-side E2EE. Files encrypted before they leave your device. Server stores ciphertext only.
Access controls	Set download limits, expiry dates. Disable a drop remotely at any time.
API + CLI access	List, manage, and toggle drops via API, CLI, and MCP server - not just the web UI.

For a developer who occasionally needs to share a .env file, a private certificate, or a sensitive document - and wants to do it without trusting a third-party service - Drops is a genuinely useful feature that SimpleLogin simply doesn't compete on.

Privacy posture and jurisdiction

SimpleLogin is operated by Proton AG and subject to Swiss law - which has strong privacy protections, but Proton is now a large company with investor obligations, a broad product portfolio, and a corporate structure that has grown significantly since SimpleLogin was an independent project.

anon.li is independently operated with a Liechtenstein jurisdiction philosophy. It's a smaller, more focused service - which cuts both ways: fewer resources, but also no corporate parent that could change direction, get acquired, or be pressured by a larger ecosystem.

⚠️ SimpleLogin was acquired by Proton in 2022. While Proton has a strong privacy reputation, the service is no longer community-independent. If you prefer your privacy tools to be genuinely independent, anon.li is the stronger philosophical fit.

Both services are AGPL v3 open source. Neither stores email content. Both use TLS in transit. SimpleLogin has optional PGP forwarding at the premium tier; anon.li has a zero-knowledge Drops system today and PGP on the roadmap.

Ecosystem and integrations

SimpleLogin's biggest ecosystem advantage is Proton Pass integration. If you're already in the Proton ecosystem (ProtonMail, Proton VPN, Proton Pass), SimpleLogin slots in seamlessly - alias suggestions inside the password manager, one unified subscription, Proton's infrastructure behind you.

anon.li's ecosystem advantage is developer depth. The combination of REST API + CLI + browser extension + MCP server means it integrates with your workflow however you prefer to work - from the terminal, from the browser, from an AI assistant, or via scripts in your own applications.

Who should use which

Choose SimpleLogin if...

You're in the Proton ecosystem - ProtonMail + Proton Pass + SimpleLogin is the most seamless bundle for privacy-focused non-developers.
You need PGP forwarding today - SimpleLogin's PGP feature is mature and well-documented. anon.li has it on the roadmap.
You want iOS/Android apps - SimpleLogin has polished native mobile apps. anon.li is web-first for now.
You want battle-tested reliability - five years of production use, millions of aliases, Proton's infrastructure.

Choose anon.li if...

You're a developer - API + CLI + MCP server means anon.li fits into your workflow in ways SimpleLogin can't.
You want E2EE file sharing - Drops gives you a genuinely private way to share sensitive files. No equivalent exists in SimpleLogin.
You prefer independence - no Proton parent, no corporate ecosystem to navigate. One focused product, one team.
You use AI assistants in your workflow - the MCP server integration is unique. Manage aliases directly from Claude, Cursor, or any MCP-compatible client.

SimpleLogin remains the most polished and widely trusted email aliasing service available. If you're already inside the Proton ecosystem, there's little reason to leave.

But anon.li is a compelling new choice for developers and power users. The MCP server is genuinely novel. The CLI is overdue in this category. The encrypted Drops feature adds a dimension that no other aliasing service offers. And being independent - not part of a larger corporate stack - is increasingly a feature, not just a differentiator.

Both are AGPL v3 open source. Both take your privacy seriously. The choice comes down to ecosystem fit and how deep you want your tooling to go.

*Try anon.li at anon.li.