There is no dotenv standard
A .env file looks simple enough that everyone wrote their own parser, and they do not agree. Whether # after a value starts a comment, whether \n inside double quotes becomes a newline, whether $OTHER is expanded, whether a value may span lines, whether export is allowed — every one of those varies between the loader in one language and the loader in the next, and sometimes between major versions of the same library.
What this page implements is the intersection that most of them share, and it says so where it guesses. An export prefix is stripped. A # at the start of a line, or after whitespace in an unquoted value, starts a comment. A # inside quotes is an ordinary character. Double-quoted values expand \n, \t, \r and escaped quotes; single-quoted values are taken literally. Variable references are not expanded, because whether they should be is exactly the thing loaders disagree about, and silently substituting would be worse than leaving them alone.
The hash problem, concretely
This is the failure that sends people looking for a converter in the first place. Take a generated password of p@ss word#1. Written unquoted, most loaders read the value as p@ss and treat the rest as a comment, or read p@ss word and drop the fragment after the hash. Written in double quotes it survives intact. The application then fails to authenticate with an error that says nothing about quoting, and the hunt begins in the wrong place.
| Line in the file | Value most loaders produce |
|---|---|
PW=p@ss word#1 | p@ss word or p@ss |
PW="p@ss word#1" | p@ss word#1 |
PW='p@ss word#1' | p@ss word#1 |
PW=p@ss\nword | The six characters, backslash and n included |
PW="p@ss\nword" | Two lines, in loaders that expand escapes |
Quoting for a shell is a different job
Shell export output is not the same problem as env output, and the safe answer is different. For a shell, single quotes are the strong form: everything inside is literal, with no expansion of $, no backtick substitution, no escape processing. The only character that cannot appear inside is a single quote itself, and the standard workaround is to close the quoted run, emit an escaped quote, and open a new one. That is what the export output does, which is why a value containing an apostrophe comes out looking odd and is nevertheless correct.
Double quotes in a shell would be the wrong choice here: a value containing $HOME or a backtick would be expanded by the shell at the moment you paste it, turning a literal into whatever the shell happened to substitute. If you are pasting into an interactive terminal, remember that the whole line usually lands in your shell history file in plain text.
Everything is a string, on both sides
Converting to JSON produces string values, never numbers or booleans, and that is not a shortcut. An environment holds strings; a variable is either unset or it is text. DEBUG=false is the five-character string false, which is why so much code has been caught out by treating it as truthy. Converting in the other direction, a JSON number becomes its text form, a boolean becomes true or false, and null becomes an empty value, which is not the same as being unset — a warning is emitted when that happens.
Nested objects and arrays have no representation at all. They get flattened to their JSON text and flagged, because the reader will have to parse them back, and there is no convention for it. If a configuration has genuine structure, an environment is the wrong transport and a config file is the right one.
What to do with the file once you have converted it
The output box is the end of this page, but not the end of the job. Keep the file out of version control, keep a redacted example checked in alongside so the next person knows what to fill in, and treat any value you converted here as still secret. If you need to hand a value to something that wants it encoded rather than plain, the Base64 encoder is next door; if the variables are feeding an HTTP client, the curl to fetch converter and the header explainer are the two pages you will want after this one.
Questions people ask
Are variable references like $DB_HOST expanded?
No, and the omission is deliberate. Some loaders expand references to other variables in the same file, some expand only against the surrounding process environment, some do neither, and the ones that do expand differ on whether the referenced value has to be defined earlier in the file. Substituting here would produce output that is right for one loader and wrong for another, with no warning. The reference is passed through as written.
Why does my exported value have that strange quote sequence in it?
A single-quoted shell string cannot contain a single quote, so the value has to leave the quoted run, emit an escaped quote, and re-enter it. The result looks wrong and pastes correctly. Single quoting is used rather than double because it stops the shell expanding dollar signs and backticks in your value at the moment you paste the line.
Can it read a value that spans several lines?
Not reliably, and it will warn you rather than guess. Multi-line values in dotenv files are a later addition that different loaders spell differently, and a quoted value left open at the end of a line is at least as likely to be a missing closing quote as an intentional line break. Certificates and private keys are the usual case; most deployment targets have a better mechanism for those than an env file.
What happens if the same name appears twice?
The last occurrence wins and a warning is emitted. That matches what most loaders do, but not all of them — a few keep the first value and ignore later ones, on the reasoning that an already-set variable should not be overwritten. Because the behaviour is not universal, a duplicate is worth resolving in the file rather than relying on either rule.
Is it safe to paste a production env file?
The parsing and the conversion both happen in your browser with no request made and nothing stored, so nothing is transmitted. The realistic risk is not the page, it is what happens next: the values are on your screen, they go into your clipboard when you copy the output, and a shell export line pasted into a terminal usually lands in your shell history in plain text. Names that look like credentials are flagged in the results for that reason.