Why was my key rejected?

Because it is not a name a `.env` file can hold. Letters, digits, `_` and `.`, not starting with a digit — anything else, such as `my key` or `2fa`, is refused with the key quoted in the message. The reason is blunt: `my key=1` is not an assignment, and no shell or dotenv reader will treat it as one.

When are values quoted?

Only when they would otherwise be misread: whitespace, `#`, a quote or a backslash in the value. `PORT=3000` stays bare, `NAME="my app"` gets quotes because the space would end the value early, and a newline is written `\n` inside the quotes so the variable stays on one line.

Do lowercase names work?

Yes. Uppercase is a convention, not a rule, and this tool does not rewrite your keys to enforce it — renaming `port` to `PORT` would hand you a file that no longer matches the code reading it. A name is accepted or refused on whether it is valid, not on how it is capitalised.

JSON to .env — Ready for Docker and CI

Convert a flat JSON object into a .env file. Names are checked and values quoted where a shell needs it, ready for Docker or your pipeline.

Instant Private Zero cookies

What this tool does

A flat JSON object becomes a .env file, one assignment per line.

{ "PORT": 3000, "NAME": "my app", "DEBUG": true }

PORT=3000
NAME="my app"
DEBUG=true

Values keep their text: a number, a boolean and a string with the same characters all come out the same, because a .env file holds nothing but text.

A name a reader would refuse now stops the conversion

Variable names are checked before anything is written: letters, digits, _ and ., never starting with a digit. my key and 2fa are refused, with the offending key named.

This deserves stating plainly, because it is a defect this tool used to have. It accepted any key and wrote it out, so {"my key": "1"} produced:

my key=1

a line that the .env reader on this same site rejects, and that a shell would not treat as an assignment either. A converter whose output its own inverse refuses is a converter with a bug. It was found while writing this page and fixed.

Quotes only where they are needed

A value is quoted when leaving it bare would change where it ends: it contains whitespace, a # that would start a comment, a quote or a backslash.

{ "GREETING": "hello world", "NOTE": "a # b" }

GREETING="hello world"
NOTE="a # b"

Inside quotes, a real newline is written \n — a variable is one line, and a line break in the middle of a value would end the assignment there.

What a .env file cannot hold

Nesting has no place in it: {"db": {"host": "x"}} is refused, with db named, rather than invented into DB_HOST or db.host. Which of those your application expects is not something the JSON says.

And null becomes an empty value, KEY=, which reads back as an empty string. That distinction is simply absent from the format — worth knowing before you rely on it.

Private by design

Everything runs locally in your browser with JavaScript. Your data is never uploaded, which makes the tool safe for sensitive content, and it keeps working offline.

Frequently asked questions

Why was my key rejected?: Because it is not a name a `.env` file can hold. Letters, digits, `_` and `.`, not starting with a digit — anything else, such as `my key` or `2fa`, is refused with the key quoted in the message. The reason is blunt: `my key=1` is not an assignment, and no shell or dotenv reader will treat it as one.
When are values quoted?: Only when they would otherwise be misread: whitespace, `#`, a quote or a backslash in the value. `PORT=3000` stays bare, `NAME="my app"` gets quotes because the space would end the value early, and a newline is written `\n` inside the quotes so the variable stays on one line.
Do lowercase names work?: Yes. Uppercase is a convention, not a rule, and this tool does not rewrite your keys to enforce it — renaming `port` to `PORT` would hand you a file that no longer matches the code reading it. A name is accepted or refused on whether it is valid, not on how it is capitalised.