Online Tool Store
Env File to JSON
Parses a .env file into JSON with the correct rules for double-quoted, single-quoted and unquoted values, expands variable references in file order, and reports duplicates and unusable names. Converts back with safe quoting, and can mask values for sharing.
🔒 This tool runs entirely in your browser. Your files are never uploaded to a server.
How each value was read
| Key | Quoting | Value |
|---|
A .env file is usually a file full of credentials. Everything here happens in your browser and nothing is uploaded or stored — but that is worth checking before pasting production secrets into any tool, including this one. If you only need to share the shape of a file, turn on masking.
How to use it
- Paste your .env file, or open one — the sample contains every awkward case on purpose.
- Check the table: it shows which quoting rule was applied to each value.
- Read any warnings — duplicates and unusable variable names are both easy to miss.
- Use masking if you are sharing the result with anyone.
Three quote styles, three different rules
A .env file looks like the simplest format imaginable and then behaves in three different ways depending on how a value is quoted. This is where nearly all .env bugs come from:
A="real\nnewline" → escapes interpreted, $VAR expanded
B='literal\nand $VAR' → entirely literal, nothing touched
C=value # comment → trimmed, comment stripped
So the same characters mean different things in adjacent lines. The single-quote case is the one that surprises people most: a password containing a dollar sign is safe in single quotes and will be mangled in double quotes, because the loader tries to expand it as a variable reference.
The table under the widget labels every value with the rule that was applied, so you can see at a glance whether a value was taken literally or processed.
Expansion resolves in file order
This detail is easy to get wrong and was in fact wrong in the first version of this tool. Variable references resolve against keys defined earlier in the file, exactly as a real loader processes it line by line:
DB_HOST=localhost
DB_URL="postgres://${DB_HOST}/app" → uses localhost
DB_HOST=other ← cannot change the line above
An implementation that builds its lookup table from the whole file first will let that later duplicate reach backwards and give the wrong URL. Building the table as it goes is both simpler and correct — and the duplicate is reported either way, because having a key set twice is nearly always a mistake.
Going back to .env is a quoting decision
Converting JSON into .env format means deciding, per value, whether quotes are needed and which kind. The rule used here is to leave a value bare when it is unambiguous, and otherwise to pick the quote style that preserves it:
value → KEY=value
two words → KEY="two words"
cost $5 → KEY='cost $5' ← single, so it stays literal
it's $5 → KEY="it's \$5" ← double, dollar escaped
The dollar-sign case is the one that matters. Writing it in double quotes would hand a live variable reference to the next loader that reads the file, silently replacing part of a password or a price. Single quotes are the correct answer where the value has no single quote of its own; where it does, double quotes with an escaped dollar is the fallback. Both paths were checked by round-tripping against an expansion table deliberately loaded with values that would have shown up as corruption.
Everything is a string
An environment variable has no type. PORT=5432 is the four characters
5432, and DEBUG=false is the word false — which is why
if (process.env.DEBUG) is true for the string "false" and catches
people out regularly.
The type-conversion option is therefore off by default: turning it on changes your data rather than merely reformatting it. When it is on it only converts clean integers, decimals, the two booleans and null — a version number like 1.20 is left as text, since converting it would drop the trailing zero and change the meaning.
These files are full of credentials
Worth saying plainly rather than burying in a footer: a .env file is normally a list of database passwords, API keys and signing secrets. Parsing here happens in the page and nothing is transmitted, which you can confirm in your browser's network tab — but the habit of not pasting production secrets into web tools is a good one regardless of what any individual tool claims.
The masking option exists for the common case of wanting to show somebody the shape of a configuration — which keys exist, how they are quoted, which are empty — without the values. It replaces each value with asterisks while leaving the structure and the warnings intact.
FAQ
Why does my \n stay literal in one line and become a newline in another?
Because the quote style decides. Inside double quotes, escape sequences are interpreted, so \n is a real newline. Inside single quotes nothing is interpreted at all — the backslash and the n stay as two characters. Unquoted values are trimmed and have any inline comment stripped. Those three behaviours are the source of most .env surprises, so the table under the widget shows which rule was applied to every value.
Are ${VAR} references expanded?
Yes by default, and only where the syntax allows it — unquoted and double-quoted values expand, single-quoted values stay literal. References resolve against variables defined earlier in the file, which matters if a key is set twice: a later duplicate cannot reach backwards and change an earlier line's result. You can turn expansion off if you want the raw text.
What happens to a value containing an equals sign?
It survives. Only the first equals sign is treated as the separator, so a line reading KEY=a=b=c gives the value a=b=c. That is the behaviour of every real loader, and it matters because connection strings and base64 values frequently contain equals signs.
Why is my value quoted in the output when it was not in the input?
Because going back to .env format requires quoting anything that would otherwise be misread — a space, a hash, a quote character, a newline, or a leading or trailing space. There is one case worth knowing: a value containing a literal dollar sign is written in single quotes rather than double, because a loader with expansion enabled would try to resolve a ${...} inside double quotes. Single quotes are literal, so the dollar survives.
Should I convert numbers and booleans to real JSON types?
Only if whatever consumes the JSON expects them. Environment variables are always strings as far as the operating system is concerned — PORT=5432 is the text "5432", not the number 5432. The option exists because a config loader often wants real types, but it is off by default since converting changes the data. Note it deliberately leaves things like a version number of 1.20 alone, because that would lose the trailing zero.
Is it safe to paste a real .env file here?
The parsing happens entirely in your browser and nothing is uploaded, logged or stored. That said, a .env file is usually a list of production credentials, and the right habit is not to paste those into any web tool without checking first — which you can verify here by opening your network tab. If you only need to show someone the shape of a file, use the masking option, which replaces every value with asterisks while keeping the keys.
How we compare
| Feature | Online Tool Store | Other online converters | A dotenv library locally |
|---|---|---|---|
| Secrets never leave your device | ✓ | ✗ | ✓ |
| Shows which quoting rule each value used | ✓ | ✗ | ✗ |
| Reports duplicates and unusable names | ✓ | ✗ | Silently |
| Masks values for safe sharing | ✓ | ✗ | ✗ |
| Converts back to .env with correct quoting | ✓ | Usually one way | Not its job |
| Actually loads variables into a process | ✗ | ✗ | ✓ |
| Matches one specific loader's edge cases exactly | ✗ | ✗ | ✓ |
Useful for turning configuration into JSON for a deployment tool, auditing a file for duplicates, and sharing a redacted copy. One honest caveat: .env has no specification, so loaders differ on the awkward edges. If a value matters, test it with the loader you actually use rather than trusting any converter, including this one.