Format, sort, and validate .env files. Auto-detects secrets and generates a safe .env.example template. 100% browser-based, nothing uploaded.
A messy .env file silently breaks deployments — mixed quoting causes parsing errors in one library and not another, inconsistent casing trips up case-sensitive lookups, and unsorted keys make diffs unreadable. A consistent format is one of those small habits that prevents large 3am incidents.
The single biggest .env mistake is committing it to git. Public GitHub repos are crawled by bots within minutes; a leaked AWS key can rack up thousands of dollars in compute before you notice. The fix is twofold: add .env to .gitignore, and commit a .env.example template so collaborators know which variables to provide.
It does three things at once: validates KEY=VALUE syntax (flagging lines that won't parse in any dotenv library), formats the file consistently (sort, uppercase, quote-when-needed), and generates a safe .env.example by replacing any value with a key matching common secret patterns (KEY, TOKEN, SECRET, PASSWORD, etc.) with a placeholder.
It doesn't validate that your variables are actually used by your app, doesn't enforce a schema (use envalid or zod for that), and doesn't support multiline values or variable interpolation. The goal is a clean baseline; project-specific validation belongs in your runtime code.
Assume compromise. Rotate the credential immediately, then use BFG Repo-Cleaner or git filter-repo to scrub the secret from history, force-push, and ask collaborators to re-clone. Just deleting the file in a new commit isn't enough — git history preserves everything.
No. Parsing, formatting, and secret detection all happen in your browser using plain JavaScript regexes. Nothing is sent to a server. You can verify by opening DevTools → Network tab while you paste.
Any key whose name matches KEY, TOKEN, SECRET, PASSWORD, PWD, API, PRIVATE, DSN, or AUTH (case-insensitive). The tool highlights these and replaces their values with placeholders in the generated .env.example. Treat the heuristic as a starting point, not a guarantee — review manually.
Committing .env to git leaks production secrets. The standard practice is to commit .env.example (with empty or placeholder values) so teammates know which variables they need to define locally — without exposing real credentials.
Most .env parsers treat values literally — VAR=hello world keeps the space. But values containing #, \ , or quotes need to be wrapped in double quotes for safe parsing across dotenv libraries. The 'quote when needed' option handles this automatically.
Not yet. This formatter focuses on the common case: KEY=value pairs, one per line, with optional comments. For advanced syntax (multiline, ${'