.env File Generator
Build a .env file and generate a safe .env.example alongside it.
Values containing spaces, #, quotes or backslashes are quoted and escaped automatically. Add .env to your .gitignore and commit only the example file.
About this tool
Assemble environment variables into a valid .env file, with quoting applied automatically to values containing spaces or special characters. It also produces the matching .env.example with values blanked — the file you actually commit.
How to use it
- Add your keys and values, grouped into sections if you like.
- Mark any secrets so they are emptied in the example file.
- Copy the .env, then copy the .env.example for version control.
When a value needs quotes
.env files look simple and have a surprising number of edge cases, because there is no standard — each library parses slightly differently.
Quotes are required when a value contains spaces, a # (which otherwise starts a comment), or a line break. This tool adds them automatically only when needed, so the file stays readable.
Single and double quotes differ in most parsers. Double quotes allow escape sequences like \n to be interpreted; single quotes keep everything literal. If your value contains a literal backslash — a Windows path, a regex — single quotes are safer.
Trailing spaces are invisible and load-bearing. KEY=value includes the space in many parsers. This is a genuinely nasty bug to find, which is why values here are trimmed and quoted if the spacing is intentional.
Multi-line values need quoting and are not universally supported. For a private key or certificate, Base64-encode it into a single line instead.
Why you commit .env.example
.env belongs in .gitignore — it holds credentials. But that creates a problem: someone cloning the repository has no idea which variables the application needs. They run it, get a blank error, and have to read the source to find out.
.env.example solves that. Same keys, same comments, values removed for anything secret. It is documentation that cannot drift far from reality, because a missing key shows up the first time someone sets the project up.
Conventions worth following:
- Keep the key order identical between the two files
- Leave non-secret defaults in place —
APP_ENV=local,PORT=3000— so fewer things need filling in - Group related keys with a comment header
- Never leave a real credential in the example file, including "test" keys from a payment provider
This tool produces both at once and blanks anything you mark as a secret.
Frequently asked questions
- When do values need quotes?
- Whenever they contain spaces, the # character, or a line break. Values are quoted automatically when required, and left bare when not, which keeps the file readable.
- Why generate a .env.example?
- Because .env is gitignored, a new developer cloning the repo has no idea which variables exist. The example file documents the keys without leaking the values.
- Is it safe to put real secrets in here?
- The file is assembled in your browser and nothing is transmitted, so no value reaches a server. Nothing is written to storage either, so closing the tab discards everything.