Skip to content

.env Validator

Paste a dotenv file and get a line-by-line report: duplicate keys, unbalanced quotes, unquoted values with spaces or hashes, invalid key names, and API keys that should never be committed. Nothing is uploaded.

  • Line-by-line diagnostics
  • Duplicate key detection
  • Quote and comment pitfalls
  • Secret-shaped value warnings
  • Runs fully client-side

Validator

Your file never leaves the browser

Comments and blank lines are ignored. Analysis runs as you type.

Paste a dotenv file to see duplicate keys, quoting problems and risky values, line by line.

    How to validate a .env file

    1. 01

      Copy your .env file

      Open the .env file in your editor and copy its contents. Comments and blank lines are fine — the validator skips them.

    2. 02

      Paste it into the validator

      Paste the file into the text area. Analysis happens as you type, entirely inside your browser.

    3. 03

      Work through the report

      Errors break parsing and must be fixed. Warnings are values that parse but probably do not mean what you intended. Info notes are conventions.

    4. 04

      Fix and re-check

      Apply the fixes in your editor, paste again and confirm the report is clean before you deploy.

    Why .env files break in ways that are hard to see

    A dotenv file looks like the simplest format in the world: KEY=value, one per line. The trouble is that there is no official specification. Every loader — dotenv in Node, python-dotenv, Docker Compose, Vite, the Railway and Vercel dashboards — implements slightly different rules for quoting, comments and whitespace.

    The failure mode is nasty because it is silent. Your app does not crash on a malformed line; it starts up with a variable containing production # the app environment instead of production, and you find out three hours later when a conditional takes the wrong branch.

    The four bugs that cause most incidents

    Inline comments on unquoted values. NODE_ENV=production # the environment is read as the literal string production # the environment by some parsers and as production by others. Quote the value or put the comment on its own line.

    Values with spaces left unquoted. APP_NAME=My App is ambiguous. Docker Compose and several shells will stop at the first space. Write APP_NAME="My App".

    Duplicate keys. Defining DATABASE_URL twice is not an error for most loaders — the last one silently wins. That is exactly how a staging URL ends up in production.

    Spaces around the equals sign. PORT = 3000 can produce a key named PORT (with a trailing space) that your code will never find, because it is looking for PORT.

    Secrets in .env files

    A .env file is a convenient place to keep credentials and a terrible place to lose track of them. This validator flags values shaped like known credentials — OpenAI and Anthropic keys, GitHub tokens, AWS access key IDs, Slack tokens, PEM private keys and JWTs — as a reminder, not an accusation.

    The rule that actually protects you is upstream: .env belongs in .gitignore, and .env.example with placeholder values belongs in the repository. If a real key has ever been committed, rotate it. Deleting the commit does not help — it stays in the history and in every clone.

    What this tool does not do

    It checks syntax and shape, not meaning. It cannot tell you that DATABASE_URL points at the wrong host, that a key has been revoked, or that your application needs a variable you forgot to define — it has no knowledge of your app.

    It also does not enforce one parser's rules over another. Where loaders genuinely disagree, the report says so and suggests the form that works everywhere, which is usually "quote the value".

    Frequently asked questions

    Is my .env file uploaded anywhere?

    No. The validator runs entirely in your browser using JavaScript. The file is never sent over the network, never written to localStorage and never added to the URL. Closing the tab discards it.

    Should I quote values in a .env file?

    Quote any value that contains a space, a hash, a quote character or a trailing space. For simple values like ports and flags, quotes are optional. Double quotes are the safest default because every major loader understands them the same way.

    What happens if the same key appears twice?

    Most loaders, including Node dotenv and python-dotenv, keep the last occurrence and silently discard earlier ones. Since no error is raised, duplicates are a common cause of a stale value reaching production. The validator flags every repeat and points at the earlier line.

    Can I use variables inside other variables?

    Some loaders support interpolation like DB_URL=postgres://${DB_USER}@host, and some do not — plain Node dotenv does not expand variables without the dotenv-expand package. The validator points out references to keys that are not defined in the file so you can confirm they come from the real environment.

    Does uppercase actually matter for key names?

    Functionally no on Linux and macOS: environment variables are case-sensitive and lowercase works. It is flagged as a convention note because Windows treats environment variable names case-insensitively, and mixed conventions in one file are a readability problem.

    Why is a multi-line value reported as an unbalanced quote?

    Because multi-line values are one of the least portable parts of the format. Node dotenv supports them inside double quotes, but many other loaders do not. For PEM keys, the widely compatible approach is a single-line value with literal \n escape sequences.

    Developers

    JWT Decoder

    Decode the header and payload of a JWT without the token ever leaving your browser.

    Developers

    Cron Expression Parser

    Translate a cron expression into plain English and see exactly when it runs next.

    Developers

    UUID Generator

    Generate cryptographically random UUID v4 or time-ordered UUID v7, in bulk.