Encrypt the whole file locally with the AES-256-GCM Encryptor. Paste, encrypt with a passphrase, save only the ciphertext.
The .env file that should never have been committed
Every developer has seen it: a repository with a .env file containing database credentials, API keys, and a production secret or two, sitting in git history forever.
Git history is a permanent record. Deleting the file today does not remove it from past commits, and any clone, fork, or CI cache can still contain it. Attackers scan public repositories for exactly these files.
The fix starts before the file exists: never commit secrets in plaintext. Encrypting is the fallback for the cases where a copy must exist in the repository at all.
The better options before encryption
- gitignore the file - add .env and .env.* to .gitignore and never stage them
- Use environment variables injected by your host, CI, or deployment platform
- Use a secret manager for production values and inject them at runtime
- Store only non-secret defaults in a committed .env.example, with placeholders
Note: Encryption is not a license to commit secrets casually. It is the last-resort pattern for teams that genuinely need a shared, versioned copy of configuration - for example offline setups or small teams without a secret manager.
Why AES-256-GCM for environment files
AES-256-GCM is an authenticated encryption mode: it provides confidentiality and detects any tampering with the ciphertext. If the file is modified in the repository, decryption fails instead of silently returning corrupted values.
Because .env files are usually small text, encrypting them as a single document with a passphrase is practical. The passphrase is stretched with PBKDF2, so a weak passphrase still costs an attacker real computation per guess.
Everything can happen in the browser with the Web Crypto API - the plaintext never needs to reach a server, which is exactly what a zero-knowledge workflow requires.
Encrypt an .env file before committing
- Open the AES-256-GCM Encryptor.
- Switch to file mode and select your .env file, or paste its contents into the text area.
- Choose password-based encryption and enter a strong passphrase - at least 12 random characters, ideally a passphrase of four or more words.
- Encrypt and save the output as .env.enc (or env.enc).
- Remove the plaintext file from the working tree and commit only the ciphertext, plus an env.example that documents the variable names without values.
- Share the passphrase with teammates through a channel outside the repository - a password manager, not a chat message or a PR comment.
Warning: There is no recovery if the passphrase is lost, and no security if it leaks. Store it in a team password manager, rotate it on member exit, and treat the ciphertext as only as strong as the passphrase.
Decrypting when a teammate pulls the repository
- Fetch the repository and open the AES-256-GCM Encryptor.
- Select the .env.enc file.
- Enter the shared passphrase and decrypt.
- Copy the values into the local environment or save the plaintext file locally - and make sure it is ignored by git.
Rotation and incident response
Encrypting secrets reduces exposure, but if a plaintext .env was ever committed, assume every secret in it is compromised and rotate them - even if you later remove or encrypt the file.
When a teammate who knew the passphrase leaves the team, rotate the passphrase and re-encrypt the file. Better: rotate the secrets themselves so the old ciphertext becomes useless.
Add a check to CI that fails when a plaintext .env file appears in a diff. A few lines of script are cheaper than the cleanup that follows a leak.
FAQ
Q.Is encrypting the .env file enough?
A.It protects the file contents in the repository, but it does not fix weak passphrases, key sharing mistakes, or secrets that already leaked in plaintext. Combine encryption with gitignore, secret managers, and rotation.
Q.Can I encrypt just one secret instead of the whole file?
A.Yes - encrypt individual values and store them as environment variables like API_KEY=$(decrypt ...). Whole-file encryption is simpler for small configs; per-value encryption gives finer control and is closer to how secret managers work.
Q.What happens if the passphrase is lost?
A.The ciphertext is unrecoverable. There is no backdoor in AES-256-GCM. Keep the passphrase in a team password manager and make losing it a process event, not a recovery problem.
Q.I already committed a plaintext .env. What now?
A.Rotate every secret in that file immediately - history and clones still contain it. Then add it to .gitignore, encrypt future copies, and consider history rewriting only for very small private repositories where you understand the consequences.
Q.Is it safe to encrypt my .env in a browser tool?
A.Only if the tool is truly client-side. The encryptor on this site runs entirely in your browser with Web Crypto API - nothing is uploaded. Verify the same property for any tool you use: check that encryption happens locally and the page makes no network request with your data.
References
- NIST SP 800-38D – Galois/Counter Mode (GCM): https://csrc.nist.gov/pubs/sp/800/38/d/final
- RFC 5116 – An Interface and Algorithms for Authenticated Encryption: https://www.rfc-editor.org/rfc/rfc5116
- NIST SP 800-132 – Password-Based Key Derivation (PBKDF2): https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf
- OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
Encrypt your environment file
AES-256-GCM with a passphrase, entirely client-side. No upload, no account.
Encrypt first, or better, don't commit at all
Secrets in git are a permanent liability. Prefer gitignore and secret managers; when a versioned copy is unavoidable, encrypt the file locally with a strong passphrase and commit only ciphertext.
Encrypt and decrypt .env files in your browser with the AES-256-GCM Encryptor - nothing leaves your device.
Related Articles
How to Decrypt AES-256-GCM Locally
Decrypting AES-256-GCM is straightforward when you have the password and the right metadata. Here is the exact workflow—and the mistakes that break decryption.
bcrypt vs Argon2: Password Hashing
bcrypt has protected passwords for decades; Argon2 is the modern, memory-hard recommendation. Here is how they compare and when to use each in 2026.
QR Code Printing: Size, Contrast, Materials
A QR code that fails to scan on paper is a broken link. Get the minimum size, contrast, error correction, and quiet-zone rules right before sending the file to print.
Developer Security Tools: Zero-Knowledge Guide
The tools you reach for with sensitive data should not see that data. A guide to the zero-knowledge security toolbox: what each tool does, when to use it, and how to verify it.
Verify Downloaded ISO Checksums: Linux, Windows, and macOS
A corrupted ISO can fail hours into an install. Verify the SHA-256 checksum before you burn or write it, and never upload the file to do it.
AES-GCM vs ChaCha20-Poly1305
Both encrypt and authenticate in one pass. AES-GCM wins on hardware-accelerated chips; ChaCha20-Poly1305 wins in pure software and on small devices. The rest of the decision is your platform.