waynetools/env-json-converter
Updated 2026-07-11 · Built by Wayne

.env to JSON Converter (Bidirectional, Nested Keys & Docker Compose)

Paste a .env file to get JSON, or paste JSON to get a .env file — both directions run in your browser. Correctly handles quoted values, backslash escapes, multi-line double-quoted values and comments, and exports flat or nested (KEY__SUB) JSON, a docker-compose environment: block, and a TypeScript ProcessEnv interface in one click.

What it does: a client-side .env ↔ JSON converter that parses real dotenv syntax — quotes, escapes, multi-line values, comments, export prefixes — instead of naive line-splitting, then generates flat or nested JSON, a docker-compose environment block and a TypeScript ProcessEnv type from the same parsed data. Nothing is uploaded; it runs entirely as JavaScript in your tab.

100% client-side Free No signup Bidirectional Nested KEY__SUB → JSON Docker Compose export TypeScript ProcessEnv export

      
0 variables parsed

What is this tool

This is a two-way .env and JSON converter built for developers who move configuration between shell environments, Docker, CI secrets and application code. Most "env to JSON" tools online split each line on the first = and call it done, which silently corrupts anything more interesting than KEY=value: a database URL with a colon, a multi-line RSA private key, a value with a trailing comment, or a JSON blob stored as a string. This tool parses character by character, the way the Node dotenv package and Docker Compose's own env-file loader do, so quoted values, backslash escapes, multi-line double-quoted blocks, inline comments and an optional export prefix are all handled the way they behave in a real shell.

The other direction — JSON back to .env — is just as easy to get wrong. A nested JSON config object has no direct .env representation, arrays and booleans need explicit string conversion, and a value containing a newline or a quote needs correct escaping or the resulting file won't parse. This tool flattens nested objects using a KEY__SUB double-underscore path convention (matching how dotenv-expand, Spring Boot and .NET configuration providers already read nested env vars), serializes non-string values sensibly, and quotes only the values that actually need it.

Because a .env file is rarely the final destination, the tool also generates two artifacts straight from the same parsed data: a docker-compose environment: list block with correct YAML quoting, and a TypeScript declare global augmentation of NodeJS.ProcessEnv so every key gets type-checked at compile time instead of coming back as string | undefined everywhere it's read. Everything — parsing, converting, generating all four output formats — runs as plain JavaScript in your browser tab; nothing is uploaded, logged or sent anywhere, which matters when the file you're pasting has real API keys and database passwords in it.

How to use it

  1. Pick a direction: use the .env → JSON tab to paste dotenv content, or JSON → .env to paste a JSON object (flat or nested).
  2. Paste your content into the input box, or click Load sample to see a worked example with quotes, a multi-line value and nested keys.
  3. Toggle nesting on or off — with it on, keys like DATABASE__HOST become {"DATABASE":{"HOST":...}}; with it off you get a flat object with the raw double-underscore keys.
  4. Click Convert (it also runs automatically as you type, debounced) to parse the input and generate all four outputs.
  5. Switch output tabs between JSON, .env, docker-compose and TypeScript to preview each format, then Copy output or Download the active one.
  6. Swap direction to send the current output back in as input — useful for round-tripping a file to confirm nothing was lost in translation.

Two worked examples

Example 1 — quotes, a comment and a nested key, .env → JSON

Input .env:

export NODE_ENV=production
# database connection
DATABASE__HOST=db.internal.example.com
DATABASE__PORT=5432
DATABASE__PASSWORD="p@ss w0rd \"quoted\""
APP_NAME=Checkout Service # inline comment stripped
FEATURE_FLAGS='["beta","dark-mode"]'

Output JSON (nested on):

{
  "NODE_ENV": "production",
  "DATABASE": {
    "HOST": "db.internal.example.com",
    "PORT": "5432",
    "PASSWORD": "p@ss w0rd \"quoted\""
  },
  "APP_NAME": "Checkout Service",
  "FEATURE_FLAGS": "[\"beta\",\"dark-mode\"]"
}

Note the inline comment after APP_NAME is removed, the escaped double quote inside DATABASE__PASSWORD survives correctly, and DATABASE__HOST / DATABASE__PORT merge into one nested DATABASE object instead of three unrelated flat keys.

Example 2 — nested JSON → .env, docker-compose and TypeScript

Input JSON:

{
  "PORT": 3000,
  "DEBUG": false,
  "REDIS": { "HOST": "localhost", "PORT": 6379 }
}

Output .env:

PORT=3000
DEBUG=false
REDIS__HOST=localhost
REDIS__PORT=6379

Output docker-compose block:

services:
  app:
    environment:
      - PORT=3000
      - DEBUG=false
      - REDIS__HOST=localhost
      - REDIS__PORT=6379

Output TypeScript:

declare global {
  namespace NodeJS {
    interface ProcessEnv {
      PORT: string;
      DEBUG: string;
      REDIS__HOST: string;
      REDIS__PORT: string;
    }
  }
}

export {};

The number 3000 and boolean false are both written as plain strings — the only type an environment variable can actually hold — which is also why the generated TypeScript interface types every key as string rather than pretending PORT is a number.

Frequently asked questions

Does converting .env to JSON handle quotes and multi-line values correctly?

Yes. The parser reads character by character rather than splitting naively on newlines, so a double-quoted value that spans several physical lines (common for PEM certificates or multi-line SQL) is captured as one JSON string with real newline characters. Double-quoted values also support backslash escapes for \n, \r, \t, \", \ and \$; single-quoted values are treated literally. Comments on their own line and inline comments after a value are stripped correctly, without breaking on a # that appears inside a quoted value.

What is the KEY__SUB nested JSON convention?

Environment variables are flat by nature, but application config is usually nested. This tool uses a double underscore as a path separator: DATABASE__HOST becomes {"DATABASE":{"HOST":"value"}}, and DATABASE__POOL__MAX becomes a three-level nested object. This mirrors the convention already used by dotenv-expand, Spring Boot relaxed binding and .NET configuration providers, so the nested output plugs straight into config systems that expect it. Turn the nesting toggle off to get a flat JSON object with the raw double-underscore keys instead.

How does JSON back to .env work when values are nested or arrays?

Nested objects are flattened back into KEY__SUB__CHILD keys, walking the tree depth-first. Arrays and any other non-string, non-primitive value are serialized with JSON.stringify and written as a double-quoted .env value, since a raw environment variable has no native array or object type. Booleans and numbers are converted to their plain string form (true, 5432) without quotes, unless the value needs quoting for whitespace or special characters.

Is this different from waynetools' JSON to Types tool?

Yes, they solve different problems. json-to-types turns a JSON sample into Pydantic, Zod or TypeScript models describing its shape. This tool's job is the .env format itself: parsing real dotenv syntax (quotes, escapes, multi-line values, comments, export prefixes) into JSON and back, plus generating the two artifacts a .env file is usually needed for next — a docker-compose environment: block and a minimal TypeScript ProcessEnv augmentation, not a full data model.

Is my .env file uploaded anywhere?

No. Parsing, converting and generating every output happens in plain JavaScript in your browser tab. There is no server call, no logging and no network request after the page loads — safe to use with real secrets, though pasting production credentials into any browser tool is still worth a moment of caution.

Does the docker-compose export handle values with colons or spaces?

Yes. YAML treats a bare colon-space or a leading special character as syntax, so any value containing a colon, a space, a quote, a backslash, or that is empty, is automatically wrapped in a double-quoted YAML string with internal quotes and backslashes escaped. Plain values like ports or hostnames are left unquoted for readability.