.ENV Beautifier

What this page is for

Paste the contents of a .env file and it comes back tidied: one variable per line, no stray spaces around the equals sign, no leading indentation, consistent line endings. Comments and blank lines survive. Keys stay in the order you wrote them.

It is a normaliser, not a validator. It does not know which variables your application expects, does not check that values are correct, does not detect duplicates and does not warn about secrets. It only reshapes text.

The exact rules

The behaviour is small enough to describe completely, which is useful because .env files often carry values where a careless transformation would be damaging.

1. Each line has its surrounding whitespace removed.
2. A line that is empty stays empty.
3. A line starting with # is kept as a comment, with its outer whitespace trimmed.
4. Any other line is split at the first equals sign into a key and a value.
5. The key and the value are each trimmed of spaces.
6. The line is written back as key=value.
7. Line endings are normalised to the server's newline convention.

Nothing else happens. Quotes are not removed, values are not re-escaped, comments after a value are not stripped, and duplicate keys are not merged.

A worked example

Input, with indentation and a missing equals sign:

  # note
APP_NAME="My App"
EMPTY=
export TOKEN=abc # inline
BROKEN

MULTI="line1
line2"

Output:

# note
APP_NAME="My App"
EMPTY=
export TOKEN=abc # inline
BROKEN=

MULTI="line1
line2"=

Every rule and every trap is visible there. The comment lost its indentation but kept its text. The quoted value kept its quotes. The blank line survived. BROKEN, which had no equals sign, became BROKEN=. The export prefix stayed inside the key. The inline comment stayed part of the value. And the multi-line value was broken apart, turning its second line into a new key.

The multi-line problem

That last result is the one to watch. Strictly, a .env file has no multi-line values; quoting a value across lines is a convention some loaders accept and others reject. This tool treats every line independently, so a quoted value spanning two lines is split into a valid-looking first line and a nonsense second key.

If a value genuinely spans lines — a PEM key, a JSON blob, a certificate — do not run it through this page. Encode it on one line first, or edit by hand. The same applies to values containing a newline escape written as literal text; those are fine, since they are a single line.

What it does not change

• Quotes. "value" and 'value' stay as typed.
• Inline comments. KEY=value # note keeps the note in the value; whether your loader treats it as a comment depends on the loader.
• Variable references. ${OTHER_VAR} is left alone, not expanded.
• Escapes. Backslashes and escaped quotes are untouched.
• Order and duplicates. Lines stay where they are; a repeated key stays repeated.
• Case. Keys are not upper-cased.

That restraint is deliberate. A formatter that "helpfully" removed quotes or expanded references could silently change a password, a connection string or a regex. This one changes only the whitespace it was designed to change.

The export prefix, and other shell habits

Lines copied from a shell session often begin with export. Because the parser splits on the first equals sign, export TOKEN=abc produces the key export TOKEN — including the space. That is invalid as a variable name in most loaders and will usually be ignored or rejected. Remove the prefix before formatting, or fix it afterwards in the output box.

Other common leftovers behave similarly: a leading set, a Windows SET, or a stray prompt character becomes part of the key. The formatter has no way to know which words are shell syntax and which are names.

Why minify looks identical

The second mode exists because the page shares its interface with other formatters. For .env files there is no safe way to compress beyond normalising whitespace, so minify performs exactly the same transformation as beautify. Choosing it is harmless; it simply does not make the file smaller.

Using it

1. Paste the file into the manual tab, or fetch a raw file by URL. Do not fetch a private URL that requires your session.
2. Leave the language on ENV and the mode on Beautify.
3. Press the convert button. The cleaned text appears on the right.
4. Check the counters: a big change in length usually means indentation was removed or lines were joined.
5. Read the whole output before copying. The transformation is simple, but it cannot tell you that a key was mistyped.
6. Copy the text or download it as beautify-output.env.

Where it helps

• Files edited by several people. Alignment drifts; this resets it.
• Copy-paste from chat or tickets. Indentation and trailing spaces are common and invisible.
• Windows-to-Linux transfers. Line endings are normalised, which removes a class of "command not found" style failures caused by carriage returns.
• Preparing a diff. Normalising both versions makes real changes stand out.
• Reading a dense file. One variable per line is easier to scan than wrapped paragraphs.

It is not a tool for generating a .env.example: it has no idea which values are secret, so it cannot strip them for you. Do that by hand, replacing values with placeholders.

Privacy

The text is posted to the server for processing. A .env file is, by definition, the file most likely to contain database passwords, API keys and signing secrets. Pasting a production file into any web page is a bad trade for tidier whitespace. Use a local editor for real secrets, and reserve this page for templates, examples or files whose values are already placeholders.

Limits

200,000 characters per request, one file at a time, no validation, no duplicate detection, no secret scanning, no sorting, no key renaming, no comment stripping and no multi-line handling. There is no diff view and no way to export a template with values removed. The output is plain text with no metadata.

Common mistakes

• Pasting production secrets. The request carries them to the server.
• Formatting a multi-line value. It will be split into a broken key.
• Leaving an export prefix. It becomes part of the key name.
• Assuming inline comments are removed. They stay in the value.
• Expecting validation. A clean-looking file can still be wrong.
• Using minify to shrink the file. It produces the same text.

Frequently Asked Questions