Why is pasting an API key into Slack bad?

Slack messages persist in chat history forever, are indexed for search, are visible to anyone added to the channel later, and remain on Slack's servers. A leaked Slack auth token gives an attacker access to every key ever pasted into your workspace. The same applies to email, Teams, Discord, and most chat platforms.

How is chirpfile different from Bitwarden Send or Tresorit Send?

Bitwarden Send and Tresorit Send put the decryption key in the URL fragment - so the recipient receives a single link that contains both the locator AND the key. If that link is forwarded, screenshot, screen-shared, or auto-copied by a password manager, the secret leaks. chirpfile splits the channels: the encrypted payload goes online, the key travels via sound only between physically present devices. There is no link that contains the key.

Is this actually secure - or is it security theater?

It's actually secure, and you can verify it. Every chirpfile page runs an open-source audit script that wraps window.fetch and scans every outbound request body for the active AES key. If the key were ever transmitted to the server, the audit panel would alarm. You can read the script source at /public/audit.js, or open browser DevTools and watch the network yourself. Both methods will confirm the key never leaves the device.

What's the size limit on a secret?

Text under 120 characters - which covers virtually every API key, OAuth token, JWT (sort of), database password, and credential - travels as pure sound with no relay involved. Longer secrets go through the relay (encrypted) up to 15 MB on free and 1 GB on Pro.

chirpfile

Don't paste API keys into Slack.

Q: Why not just use a password manager?

For ongoing secrets shared within a team, a password manager is the right tool - use 1Password, Bitwarden, or Dashlane. chirpfile is for one-time handoffs: a contractor needing temporary access, a colleague asking for a key in a meeting, sharing a credential with someone outside your password manager team. Single use, no account setup, gone in 15 minutes.

Slack history persists. Email is indexed. Screen shares leak. Send a one-time secret to the device next to you - encrypted in the browser, key transmitted as sound, burned after first read.

The everyday secret-sharing problem

You're in a pairing session and your colleague needs the staging database password. Or you're contracting for a client and they need the AWS access key. Or you're showing someone a quick demo and the OAuth client ID has to land on their laptop.

The usual options all have permanent-storage problems:

Slack DM. Persists in history forever, indexed in search, visible to anyone added to the channel later, sits on Slack's servers.
Email. Same problem plus inbox auto-backup to Gmail/Outlook/iCloud. Often archived to corporate mail retention.
Read it aloud. Slow, error-prone for any non-trivial key, painful with special characters. Recipient still has to type it.
Cloud doc / shared notes. Persists. Indexed. Often shared further or accidentally screen-grabbed.
SMS / iMessage. Backed up to iCloud or carrier, visible on every paired device, often previewed on lock screens.

What you actually want

One transfer. The secret arrives once on the recipient's device. No persistence anywhere.
No account setup. Both you and the recipient open a webpage. That's it.
No log trail. No chat history, no email archive, no cloud-doc revision.
Physical presence verification. Only someone in the same room as your device can receive. No remote interception.
Verifiable by someone paranoid. You can prove to yourself that the secret didn't touch anyone else's server.

How chirpfile does this

You type or paste the secret in your browser. If it's under 120 characters (which covers virtually every API key, OAuth token, database password, JWT), the secret is encoded directly into the chirp. No server touched. No upload. Pure sound between devices.

For longer secrets (multi-line credentials, JSON tokens, signed payloads), the secret is encrypted with AES-128-GCM in your browser, the ciphertext goes to a relay, and the decryption key travels via the chirp. The relay holds ciphertext it cannot decrypt. After download, the relay deletes its copy. After 15 minutes, anything unclaimed is deleted regardless.

Either way: the secret only exists on your device, on the recipient's device, and (briefly, encrypted) on the relay. Never in chat history, never in inbox backup, never in a cloud doc.

How it compares to other secret-sharing tools

Key channel Sound (out-of-band) URL fragment

Risk if link is forwarded None - no link contains the key Recipient + anyone who got the URL

Account required No Bitwarden: paid tier · Tresorit: optional

Burn after read Yes Yes

Physical presence required Yes (recipient must be in audio range) No - remote works

Server can decrypt No (verifiable) No (asserted)

You can verify this yourself. Every chirpfile page runs a small audit script that wraps window.fetch and scans every outbound request body for the active AES key. If the key were ever transmitted, the audit panel at the bottom of the page would alarm. Read the script at /public/audit.js - about 230 lines of plain JavaScript. It's the exact code running in your browser right now.

Try it now

Open chirpfile.com on both devices. Type the secret. Listen for the chirp.

Open chirpfile

Common questions

When should I use chirpfile vs a password manager?

Password managers (1Password, Bitwarden, Dashlane) for ongoing team-shared secrets. chirpfile for one-time handoffs: a contractor needing temporary access, a colleague needing a key in a meeting, sharing with someone outside your password-manager team, demos.

Is sound really a secure channel? Couldn't someone record it?

A recorder in the room can capture the chirp. The threat model is "no one else in the room is trying to attack you" - which matches the natural use case (you and a colleague in a meeting, you and a client at a table). If you're in a public space where someone might be recording, ultrasound mode reduces the audible signature but doesn't fully defeat a dedicated attacker with a wideband mic. For high-threat scenarios use proper key escrow.

Does the key ever appear in any log?

No - and the audit panel at the bottom of every chirpfile page lets you verify this in real time. It wraps window.fetch and scans every outbound body for the key. If the key were ever sent over the network, the alarm would fire.

What about multi-line secrets like a JSON config or a long token?

For text over 120 characters, the data is encrypted in your browser and uploaded as a blob. The encryption key still travels via sound. Up to 15 MB free, 1 GB on Pro.

Can the recipient screenshot the secret?

Yes - chirpfile doesn't claim to defeat the recipient. If you don't trust the recipient with the secret, no transfer tool can help. The point is preventing the secret from being intercepted in transit and from persisting in chat history, inbox, or cloud storage where third parties have access.

Open app → Security model Whitepaper Guide: zero-knowledge file transfer Share WiFi password View audit source Compare all FAQ ← Home