Convert .env Files to JSON and Other Formats Instantly
A .env file is the quiet workhorse of almost every modern project. It holds the configuration a program needs at runtime — database URLs, API keys, feature flags, port numbers — as a plain list of KEY=value lines. That format is easy to write by hand, but it is not always the shape you need. A CI pipeline may want the same values as JSON, a Kubernetes deployment expects a ConfigMap, a docker-compose file wants an environment block, and a shell script wants export statements. This converter reads the .env dialect faithfully and rewrites the same key-value pairs into JSON, YAML, docker-compose, a Kubernetes ConfigMap, or shell exports, and it also runs in reverse so you can turn a JSON object back into a clean .env file. Because it is aimed at secret-adjacent data, all of the parsing happens locally in your browser and nothing is ever uploaded to a server.
The parser follows the conventions that dotenv libraries established, and getting those details right is what separates a real converter from a naive split on the equals sign. Each line is a KEY=value pair, and a leading export keyword is accepted and stripped, so export KEY=value behaves the same as KEY=value. Blank lines are skipped, and any line beginning with a hash is treated as a comment and ignored, as is an inline comment that follows an unquoted value. Values can be bare, or wrapped in single or double quotes. A single-quoted value is taken literally, character for character, so a backslash-n inside it stays as two characters. A double-quoted value is interpreted, so an escape sequence like backslash-n becomes a real newline, and an optional dollar-brace reference such as a variable name in braces is expanded to the value of a key defined earlier in the same file. An empty value after the equals sign is preserved as an empty string rather than dropped. The result is a faithful map that matches how your application would actually load the file at runtime.
A short worked example makes the rules concrete. Suppose your file contains the single line PORT=3000. The converter produces the JSON object with one property, written as a string, giving the output PORT set to the string 3000 rather than the number 3000, because values in a .env file are always text until your program chooses to coerce them. Add a second line, a comment beginning with a hash, and it disappears from the output entirely. Add DB_URL wrapped in double quotes that itself references the earlier PORT with a dollar-brace expression, and the converter substitutes the resolved 3000 into the final string. Switch the output selector to Kubernetes ConfigMap and the same pairs are emitted as a valid ConfigMap manifest with a data block; switch it to docker-compose and they appear under an environment key ready to paste into a service definition. The reverse direction takes a JSON object and flattens it back into KEY=value lines, quoting any value that contains spaces or special characters so the resulting .env file loads cleanly.
The practical uses cluster around moving configuration between the many tools a project touches. A developer who keeps local settings in a .env file can generate the ConfigMap needed to run the same service in a cluster without hand-editing YAML and risking an indentation mistake. A platform engineer can convert a JSON secrets export from a vault back into the .env format that a legacy service expects. Someone writing documentation can turn a working .env into a readable JSON snippet to show the shape of the configuration. During debugging, pasting a suspect .env here quickly reveals a value that was accidentally left unquoted, a stray comment that swallowed part of a value, or a variable reference that failed to resolve because the referenced key was defined later in the file.
A few tips keep the round trip clean and safe. Remember that everything is a string on the .env side, so if a downstream consumer needs a real number or boolean it must do the conversion itself; the JSON output preserves the text exactly rather than guessing types. Prefer double quotes when a value must contain a newline or a variable expansion, and single quotes when you want a literal string with no interpretation at all. Because the tool runs 100% in the browser and uploads nothing, it is safe to paste files that contain API keys or database passwords, but treat the output with the same care as the input — a ConfigMap is plain text, and secrets belong in a Kubernetes Secret rather than a ConfigMap for anything sensitive. The one real limit is that the parser targets the widely used dotenv subset rather than every exotic extension some libraries add, so a very unusual multiline heredoc syntax may not round-trip, but standard files convert cleanly in both directions.