.env File Parser

Parse and inspect .env files — view keys, values, types, and detect common issues.

.env Contents

What Is a .env File?

A .env file stores environment-specific configuration such as API keys, database URLs, and feature flags as simple KEY=VALUE pairs. Lines beginning with # are comments and are ignored, as are blank lines. Values may be surrounded by single or double quotes to preserve spaces and special characters. This parser detects the inferred type of each value (string, number, boolean, or empty), flags duplicate keys, and warns about unquoted values that contain special characters. The JSON export is handy for debugging or piping parsed values into other tools. Nothing leaves your browser.

Built and maintained by Meet Shah · Last updated 4 August 2026

What this tool is used for

Inspecting a `.env` file's keys and values without opening it in an editor.
Finding a duplicate key that a later line is silently overriding.
Checking how quoting and inline comments will be parsed.
Comparing two environment files' key sets.
Spotting a value with stray whitespace that will break a comparison.

Frequently Asked Questions

What does the parser flag as a problem?: Duplicate keys, a line with no key before the `=`, a key containing characters that are not valid in a shell variable name, and an unterminated quote. Each is reported with its line number and a severity, because a `.env` has no compiler — a broken line just becomes a value nobody notices is missing.
Why do duplicate keys matter if the file still loads?: Because which one wins depends on the loader, and that is the worst kind of ambiguity for a secret. Most dotenv implementations keep the LAST occurrence, some keep the first, and Docker Compose's behaviour differs again. The file reads as if both values are configured and exactly one of them is.
Does .env have a specification?: No, and that is the root of most surprises. Every language's dotenv library invented its own rules for quoting, escaping, multi-line values, variable interpolation and comments after a value. A file that works in Node can behave differently in Python, so treat cross-runtime `.env` files with suspicion.
Are values typed?: Not in the file — everything is a string when it reaches the process. The type column here is a guess based on the value's shape, offered so you can spot that `DEBUG=false` will arrive as the five-character string `"false"`, which is truthy in nearly every language's boolean test.
Is it safe to paste a real .env here?: The parsing runs entirely in your browser and nothing is transmitted, so it never leaves the machine. The much larger risk with a `.env` is the one it exists to prevent: make sure the file is in `.gitignore` before it acquires real credentials, not after.

Common errors and gotchas

Pasting a production `.env` into any tool, which is a habit worth not forming even locally.
Assuming one parser's rules, since quoting, multi-line and export-prefix support all vary.
Treating an inline `#` inside a quoted value as a comment, where it is data.
Overlooking a duplicate key, where the last occurrence usually wins silently.
Expecting types, since every environment variable is a string.