Format your .env file into a neat, readable layout directly in your browser with client-only processing.
.env, .env.local, .env.production, or .env.example content into the Input panel. The parser accepts UTF-8 input and handles all the common dialect quirks — # comments on their own line, blank-line groupings between sections, single/double/backtick-quoted values, export prefixes from shell-sourced files, and multi-line values written either with \n escapes or as a real linebreak inside double quotes.=, collapses runs of blank lines down to a single separator, preserves your # comments and section groupings, and aligns quote style consistently. Duplicate keys are flagged inline (the last assignment wins at load time for most loaders — silent overrides are a frequent production bug). Syntax problems like an unterminated quote, a stray colon instead of =, or a key starting with a digit surface with the offending line number."..." as the canonical form), quote only when needed (matches the dotenv convention of unquoted bare values), or preserve as-is. Optional toggles control whether keys are sorted alphabetically, whether export prefixes are stripped, and whether blank lines between groups are kept..env file. Everything runs in your browser session — no upload, no signup, no telemetry. Your secrets — DATABASE_URL, STRIPE_SECRET_KEY, JWT signing keys — never leave the tab.The .env file is the de-facto standard for local development configuration across the JavaScript, Python, Ruby, and Go ecosystems. It was popularised by the 12-factor app methodology (factor III: "Store config in the environment") and the original motdotla/dotenv Node library, and it has since spread to python-dotenv, direnv, godotenv, Rust's dotenvy, Docker Compose's env_file: directive, GitHub Actions' dotenv-action, and almost every modern web framework. The format looks trivially simple — one KEY=value per line — but it has no formal spec, so each loader implements slightly different rules around quoting, multi-line values, comments, and variable interpolation. A clean, normalised file makes code review easier, surfaces duplicate keys, and prevents the silent overrides that bite teams in production.
.env.example templates committed to Git — Every project should commit a .env.example (with placeholder values) and keep .env itself in .gitignore. A formatted template — sorted keys, consistent quoting, grouped sections like # Database, # Auth, # Third-party APIs — gives new contributors a frictionless onboarding path and serves as documentation for which variables exist.API_KEY=old then later API_KEY=new), most loaders silently take the last value. The bug only surfaces when an environment behaves differently than the file appears to specify. The formatter flags every duplicate so you can dedupe before deploy..env plugins reflow files in incompatible ways: some quote every value, some quote nothing, some swap single quotes for doubles. Formatting pins a single convention so git diff shows only real changes, not whitespace churn between editors.pass#word written unquoted is parsed as pass (the # starts a comment in many loaders). A URL with spaces, a JSON blob, or a value containing $ needs quoting to survive interpolation. The formatter quotes anything ambiguous so values round-trip cleanly through whichever loader your stack uses.export prefixes for shell-sourced configs — If you source .env from bash directly (rather than reading it through a library), every line needs export KEY=value. The formatter can add or strip the prefix depending on whether the file is meant for a dotenv loader (most ignore export) or for shell sourcing..env typically doesn't crash the app — the loader just silently skips the bad line, and a feature flag or DB credential goes unset. Validating syntax up front catches stray smart quotes, BOM bytes, mismatched multi-line quotes, and Windows CRLF artefacts before they cause a 2 AM page.The .env format has no formal spec — each loader (motdotla/dotenv, python-dotenv, godotenv, dotenvy, direnv, dotenvx) differs in subtle ways. The rules below cover the intersection that works across the major loaders.
| Construct | Example | Notes |
|---|---|---|
| Bare assignment | DB_HOST=localhost |
Unquoted value; trimmed of surrounding whitespace |
| Double-quoted value | GREETING="hello world" |
Required if value contains spaces or #; \n/\t escapes interpreted |
| Single-quoted value | RAW='C:\path\to\file' |
Literal — escapes and ${VAR} interpolation are NOT processed |
| Backtick-quoted value | KEY= `mixed "and 'quotes` |
motdotla/dotenv supports backticks for values containing both quote types |
| Comment (line) | # database settings |
# as the first non-blank char of a line |
| Comment (trailing) | DB_HOST=localhost # primary DB |
Inline # after an unquoted value is a comment in python-dotenv and motdotla/dotenv; wrap in quotes to keep a literal # |
| Blank line | (empty) | Ignored by all loaders; used for visual grouping |
export prefix |
export DB_HOST=localhost |
Ignored by most dotenv loaders; required if you source the file from bash |
| Multi-line (literal) | KEY="line oneline two" |
Real newlines inside double quotes — supported since motdotla/dotenv v15 and in python-dotenv |
| Multi-line (escape) | KEY="line one\nline two" |
\n inside double quotes is expanded to a newline |
| Variable interpolation | URL=${PROTO}://${HOST} |
Works in python-dotenv, dotenvx, dotenv-expand, direnv. NOT supported by base motdotla/dotenv |
| Default value | PORT=${PORT:-3000} |
dotenvx and shell-style defaulting; not universal |
| Empty value | OPTIONAL_FLAG= |
Legal; reads back as the empty string |
| Loader | Ecosystem | Variable interpolation | Multi-line | Notes |
|---|---|---|---|---|
motdotla/dotenv |
Node.js | No (use dotenv-expand or dotenvx) |
Yes (since v15) | The original; default for Create React App, Next.js, Vite |
dotenvx |
Cross-language CLI | Yes — ${VAR}, ${VAR:-default}, command substitution |
Yes (backticks for mixed quotes) | Successor to motdotla/dotenv; also handles encryption |
python-dotenv |
Python | Yes (built-in ${VAR} expansion) |
Yes | Used by Flask, Django (via django-environ), FastAPI |
godotenv |
Go | Yes (POSIX-style ${VAR} and $VAR) |
Yes | Joho's port of Ruby dotenv |
dotenvy |
Rust | Optional via dotenvy::var_os patterns |
Yes | Active fork of the abandoned dotenv crate |
direnv |
Shell | Yes (full bash expressions) | Yes | Sources .envrc (and optionally .env) when you cd into a dir |
Docker Compose env_file: |
Docker | Limited — no interpolation in the loaded values themselves | Lines only; no real newlines | Comments must be on their own line; quotes are NOT stripped (a known quirk) |
| Spring Boot | JVM | N/A — uses application.properties/.yml, not .env |
N/A | Spring Cloud Config or spring-dotenv add .env support |
A # as the first non-blank character of a line marks the rest of the line as a comment. motdotla/dotenv and python-dotenv also support trailing inline comments: KEY=value # comment parses the value as value and discards the comment. Two important quirks: (1) if your value itself contains a #, you must quote the value or the # and everything after will be stripped — PASSWORD=p#1 reads back as p; write PASSWORD="p#1" instead. (2) Docker Compose's env_file: directive does NOT support inline comments — the entire line including the # becomes part of the value, which has surprised many teams. Put comments on their own line if you need cross-loader portability.
\n?There are two approaches, and the right one depends on your loader version. Modern approach (preferred): wrap the value in double quotes and just type real newlines inside — motdotla/dotenv has supported this since v15.0.0 (released 2022), and python-dotenv, godotenv, and dotenvy all handle it. This is ideal for multi-line secrets like PEM-encoded private keys, JSON blobs, or SSH keys. Legacy approach: use \n escape sequences inside double quotes — KEY="line one\nline two". Both produce the same in-memory value. What you cannot do with most dotenv loaders is bash-style backslash continuation (KEY=line one \ then next line) — that works in shell source but not in dotenv parsers.
${OTHER_KEY} interpolation work?It depends entirely on which loader you use. Base motdotla/dotenv does NOT expand variables — DB_URL=postgres://${DB_USER}@host is stored literally as the string postgres://${DB_USER}@host. You need dotenv-expand or dotenvx for expansion in Node. python-dotenv DOES expand ${VAR} by default. godotenv expands POSIX-style. direnv runs the file through bash, so full shell expansion works. If you write .env files meant to be portable across loaders, avoid ${VAR} references — or document explicitly that the file requires dotenv-expand. Single-quoted values never interpolate, even in loaders that support expansion.
Quote any value that contains spaces (API_NAME="My Cool API"), a # symbol (PASSWORD="p#1"), starts or ends with whitespace you want preserved, contains a $ you don't want expanded, or spans multiple lines. Use double quotes if you want escape sequences (\n, \t) interpreted and ${VAR} expansion to apply (in loaders that support it). Use single quotes if you want the value literal — useful for regex patterns, Windows paths, or values containing ${...} that you don't want expanded. Bare unquoted values are fine for typical alphanumeric strings, URLs without spaces, integers, and booleans. The formatter on this page can normalise to a single style across the whole file.
export prefix?Almost certainly not. Of the dotenv loaders surveyed above, none require export — they all accept lines with or without it and treat them identically. The export keyword only matters if you literally source .env from a bash shell (so the variable is exported to child processes) — in that case every line needs export. If you're using dotenv via require('dotenv').config(), from dotenv import load_dotenv, or any equivalent, you can leave export off. The formatter can strip or add the prefix in bulk depending on whether the file is meant for source or for a library.
.env to Git?No. This is one of the most consequential rules in .env practice — your .env file contains secrets (database URLs with passwords, API keys, JWT signing keys, OAuth client secrets) that must never end up in a public or even a private Git history. Add .env (and .env.local, .env.*.local) to your .gitignore from day one. Instead, commit a .env.example (or .env.template) with the same keys but placeholder values — empty strings, fake credentials, or descriptive text like your_stripe_publishable_key_here. New contributors copy .env.example to .env and fill in real values. If you accidentally commit a real secret, rotate the credential immediately (history rewriting alone is not enough — assume the value is compromised) and consider tools like git-secrets or GitHub's secret-scanning to catch future leaks.
.env even apply?Spring Boot is the odd one out here. The JVM ecosystem standardised on application.properties and application.yml long before .env became popular, and Spring's @Value("${spring.datasource.url}") resolves from those files plus environment variables and command-line args — there's no built-in .env loader. You have three options: (1) export the values as real environment variables (Docker, Kubernetes, systemd, CI all support this — Spring picks them up because SPRING_DATASOURCE_URL maps to spring.datasource.url); (2) add the spring-dotenv third-party library or me.paulschwarz:spring-dotenv so Spring reads .env alongside application.properties; (3) keep secrets in application-local.properties (gitignored) and use Spring profiles. For pure JVM apps, Spring's application.properties/application.yml is the canonical config format — there's no need for .env. For converting between adjacent config formats, see YAML to JSON and JSON to YAML.
By default, no — keys stay in the order you wrote them, which preserves the intent of grouped sections (# Database block, # Auth block, # Feature flags block). Sorting is opt-in via a toggle, because alphabetic sorting destroys those visual groupings even though it can make diffs cleaner across machine-generated files. If you do enable sorting, the formatter sorts within each blank-line-separated group rather than across the whole file, so your section headers stay meaningful. Comments are kept attached to the key they precede.
No. The .env Formatter runs entirely in your browser session — your file never leaves the tab. There are no network requests after the initial page load, so secrets in DATABASE_URL, STRIPE_SECRET_KEY, JWT signing keys, OAuth tokens, and any other sensitive values stay on your machine. The page also works offline once loaded. For pretty-printing related formats see the JSON Formatter for JSON payloads, or use YAML to JSON when migrating config between formats.