ENV to JSON Converter
Parse dotenv-style assignments into flat or grouped JSON while keeping type inference explicit.
Paste dotenv-style assignments. Quoted values may span lines; an unquoted # starts a comment when comment handling is enabled.
How ENV values should become JSON
JSON output
Converted JSON will appear here.
A .env file carries text, not JSON types
Environment variables arrive at an application as strings. A line such as PORT=5432 does not itself say that 5432 is a JSON number, and FEATURE_ENABLED=false does not make false a boolean. Auto inference here is therefore deliberately optional. Quoted values always stay strings, while unquoted booleans, null, safe numbers, and valid JSON arrays or objects can be inferred when that mode is selected.
Dotenv files do not have one cross-platform formal standard. Node.js publishes its own .env rules for variable names, comments, quoted values, multiline quoted text, and optional export prefixes. Those rules are a useful reference, but another runtime or dotenv library can differ. See the Node.js .env documentation.
What the parser accepts
- Names made from letters, digits, and underscores, without a leading digit.
- Values containing additional equals signs after the first separator.
- Single- or double-quoted values, including quoted text that spans lines.
- Full-line and inline # comments when comment handling is enabled.
- An optional export prefix when that option is enabled.
Shell expansion is intentionally outside scope. References such as $HOME, command substitutions, and shell expressions are copied as text rather than executed.
Underscore nesting is a naming convention, not a standard
Flat mode preserves DATABASE_HOST as the JSON member DATABASE_HOST. Nested mode treats every underscore as a boundary, lowercases the pieces, and produces database.host. That can be handy for a naming scheme built around prefixes, but it is lossy for names where underscores are part of the intended field name.
Collisions are rejected rather than overwritten. For example, APP=value and APP_NAME=Sneha cannot both become one nested structure because APP would need to be both a value and an object. Duplicate ENV names are rejected for the same reason: silently keeping the last value would hide configuration mistakes.
A small example where quoting matters
PORT=5432
PIN="0017"
ENABLED=true
NAME="Sneha # local"
Auto inference produces:
{
"PORT": 5432,
"PIN": "0017",
"ENABLED": true,
"NAME": "Sneha # local"
}PIN remains text because it was quoted. That avoids turning an identifier with leading zeroes into a number. Integers outside JavaScript's safe range are also left as strings instead of being rounded silently.
Secrets do not become harmless after conversion
JSON output can expose the same passwords, tokens, private keys, and connection strings that were present in the source file. The preview masks likely secret names only to reduce accidental on-screen exposure; it does not redact the generated JSON. Avoid pasting production credentials into tickets, chat messages, screenshots, or source control after conversion.
Boundaries that are better left explicit
This parser does not expand variables, execute shell syntax, fetch files, or decide application-specific types. It also stops at 5,000 assignments and one million input characters so an accidental huge paste does not lock up the page. If a deployment platform uses its own dotenv extensions, compare the generated JSON with that platform's parser before replacing a production configuration path.
