/

Environment Var Formatter

Processed Client Side

Parse a .env file into a clean table and JSON, or build a .env file from a JSON object. Handles quotes, comments, and export prefixes.

.env file
.envLength: 152Lines: 7Size: 152 BytesCursor: 1:1
Variables
6 vars
NODE_ENVproduction
PORT3000
API_URLhttps://api.example.com
DB_PASSWORDs3cr3t p@ss
FEATURE_FLAGSbeta,dark-mode
EMPTY(empty)

Bookmark this tool now — skip the search next time you need it.

About Environment Var Formatter

This tool runs entirely in your browser. Whatever you paste is processed on your own device and is never uploaded, logged, or sent to any server.

The .env Formatter converts between a .env file and a JSON object, in both directions. Paste a .env and get structured JSON — or a clean table of every variable — and paste a JSON object to get a properly quoted .env file back. It handles the details that trip up a quick hand-conversion: export prefixes, comments, blank lines, and values wrapped in single or double quotes. The direction you need depends on the day: JSON for a deployment platform, a CI secret block, or a Docker config, and .env for local development when someone hands you a JSON blob and you just want to run the app.

Key features

  • Two directions: .env to JSON, and JSON back to a .env file
  • Handles export KEY=value, # comment lines, and blank lines without complaint
  • Strips surrounding single or double quotes from values on the way in
  • Adds quotes on the way out only where they are needed — values containing spaces, # or quote characters
  • Escapes embedded double quotes so the generated .env parses correctly
  • A table view of every parsed variable as well as the JSON view, for scanning a long file quickly
  • Key order preserved in both directions, so a diff against the original stays readable
  • Syntax highlighting for both the .env and the JSON side
  • Runs entirely in your browser — real credentials never leave your machine

How to use it

  1. Choose the direction you need: .env → JSON or JSON → .env.
  2. Paste your file into the input pane.
  3. For .env input, switch between the table view and the JSON view depending on whether you are reading or copying.
  4. Check the output for values that needed quoting, then copy it.

Tips & common mistakes

  • Everything in a .env file is a string. PORT=3000 arrives in your application as "3000", and DEBUG=false is a non-empty string that is truthy in most languages — a very common source of bugs.
  • Quote any value containing a space, a # or a quote character. An unquoted # starts a comment, which silently truncates the rest of the value.
  • This tool is a conversion step, not a vault. Convert real production secrets locally if you must, but never paste them anywhere that logs or stores what you typed.
  • Commit a .env.example with every key present and the values blanked. It documents what the application needs without leaking anything, and it is what new team members will look for first.
  • Multi-line values such as a private key do not survive a plain .env round trip cleanly. Base64-encode them into a single line, or keep them in a secret manager instead.
  • The export prefix is stripped on the way in and not re-added on the way out. It is only meaningful when a file is sourced by a shell; dotenv libraries ignore it either way.
  • Duplicate keys resolve to the last one when the JSON object is built, matching how most dotenv loaders behave — worth checking if a variable seems to have the wrong value.
  • Writing the Dockerfile that will read this file? The Dockerfile Helper checks it for common mistakes.

Related tools

Browse all 12 Development tools

Frequently asked questions

10

Choose the .env → JSON direction and paste your file. Comments, blank lines, and export prefixes are handled, and quoted values are unwrapped. You can view the result as JSON or as a table.

Switch the direction to JSON → .env and paste an object. Each key becomes a KEY=value line, with quotes added only around values that need them.

No — everything is a string. PORT=3000 reaches your application as "3000", and DEBUG=false is a non-empty string that most languages treat as truthy. Convert types explicitly in your code.

Whenever it contains a space, a # or a quote character. An unquoted # begins a comment, which silently truncates everything after it.

Yes. export KEY=value is parsed correctly and the prefix is dropped. It only means anything when a file is sourced by a shell — dotenv libraries ignore it.

No. Comment lines are skipped when parsing, because a JSON object has nowhere to put them. Keep your commented original if the comments matter.

The conversion runs entirely in your browser and nothing is transmitted, so no value reaches a server. Even so, treat real credentials carefully and prefer a secret manager for anything long-lived.

They do not survive a plain .env round trip cleanly. Base64-encode the value into a single line and decode it in your application, or store it in a secret manager instead.

The last occurrence wins when the JSON object is built, which matches how most dotenv loaders behave. It is worth checking if a variable seems to be picking up the wrong value.

A committed copy of your .env with every key present and the values blank. It documents what the application needs without leaking anything, and it is the first thing a new team member looks for.