Firefox Send Alternative That's Actually Still Online

Firefox Send was a good idea executed well. Drop a file. Encrypt it in the browser. Get a link that self-destructs. Mozilla shipped it in 2017 and pulled it in 2020 after abuse complaints overwhelmed their small team. Privacy-aware users have been searching for a replacement ever since.

Zippd is the closest spiritual successor. Same architecture. Similar UX. We added the abuse handling that Send didn't have time to build.

The 30-second verdict

If you loved Firefox Send, you'll feel at home on Zippd. The encryption model is identical. The flow is familiar. The difference is that this one is built to survive the abuse load that killed Send.

Feature comparison

Why Firefox Send died

Mozilla pulled Send in March 2020 after security researchers documented malware operators using it as a delivery channel. The team paused uploads to add abuse reporting and account requirements. They never restarted it. The official reason was "shifting priorities." The real reason: a small team couldn't keep up with the abuse load on a free, anonymous file-sharing tool.

That's a real lesson. One Zippd took seriously from day one:

• DMCA and abuse reporting on every download page.
• Admin moderation queue with response-time targets (hours for CSAM and malware).
• Repeat-infringer policies tied to IP hashes and registered accounts.
• Aggressive auto-expiry so abuse links can't accumulate.

None of that makes abuse impossible. It does make Zippd sustainable in a way Send wasn't.

Architectural similarities

The technical design is almost a one-to-one match. Anyone who read Mozilla's open-source Send code will recognize the model:

• Browser generates a random AES key. Web Crypto API. Never leaves the device.
• File encrypts client-side. Chunked, with a fresh IV per chunk for authenticated encryption.
• Ciphertext uploads to cloud storage. Directly from browser to S3-compatible storage. Send used Mozilla's own storage layer.
• Key embeds in URL fragment. The #k=… part. Browsers never send fragments to servers.
• Recipient's browser decrypts. Same Web Crypto API. Same flow.

Differences are in scale and tuning. AES-256 instead of AES-128, both fine in practice. S3 multipart upload with parallel streams replaces Send's single-stream approach. The visual design is 2026 rather than 2018.

Where Firefox Send was better

1. Mozilla's reputation

Send launched with the Firefox brand behind it. Privacy-minded users trusted Mozilla in a way they don't trust an unknown new service. We have to earn that one upload at a time.

2. Mozilla's security pedigree

Send's code was open-source and reviewed by Mozilla's security team. Zippd's crypto runs in plain JavaScript you can audit in DevTools — same accessibility, less institutional weight behind it.

Where Zippd is better

1. It exists

The most important feature. Firefox Send is a Wikipedia entry now.

2. Bigger free limits

Send capped anonymous at 1 GB and registered at 2.5 GB. We double the first and roughly 8x the second. The economics work because we run lean — no Mozilla-scale overhead to amortize.

3. Faster uploads

Parallel multipart with up to 8 concurrent streams. Send used a single-stream design that got noticeably slow above a few hundred megabytes.

4. Filenames are encrypted too

Send encrypted file contents but the metadata — filename, MIME type, plaintext size — was visible to the server. We encrypt all of it. The database stores opaque ciphertext for the metadata blob.

5. Optional payouts for popular files

Registered users earn a fixed rate per 1,000 unique downloads. See the current rate. Send had no payouts.

Migrating from a Firefox Send habit

Muscle memory translates almost directly:

1. Open the homepage.
2. Drag a file in.
3. Click "Encrypt & upload."
4. Copy the link with the #k=… fragment.
5. Send it however you like.

New thing: registered users get a dashboard with file history. Send didn't have that. If you don't want it, don't register. The anonymous flow is fully featured on its own.

FAQ

Is Zippd run by Mozilla?

No. We're a separate, independent service. We adopted the technical pattern Send pioneered because it works.

Could Zippd shut down like Send did?

Anything could shut down. The specific reason Send died — overwhelming abuse on a small team — is something we addressed structurally from day one with the moderation queue and aggressive expiry defaults. We're built to absorb abuse, not collapse under it.

Is AES-256-GCM trustworthy?

Yes. It's the modern standard for authenticated encryption. NIST recommends it. Your bank uses it. Signal uses a variant. The math is well-understood and the Web Crypto API implementation in your browser is audited by the people who ship your browser.

What if I lose the URL?

The file is unrecoverable. Same answer Send gave. Same reason — the key was never on our servers in the first place.

Try it

Send a file. If it doesn't feel like coming home, tell us what's off.