Env File Editor — Free Online .env Editor, Linter, Secret Auditor & Converter

It is a full workbench for .env files: a syntax-highlighted editor with line numbers, a live validator, a secret audit, an editable table view, an environment diff and a converter that turns the same file into 16 other formats. Everything happens in your browser — there is no server involved at any point.

Four ways: Load .env file opens a file picker (the file is read locally, never uploaded), Paste from clipboard reads your clipboard if the browser allows it, you can simply type or paste into the editor, or Import JSON / YAML converts an existing config object into .env lines.

It loads a deliberately broken example — a duplicate key, a space before the =, an unterminated line, a live-looking Stripe key, a placeholder JWT secret, TLS verification switched off and an unresolved ${VAR} — and jumps to the Audit tab. It is the fastest way to see what the linter and the audit actually catch.

• Editor — highlighted text editing with a gutter that marks problem lines
• Table — one row per variable, editable in place, with a filter box
• Audit — secret detection, unsafe settings and a graded score
• Compare — diff two environments and merge the gaps
• Export — live preview of 16 output formats

Yes, in both directions. Editing a cell in the Table tab rewrites the .env text, and editing the text updates the table, the stats, the lint list and the audit. The .env text is the single source of truth — comments, blank lines and quote style survive a round trip through the table.

Live counts of variables, comment lines, duplicate keys, empty values, flagged secrets (keys with a critical or high audit finding) and total lines. Underneath, the worst syntax issues are listed — click any of them to jump straight to that line in the editor.

Ctrl/⌘+F opens find and replace, Ctrl/⌘+S downloads the current .env, Ctrl/⌘+Shift+M toggles value masking, Tab inserts two spaces, and Esc closes the find bar or the import dialog.

It replaces every value with dots in the editor, the table, the compare results and the status bar, while leaving the real text untouched underneath. It is meant for screen sharing, pair programming and screenshots. The Export tab has its own separate redact values checkbox for when you want to hand the file to someone.

Yes. Open Find, turn on Keys only, and replace runs against key names rather than the whole file — the safe way to rename a prefix such as OLD_APP_ to NEW_APP_ without touching any values that happen to contain the same text. Aa toggles case sensitivity.

• Sort keys A→Z — alphabetical, and each comment block stays attached to the variable it documents
• Group by prefix — splits into # ── DB ── style sections based on the first word of each key
• Trim & normalise — removes stray whitespace around keys and unquoted values
• Remove duplicates — keeps the last occurrence, because that is the one that wins at load time
• Fix quoting — adds quotes where a value needs them and removes them where it does not
• UPPER_SNAKE keys — converts apiKey or api-key to API_KEY

Three values from crypto.getRandomValues: a 256-bit hex string, the same 256 bits as base64, and a UUID. They are appended to the end of the file for you to rename and use. They are generated in your browser from the operating system's secure random source — not from a seeded pseudo-random generator, and not from a server.

No, deliberately. Nothing is written to localStorage, cookies or IndexedDB, because everything you paste here is by definition a secret. Reloading the page loses the content — export or copy before you leave.

Yes, once the page has loaded. The parser, the linter, the secret patterns and every export format are part of the page. You can disconnect and keep working, which is a reasonable habit when handling production credentials.

No hard limit. Above roughly 3,000 lines the syntax highlighting switches off automatically to keep typing responsive; everything else — linting, auditing, exports — keeps working normally.

A plain text file of KEY=VALUE lines that holds configuration outside your source code — database URLs, API keys, feature flags, ports. Loaders such as Node's dotenv, Python's python-dotenv, Ruby's dotenv, Laravel, Docker Compose and Vite read it at startup and put the values into the process environment.

No, and that is the root of most confusion. Every loader implements its own dialect. They agree on KEY=VALUE, # comments and quoting, and disagree about interpolation, multi-line values, escape sequences and whitespace. This editor follows the common denominator and warns wherever a line would behave differently depending on the parser.

Only when the value contains something ambiguous: a leading or trailing space, a #, a quote character or a line break. Everything else is fine unquoted. Fix quoting applies exactly that rule across the file.

In most loaders, double quotes expand escape sequences — "line1\nline2" becomes two lines — and often expand ${VAR} references too. Single quotes are literal: 'a\nb' stays as backslash-n. The editor decodes \n, \t, \r, \\ and \" inside double quotes and leaves single-quoted values alone.

Yes, if it is quoted — which is how people paste RSA private keys and certificates. The parser here follows the value across lines until the closing quote, keeps it as one variable, and marks the continuation lines in the gutter. If the closing quote is missing you get an unterminated quote error, because a real loader would swallow the rest of your file into that one value.

Because an unquoted # preceded by whitespace starts an inline comment. PASSWORD=abc#123 keeps the hash (no space in front), but PASSWORD=abc #123 gives you abc. Quote the value and the problem disappears.

Shell syntax says no, and several loaders agree. KEY = value can end up with a key literally named "KEY " and a value of " value". The linter flags both sides separately, and Trim & normalise fixes them.

Yes — the prefix exists so the file can also be sourced by a shell. The parser recognises and preserves it, colours it separately, and drops it in formats where it makes no sense, such as JSON or a Kubernetes manifest.

To be safe: a letter or underscore first, then letters, digits and underscores — the POSIX identifier rule. Anything else may load in Node but will break export, shell interpolation and several parsers. The linter warns on invalid identifiers and, more gently, on lower-case keys, since the universal convention is UPPER_SNAKE_CASE.

Some loaders substitute another variable's value there. Support is inconsistent: dotenv alone does not expand, dotenv-expand, Docker Compose and Laravel do. This tool shows the resolved value under the field in the Table tab, warns when a reference points at a key that does not exist, catches self-references, and can bake the references into literal values with Resolve ${VAR} refs.

The editor understands the shell-style default syntax — ${PORT:-3000} resolves to 3000 when PORT is absent, and the missing key is not reported as an error. Whether your loader supports it is another matter; Docker Compose does, plain dotenv does not.

Practically every loader keeps the last occurrence, so the earlier line is dead config that still looks alive during code review. Duplicates are counted in the sidebar, marked red in the table, listed with all their line numbers, and Remove duplicates deletes the earlier ones.

Nine times out of ten it is a UTF-8 BOM at the start of the file — usually added by a Windows editor. The first key becomes \uFEFFDATABASE_URL, which no lookup will match. The linter detects a BOM and strips it when you paste the file in.

CRLF line endings. A file saved on Windows and mounted into a Linux container leaves \r at the end of every value, so PORT becomes "3000\r" and the port parse fails. The linter reports CRLF endings, and anything you export from here is written with plain LF.

No — the format is flat strings only. The usual workaround is a delimiter (ALLOWED_HOSTS=a.com,b.com) or embedded JSON in a quoted value. When you import a nested JSON or YAML config here, the keys are flattened with underscores: {"db":{"host":"x"}} becomes DB_HOST=x.

Always. DEBUG=false arrives in your code as the string "false", which is truthy in JavaScript and Python alike — a bug that has shipped to production more times than anyone will admit. Parse and validate explicitly, or use a schema library such as zod or envalid.

No. Add it to .gitignore and commit .env.example instead — same keys, no values — so a new developer knows what to fill in. The Export tab generates that file for you, keeping your comments and section headers intact.

Around thirty rules across three severities. Errors: duplicate keys, invalid lines, unterminated quotes. Warnings: spaces around the =, invalid identifiers, unquoted values containing spaces, text after a closing quote, unresolved ${VAR} references, self-references, a UTF-8 BOM. Notes: lower-case keys, empty values, very long values or key names, CRLF line endings, unquoted $ or backticks.

Click the issue in the sidebar. The editor scrolls to that line and selects it. Problem lines are also marked in the gutter — red for errors and any critical or high audit finding, yellow for warnings.

Because it is often intentional — OPTIONAL_FEATURE_URL= is a legitimate way to say “not configured”. It is worth seeing at a glance, though, because an empty value and a missing key behave differently: the first gives your code an empty string, the second gives undefined.

A non-empty, non-comment line with no =, or one that starts with =. Most loaders skip these silently, so a typo like DATABASE_URL postgres://… simply produces no variable at all and you find out at runtime.

Because behaviour diverges. Some parsers keep the whole rest of the line, some stop at the first space, and a shell sourcing the file will try to run the second word as a command. Quoting removes the ambiguity entirely.

A ${VAR} or $VAR pointing at a key that is not defined anywhere in the same file and has no :-default. It may still resolve at runtime from the real environment, so it is a warning rather than an error — but it is the most common cause of a value that comes out as the literal text ${DB_HOST}.

It checks the shape of the file, not the meaning of your configuration — it cannot know that your database URL points at a database that exists. What it does check is that a value looks like what its key claims: a credential-shaped value, a plausible URL scheme, a plain http:// where TLS was expected.

The mechanical ones, yes: remove duplicates, trim whitespace, fix quoting, uppercase key names, resolve references, sort or group. Anything that requires a decision — which of two duplicate values is right, whether a secret should be rotated — is reported and left to you.

The linter is about syntax and hygiene: will this file load correctly. The audit is about security: is there a live credential in it, is a secret a placeholder, is a protection switched off. A file can be perfectly valid and still fail the audit badly.

It runs every value against more than forty provider token formats, a placeholder-secret list, an entropy calculation and a set of configuration rules, then grades what it finds from critical to low and turns that into a score out of 100 with a letter grade. All of it in your browser — no value is ever sent anywhere, and the values are not even included in the report you copy.

AWS access keys, GitHub tokens (ghp_, gho_, github_pat_), GitLab PATs, Slack tokens and webhooks, Stripe live and test keys, OpenAI and Anthropic keys, Google API keys and OAuth client secrets, SendGrid, Twilio SIDs and API keys, Mailgun, npm, PyPI, DigitalOcean, Shopify, Square, Discord, Telegram, Hugging Face, Cloudinary, Algolia, Datadog, Azure storage keys and SAS tokens, Sentry DSNs, JSON Web Tokens, SSH keys, PEM private key blocks, and credentials embedded in a connection URL.

Because the consequences are completely different. sk_test_… in a repository is untidy; sk_live_… is a payment incident. The same logic runs throughout: a Twilio account SID is medium, a Twilio API key is critical.

A value like changeme, secret, password, admin or abc123 sitting in a key named *_SECRET, *_TOKEN or *_PASSWORD. It is flagged high because these survive from the first day of a project into staging and sometimes into production, where they are effectively public knowledge.

It measures the Shannon entropy of a value in bits per character. A secret-named key holding a 16-character value with under 2.6 bits per character is repetitive or dictionary-like rather than random, and is flagged. The reverse check also runs: a very high-entropy random string in a key that is not named like a secret is flagged low, because keys named CLIENT_CONFIG sometimes hold real credentials.

Detection is by shape, so a 32-character hex build hash can look exactly like an API key. Findings are signals to check, not verdicts — that is why every finding names the rule that produced it and links to the line. A short low-entropy value in a key called APP_SECRET deserves the flag even if you know the app is a toy.

• NODE_TLS_REJECT_UNAUTHORIZED=0 — turns off certificate validation for the whole Node process
• Debug or verbose mode enabled while the environment is production
• Any *VERIFY*, *SSL*, *CSRF* or *SECURE* key set to false
• DISABLE_*, SKIP_* or UNSAFE_* flags switched on
• Wildcard * in a CORS, origin, allowed-hosts or whitelist key
• Plain http:// endpoints that are not localhost
• Default database passwords such as postgres, root or admin
• The same secret value reused across several keys

It starts at 100 and subtracts a weight per finding — 34 for critical, 16 for high, 7 for medium, 2 for low — with the result mapped to a letter: A from 90, B from 75, C from 55, D from 35, F below that. It is a rough prioritisation aid, not a compliance measure: a single critical finding drops you to a D on purpose.

Copy report puts a Markdown table on your clipboard with the severity, key name, line number and finding for each issue. Values are never included, so the report is safe to paste into a ticket or a pull request.

No. It means nothing in this file matched a known pattern or an unsafe setting. It cannot tell you whether the file is in .gitignore, whether it was committed six months ago, whether the same key is pasted in a Slack thread, or whether the token has the right scopes. Those checks are on you.

Rotate it first, before cleaning anything up — a key that has been exposed stays exposed, and deleting the line does not un-expose it. Then check git history with git log --all --full-history -- .env; if it appears there, rewriting history is not enough on its own either. Rotate, then clean.

Not currently — the audit looks at values. It is worth remembering that a commented-out #OLD_API_KEY=… line is exactly as exposed as an active one, since the file is still a file.

Sixteen: .env, .env.example, JSON, YAML, Docker Compose, Dockerfile ENV, Kubernetes ConfigMap, Kubernetes Secret, a sourceable shell script, PowerShell, a systemd EnvironmentFile, a GitHub Actions env: block, gh secret set commands, Terraform tfvars, CSV, and a TypeScript env.d.ts.

Pick a format on the left and the preview on the right updates immediately from whatever is in the editor. Copy puts it on your clipboard, Download saves it with a sensible filename and extension. Switching format never re-reads or changes your source file.

It replaces every value with ******** in the exported output while keeping keys, comments and structure intact. Use it when you need to show someone the shape of your configuration — in a ticket, a document or a code review — without handing over the contents.

Every key is kept with an empty value, and all comments, section headers and blank lines are preserved exactly. That gives you a committable template that documents which variables the project needs, in the order and grouping you already use.

No, and it says so in the output. A Kubernetes Secret stores base64, which is an encoding, not encryption — anyone who can read the manifest can decode it with one command. The export gives you both the readable stringData form and the base64 data form; for real protection you still need encryption at rest, RBAC, or a tool like Sealed Secrets or an external secret store.

Two blocks. The first maps each key to ${{ secrets.KEY }}, which is what you actually want in a workflow. The second contains the literal values, for the non-sensitive variables where that is appropriate. There is also a separate gh secret set format that pushes every variable to your repository secrets in one script.

Because it turns a missing environment variable into a compile error instead of a runtime crash. The generated declaration extends NodeJS.ProcessEnv with your keys, so your editor autocompletes them and TypeScript objects when you reference a variable that does not exist.

The shell script uses export KEY='value' with single quotes escaped properly, so you can source env.sh in any POSIX shell. The systemd EnvironmentFile format has no export, no inline comments and its own quoting rules — systemd will not parse a shell script, which is a surprisingly common cause of a service that starts with empty configuration.

Everything is exported as a string, because that is what an environment variable is. PORT=3000 becomes "3000", not 3000. If you need real types, convert them in your application where the schema lives.

Yes — Import JSON / YAML takes a pasted object and converts it into .env lines. Nested JSON is flattened with underscores and upper-cased, so {"redis":{"host":"x"}} becomes REDIS_HOST=x. You can either replace the whole file or merge, which updates the keys that already exist and appends the new ones at the end.

No. The editor content is the source of truth and exports are generated from it on the fly. The only buttons that rewrite your file are the clean-up tools in the sidebar, and each one tells you exactly what it changed.

It diffs two .env files by key: what is missing from B, what only exists in B, which shared keys have different values, and how many are identical. It is the fastest way to answer “why does this work locally and not in staging”.

Use Editor into A or Editor into B to pull the file you are working on into either side, then paste the other one opposite it. Swap flips the two panes when you realise you have them the wrong way round.

That is the most useful case. Put .env.example in A and your real .env in B: everything listed as missing from B is a variable the project documents but your environment does not set. Turn off compare values so you only see the key-level differences.

Add these to B appends the keys that only exist in A to the B pane (with their values), and vice versa. It is meant for filling the gaps in a new environment file without copying lines by hand. It only touches the compare panes — your editor content is left alone.

It compares Database_Url and DATABASE_URL as the same key. Useful when two environments were maintained by different people with different habits, and you want the real differences rather than the casing noise.

Copy diff as Markdown produces a summary and lists of key names for each category, ready to paste into a pull request or a deployment checklist. Only key names are included — no values ever leave the tab.

Yes. With masking on, the diff shows which keys differ without showing what the values are — the right mode for going through an environment mismatch with someone else on a call.

Not in one pass. The practical approach is to use .env.example as the fixed reference in pane A and check each environment against it in turn — that catches drift better than comparing environments against each other anyway.

The tool is built so that it is: there is no back end, no upload, no analytics on your content, and nothing is written to browser storage. Your file is parsed by JavaScript already in the page and rendered back to the screen. You can verify it — open the network tab and it stays empty while you edit. If your policy forbids pasting production credentials into any web page, that policy still applies, and you can load the page once and work with the network disconnected.

No localStorage, no cookies, no IndexedDB for your content. That is a deliberate trade-off: it means a reload loses your work, and it also means nothing is left behind on a shared machine.

The site uses privacy-first page-view analytics with no cookies and no personal data. It records that the page was viewed. It has no access to what you type — that never leaves the JavaScript running in your tab.

A local .env is fine for development. For anything shared or deployed, use the platform's secret store — AWS Secrets Manager or Parameter Store, Google Secret Manager, Azure Key Vault, HashiCorp Vault, Doppler, Infisical, or your CI provider's encrypted secrets. The advantages are audit logs, rotation and access control, none of which a file on disk can give you.

Not over Slack or email — both keep searchable copies forever. Use a shared secret manager, an end-to-end encrypted one-time link, or age/gpg to encrypt the file before sending it. If you only need to show the structure, export with redact values on, or send the .env.example.

In this order: rotate every credential in it, then remove the file from history with git filter-repo or BFG, then force-push and tell anyone with a clone to re-clone. Rotation comes first because the moment a secret hits a remote — especially a public one — assume it has been scraped. Bots scan new GitHub commits for token patterns within seconds.

• Add .env and .env.* (except .env.example) to .gitignore on day one
• Add a pre-commit hook — gitleaks, git-secrets or trufflehog
• Turn on your host's secret scanning and push protection
• Commit .env.example so nobody is tempted to commit the real thing “just to share the keys”

Always. Sharing one API key between development, staging and production means a laptop compromise is a production compromise, and it makes rotation an all-or-nothing event. The reused secret finding in the audit exists for the same reason at the file level.

The honest answer is: whenever exposure is plausible, and on a schedule you can actually keep. Immediately after any suspected leak, when someone with access leaves, and periodically for high-value credentials. A rotation process that is used quarterly beats a monthly policy that nobody follows.

No. Base64 is an encoding — echo … | base64 -d reverses it in a second. It appears in Kubernetes Secrets and Docker configs for transport reasons, never for secrecy. The Kubernetes export in this tool says so directly in the generated file.

No, and it is not trying to. It is an editor, a linter and a converter for the files you already have. A secrets manager gives you storage, access control, rotation and audit trails. This tool helps you get the file right before it goes into one.

Free, no account, no limits, no telemetry on your content. It is one of a set of client-side browser tools at jasperbernaers.com/apps — no server means no running cost, and no server also means nothing that could leak.

Any current version of Chrome, Edge, Firefox, Safari, Brave, Opera or Vivaldi, on desktop or mobile. There are no external libraries or frameworks — the page is self-contained, which is why it also keeps working offline.