⌘ K
env → json · dotenv · export · comments · quoted values · live

Parse a .env file to JSON

Read a dotenv-style file into a plain JSON object. Comments, blank lines, export prefixes and quoted values are all handled correctly.

ENV → JSON
Input
144 B
7 lines
Output
149 B
7 lines
Status
ready
live
Ratio
1.03×
out/in
input · .env
output · json
{
  "DATABASE_URL": "postgres://localhost:5432/mydb",
  "API_KEY": "sk-1234567890",
  "PORT": "8080",
  "DEBUG": "true",
  "NODE_ENV": "production"
}
Quick Start

How dotenv parsing works

Each non-blank, non-comment line is read as KEY=VALUE. Optional export prefixes are stripped, surrounding single or double quotes are removed, and everything else stays as a string.

  1. 01

    Paste .env

    Comments (lines starting with #) and blank lines are ignored.

    Parsing is strict-but-tolerant — comments and trailing commas are accepted on input where the source format historically permits them; output stays canonical.

    inputstricttolerantliveparse
    in · source.env · live
    # db
DATABASE_URL=postgres://...
    loaded · parsedtarget · ready
  2. 02

    Strip prefixes

    Lines beginning with export are normalised so the variable still becomes a plain JSON key.

    Conversion preserves type information where the target supports it (numbers stay numeric, booleans stay boolean) so the destination parser never has to re-coerce.

    striptype-preservinglosslesslivememoised
    export · optionsdrop · live
    export NODE_ENV=prod
→ NODE_ENV: "prod"
    options applied · liveround-trip
  3. 03

    Unquote values

    Surrounding double or single quotes are removed; nothing inside is reinterpreted.

    Re-encoding is idempotent: running output back through the same converter produces the same bytes, which keeps round-trips git-friendly.

    unquoteidempotentround-tripdiff-cleandeterministic
    quote · converteddrop · ready
    API_KEY="sk-..." → "sk-..."
    converted · livediff-clean
  4. 04

    Copy or download

    Drop the JSON into config loaders, test helpers or secret managers.

    Copy writes via navigator.clipboard.writeText; downloads use the target’s native MIME so editors apply the right syntax highlighting on open.

    exportclipboardtarget MIMEblobclient-side
    ✓ · copiedready · done
    ✓ Copied
    shipped · ready to shipsuccess
Pro tips

Converting between formats, safely

Pick the strictest source format

Lossy formats hide bugs. Choose JSON or YAML as your source-of-truth, convert downstream as needed.

Round-trip in CI

If your converter is idempotent, your CI can verify A → B → A equals the original. Catches subtle data loss.

Numbers vs strings differ

YAML/TOML have a number type; CSV doesn’t. Quote IDs in CSV to keep leading-zero values intact.

Watch character encoding

Source format may be Latin-1 / Windows-1252; target should be UTF-8. Convert encoding before structure.

Preserve comments where you can

YAML and TOML support comments. Don’t silently drop them — they often encode intent.

Schema-aware beats blind

Use a schema to guide conversion. Field types, required-ness, and defaults survive better with structure.

Related toolsJSON to ENVINI to JSONProperties to JSONTOML to JSONYAML to JSONDocker → Compose
Use Cases

When to convert .env to JSON

Config inspection, secret rotation, tests.

Config audit

See your effective env vars in one structured view. Type information survives: numbers stay numeric, booleans stay boolean, strings stay strings. The destination parser doesn't have to re-coerce, which avoids the "'true' becomes "true"" bug class.

round-trip safe

Secret manager import

Paste a JSON blob into Vault, AWS SSM or Doppler. Run output back through the inverse converter to verify idempotent round-trips in CI. A → B → A should produce byte-identical input — if it doesn't, you've found data loss.

type-preserving

Snapshot tests

Snapshot env state alongside a failing test run. Comments and metadata survive where the target format supports them (YAML, TOML, HCL). The tool doesn't silently drop intent-encoded annotations, which keeps your config self-documenting.

schema-aware

Tool input

Feed env values to a script that only takes JSON. Pair with a schema (JSON Schema, OpenAPI, Zod, Pydantic) to catch shape drift on either side. Catch breaking changes at conversion time rather than at runtime in production.

lossless

Diff two .env files

Convert both, paste into a JSON diff tool to spot drift. Output respects target-format conventions: quoting in CSV, indent in YAML, brackets in JSON. Existing parsers don't need patches, and the result drops into legacy pipelines unchanged.

diff-clean

Docs

Document the expected env shape as JSON in README. Encoding-aware: handles UTF-8 vs UTF-16 vs Latin-1 / Windows-1252 transparently. The character-set surprise that breaks "works on my machine" doesn't apply here.

spec-grade
FAQ

Frequently asked questions

No — everything stays a string. The dotenv spec is string-only; type-cast on the consumer side.
No. The literal characters between the quotes are preserved.
Not yet — each variable must sit on a single line.
No — ${VAR} references stay literal in the output.
No. Parsing is entirely local.
Suggest a tool

Something missing?

Tell us what you need. We ship the top requests every two weeks.

Sent straight to the maintainers · no account needed
47 in queue·8 shipped this month
Request queued. Thanks!