Send .env files and one-time secrets securely
End-to-end encrypted, self-destructing links for .env files, API keys, and passwords. Built
on a single small server with zero npm dependencies at runtime — no supply chain, no
analytics, no plaintext on the wire.
Send a .env file or one-time secret
- 0 runtime deps
- 2-factor decrypt
- Burns on first read
- ≤24h auto-expire
- EU-hosted
Link ready. Send the link and passphrase through different channels.
How to send a .env file securely (in four steps)
-
Paste your
.envfile or secret into the box above. Up to 16 KB of text — a full Next.js, Rails, or Django.envwith margin. - Choose a passphrase. It never leaves your browser; it's used to derive a second encryption key on top of the random key in the URL fragment.
- Pick a TTL. 1, 6, or 24 hours. The link self-destructs on first reveal or at the deadline, whichever comes first.
- Send the link in chat or email. Send the passphrase separately — phone call, SMS, password-manager share. Splitting the two factors across channels is the point.
What makes send.env.dev different from other one-time secret tools?
- Zero runtime npm dependencies. The production server is tiny and has no dependencies. The frontend is one HTML file plus a minimal amount of JavaScript using your browser's WebCrypto API. Most other one-time-secret tools pull hundreds of npm packages, every one a supply-chain attack surface. For a tool whose entire job is handling secrets, that is crazy and, honestly, not acceptable. We pull zero. None. Just inspect the site's HTML file and you can see how simple and secure it is. There are only 200–300 lines of JavaScript in total to audit. A whole suite of vulnerabilities and attack surfaces are just not possible here.
-
Every byte hash-pinned in CSP. The script and stylesheet that load in your browser are
pinned by sha256 hash in the
Content-Security-Policyheader at build time. The browser refuses to execute anything that doesn't match. No'unsafe-inline', no analytics, no Google Fonts call, no third-party origin allowed. - Two factors, two channels. A 256-bit random key in the URL fragment plus a passphrase run through PBKDF2-SHA256 with 600,000 iterations. Both are required to decrypt. You're told to send the link and passphrase through different channels so a single intercepted message can't reveal the secret. Many competitors only encrypt with the URL.
- Atomic burn, hard 24-hour TTL, EU-only storage. Each secret lives in its own isolated storage instance pinned to the EU jurisdiction. The reveal endpoint returns the ciphertext and deletes storage in the same single-threaded operation — concurrent readers cannot both succeed. Even if the link is never opened, the secret self-cleans within 24 hours.
Why pasting .env files in Slack, email, or chat is unsafe
Slack, Discord, Teams, email, and Jira comments write the secret into a long-term searchable index, sync
it to every device the recipient ever signs into, and expose it to anyone who later compromises a session
token, an OAuth scope, or a backup. Once a real .env hits any of those surfaces, treat every
value in it as public — the only correct response is to rotate. send.env.dev never persists plaintext,
holds ciphertext for at most 24 hours, and destroys it on first reveal.
Frequently asked questions
How do I send a .env file securely?
Paste the contents into the form above, choose a passphrase, generate the link. Send the link in chat or email; share the passphrase through a different channel — phone call, SMS, or a password-manager share. The recipient pastes the passphrase, the secret decrypts in their browser, and the server destroys the ciphertext on the first reveal.
What is a one-time secret link?
A URL that reveals a secret exactly once and then self-destructs. send.env.dev's links also encrypt the payload end-to-end — the server only ever sees ciphertext — and require a separate passphrase to decrypt, so an intercepted link alone is useless.
Can I share dotenv files via Slack, email, or Discord?
Don't. Those channels keep the message indexed, sync it across devices, and survive token compromises and
backup leaks. If a real .env ever lands in chat history, rotate every value in it — assume
it's public.
What's the safest way to send environment variables?
End-to-end encrypted, one-time, with the second factor on a separate channel. send.env.dev does this with no install or account. For ongoing distribution to running services, layer a secrets manager (1Password, Doppler, Infisical, HashiCorp Vault) on top — see the full guide on env.dev.
How is send.env.dev different from 1Password, Doppler, or Vault?
Those manage secrets for running apps and CI pipelines. send.env.dev is purpose-built for the act of
handing one .env file to one human, once. No account, no CLI, no IAM bootstrap. Use a
secrets manager on top for the continuous-distribution problem; use send.env.dev for the one-off
transfer.
Can env.dev read my secret?
No. Encryption happens in your browser via WebCrypto (AES-256-GCM) before anything leaves the device. The server only ever sees opaque ciphertext, and it never sees the URL fragment key or the passphrase.
Why do I need a passphrase if the URL already has a key?
It's a second factor. Even if someone intercepts the link, they cannot decrypt without the passphrase. Sending the link and the passphrase through different channels (e.g., chat and a phone call) means no single intercepted message reveals the secret.
What happens if I lose the link?
It's gone. The only copy of the encryption key lives in the URL fragment, which is never sent to the server. There is nothing to recover. Treat the link the same way you'd treat the secret itself.
How long does a secret last?
You choose 1 hour, 6 hours, or 24 hours when creating it. It self-destructs at that time, or the moment someone reveals it — whichever comes first.
Is it really one-time? Can two people open the link?
Each secret lives in its own atomic storage instance. The first reveal returns the ciphertext and destroys it in the same single-threaded operation. Concurrent readers cannot both succeed.
What can I share?
Any text up to 16 KB — passwords, API keys, OAuth tokens, SSH private keys, full .env
files, database URLs, JWT signing secrets, recovery codes. Binary files aren't supported; base64-encode
them first if you need to.
Will Slack or iMessage previews burn my link?
No. The encryption key and secret ID live in the URL fragment (the part after #), which is
never sent in HTTP requests. Link previewers fetch the homepage URL only and can't trigger the burn. The
reveal endpoint also rejects GET, so prefetchers can't burn a secret either.
Is it free?
Yes. No signup, no account, no payment. Part of env.dev.
Is there a CLI or API?
Not yet — send.env.dev is browser-only by design. Building a CLI on top of the HTTP endpoints would defeat the property that the encryption key never lives anywhere except the URL fragment.
Reveal a secret
Clicking reveal will permanently destroy this secret on the server. It can only be revealed once.
This link is no longer valid
It has already been used, has expired, or never existed. Each link on send.env.dev can only be revealed once, and self-destructs after the time chosen by the sender.
Secret revealed
Decrypted in your browser. Burned on the server.
This page is now invalid. Close it when you're done.