.env to JSON Converter

This tool handles sensitive keys

.env files usually contain database passwords, API keys, payment secrets, and JWT signing keys. That's why we built this tool differently from others — we've intentionally left out input auto-saving (to localStorage). While other converters might save your work if you accidentally close a tab, here, your data disappears when the tab is closed.

All conversions happen entirely within this page, and nothing is sent to any server. However, there are still ways your data can be leaked outside the browser, so stick to the basics of security.

• Don't use this tool while screen sharing or recording. There are many cases of security incidents caused by keys captured in screenshots.
• Using the Copy button leaves the value in your clipboard. On systems with clipboard history enabled (like Win+V on Windows or various app launchers), these values can be retrieved later.
• Never use this on a public PC or someone else's laptop.
• If you suspect a key has been exposed, the only solution is to revoke and reissue it. Masking the key or deleting the file is not enough.

What happens when you commit .env

It's common knowledge to add .env to your .gitignore, but accidents usually happen with that "first commit." In the early stages of a project, it's easy to commit the .env file first and add .gitignore later. Once a file is tracked, adding it to .gitignore has no effect.

More importantly, even if you make a commit that deletes the file, the original content remains in the previous commit. Anyone can read it with `git log -p`. To completely remove it from history, you need to use a tool like `filter-repo` to rewrite history and force-push, but the old history might still exist in local copies of anyone who has already cloned the repository.

If it's a public repository, you don't have much time. There have been multiple reports of cloud keys from public GitHub repositories being discovered and exploited by automated scanners within minutes. That's why the number one priority when you discover a leak is to revoke and reissue the key, not clean up the history. Cleanup comes second.

# To stop tracking an already-committed .env (it remains in history)
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "chore: stop tracking .env"

# If a key is leaked, follow this order
# 1) Immediately revoke the key/password and issue a new one
# 2) Check access logs for signs of misuse
# 3) Then, clean the history (e.g., with git filter-repo)

The .env.example convention

You should commit .env.example to your repository, not .env itself. This is a file that contains the list of keys and their format, but with empty or dummy values. It helps new team members get started by copying this file, and it makes required environment variables visible during code reviews.

To create one with this tool, paste your .env content, set the output format to `.env`, and enable "Sort keys (A→Z)" to get an organized list. From there, just clear out the values and commit the file. You can use the "Keys" count in the stats to check for discrepancies between your .env and .env.example files, catching cases where someone added a new variable but forgot to update the example.

# .env.example — structure only, no values
DB_HOST=127.0.0.1
DB_PORT=3306
DB_PASSWORD=
JWT_SECRET=
SLACK_WEBHOOK_URL=
NODE_ENV=development

# Adding comments about where to get the keys speeds up onboarding
# STRIPE_SECRET_KEY=   # Get from the Stripe Developer Dashboard

The 12-Factor App and Switching Formats

The 12-Factor App principle of separating configuration from code by storing it in environment variables has become widely adopted. This means the same set of values often needs to be moved between different formats: .env for local development, the `environment` block in docker-compose for containers, ConfigMaps/Secrets for Kubernetes, and `export` commands for checking on a server. Converting these by hand inevitably leads to errors with quotes and newlines.

ConfigMap vs. Secret — a Secret Is Not Encrypted

This is a common misconception. By default, a Kubernetes Secret is only base64 encoded, not encrypted. Anyone can reverse base64 with a one-line command. Encryption at rest (in etcd) is a separate setting that your cluster administrator must enable.

So why use Secrets? The main reasons are to enable separate access controls (RBAC), reduce exposure in logs and events, and follow operational best practice by clearly marking data as "secret." If you put an API key in a ConfigMap, anyone with permission to view ConfigMaps can see it.

• This tool's Secret output uses the `stringData` format, which doesn't require base64 encoding, so you can paste the values directly.
• The general rule is to put things like ports, modes, external URLs, and timeouts in a ConfigMap, and put API keys, database passwords, tokens, and signing keys in a Secret.
• Multi-line values (like RSA private keys or service account JSON) are also supported. This tool outputs them as YAML block scalars for ConfigMap/Secret format and with escape notation for .env format. Check the "Multi-line values" count in the stats.
• Committing a generated Secret YAML file to your repository is the same as committing your .env file. Use tools like Sealed Secrets or External Secrets, or inject the values from your CI/CD secrets store.