Dotenv (.env) Viewer

Read a .env file as a tidy key/value table instead of scanning raw lines, with secret values masked by default so tokens and passwords stay hidden on screen. The parser handles the real dotenv grammar: an optional export prefix, # comments including inline ones, single- and double-quoted values with escapes, multi-line double-quoted values, and empty values. Values that look like API keys, tokens, or passwords are detected and masked automatically. This is the most private way to inspect a .env: nothing is ever uploaded — the file is parsed entirely in your browser, and secrets never leave your machine.

How to use the Dotenv (.env) Viewer

Paste the contents of a .env file, or load one with the file picker. The viewer parses it locally and shows every variable as a row of key and value, with a count of variables found and comment lines skipped. Mask secret values is on by default: values are shown with only their first and last two characters visible and the middle replaced by dots, so you can confirm a variable is set without exposing the whole secret to anyone looking at your screen. Untick it to reveal the raw values; even when masking is off, values that strongly resemble keys or tokens are still flagged.

Use the filter box to narrow the table to variables whose key contains your search text — useful in a long file with dozens of settings. The parser strips an optional export keyword, removes full-line and inline # comments (while preserving # characters that sit inside quotes), unwraps single- and double-quoted values, decodes escape sequences in double-quoted values, and reassembles multi-line double-quoted values such as PEM keys. Because every step runs in your browser, you can audit a production .env without it ever touching a network.

What is a .env file, and why does it matter?

A .env ("dotenv") file is a plain-text list of KEY=VALUE pairs that supply configuration to an application through its environment. The pattern comes from the twelve-factor app methodology, whose third factor says configuration that varies between deployments — database URLs, API keys, feature flags, ports — should live in the environment rather than be hard-coded or committed to the repository. In development you keep those values in a local .env file; a loader reads it at startup and injects the variables into process.env, os.environ, or the equivalent, so the same code runs unchanged across laptops, CI, staging, and production with only the environment differing.

The format is deliberately minimal but has a few conventions worth knowing. Each line is NAME=value; names are conventionally uppercase with underscores. Lines may begin with export so the file can also be sourced by a shell. Anything after an unquoted # is a comment, and blank lines are ignored. Values can be wrapped in single or double quotes to preserve spaces or special characters; double-quoted values support escape sequences like \n and can span multiple lines, which is how a multi-line private key or certificate is stored. A bare NAME= sets an empty value. Many loaders also support variable expansion (${OTHER}), though that is an extension rather than part of the original spec.

The single most important rule is operational: a real .env must never be committed to version control, because it almost always contains live secrets. The standard practice is to add .env to .gitignore and commit a sanitized .env.example instead, listing every required key with placeholder or empty values so teammates know what to set. Different ecosystems ship their own loaders — dotenv for Node.js, python-dotenv for Python, godotenv for Go, and built-in support in many frameworks and container runtimes — but they all read the same basic format. A leaked .env is one of the most common ways credentials end up exposed, which is exactly why this viewer parses everything locally and masks secret-looking values by default: auditing what a file contains should never risk transmitting it.

Common use cases

• Auditing a config. Confirm which variables a .env defines, and that no value is accidentally blank, without revealing every secret on screen.
• Building a .env.example. See the full key list at a glance so you can produce a sanitized example file for the repo.
• Debugging a loader. Check how quotes, escapes, and multi-line values actually parse before blaming the application.
• Reviewing safely. Inspect a production or teammate's .env locally instead of pasting it into an online tool that uploads input.