.env File Formatter

Format, sort, and validate .env environment variable files

About This Tool

.env files store environment variables as KEY=VALUE pairs, one per line, used to configure applications without hardcoding secrets. The format is loose — different parsers disagree on quoting, escaping, and inline comments.

The formatter parses input, sorts keys alphabetically or groups by prefix, normalizes quoting, strips trailing whitespace, and flags duplicates. Optional output includes an .env.example version with values stripped, ready to commit.

The .env format originated with the dotenv package for Ruby in 2012 and was ported to most ecosystems since. There's no formal spec — different libraries diverge on whitespace handling, multi-line values, comment syntax, and variable interpolation. Most agree on the basics: KEY=VALUE per line, # for line comments, blank lines ignored, optional double or single quotes around values. Beyond that, dotenv (Node), python-dotenv, dotenvx, and Ruby's original implementation each handle edge cases differently. The formatter normalizes to a conservative dialect that all major parsers accept.

A worked example. Input:

DB_HOST=localhost DB_PORT = 5432 API_KEY="sk-abc123" DB_HOST=postgres.local # auth section JWT_SECRET=hunter2

The formatter strips the space around the equals (DB_PORT), flags the duplicate DB_HOST, normalizes quoting (API_KEY keeps quotes because the value contains punctuation; JWT_SECRET stays unquoted), sorts keys alphabetically or groups by prefix, and outputs a clean version. Duplicate keys in dotenv are environment-specific: most parsers take the last occurrence, but some take the first, which causes hard-to-find configuration bugs.

Limitations and edge cases worth knowing. Multi-line values like RSA private keys are the biggest portability problem. Some parsers accept literal newlines inside double-quoted strings; others require \n escapes; older parsers truncate at the first newline. The portable approach is single-line with \n escapes and verify the resulting string parses correctly. Variable interpolation (${OTHER_VAR}) is unevenly supported — production systems usually avoid it because behavior across deploy environments differs. The formatter preserves literal text rather than resolving references. Comments mid-line (KEY=value # inline comment) are accepted by some parsers and treat the comment as part of the value by others; safer to put comments on their own lines. Finally, .env files often leak — the original .gitignore omitting them, accidentally committing during onboarding, or syncing to cloud backups. Treat .env files as secrets and rotate any value that touches a public surface.

The about text and FAQ on this page were drafted with AI assistance and reviewed by a member of the Coherence Daddy team before publishing. See our Content Policy for editorial standards.

Frequently Asked Questions