In short
A .env file is a plain text file that stores secrets and settings, like API keys and passwords, separately from your code so they never get published by accident. The name is short for "environment". Your app reads values from it at runtime, but the file itself is kept private and is never uploaded to GitHub. Getting this one habit right is the single best thing a beginner can do to avoid leaking a key.
What goes in a .env file
A .env file is a list of name and value pairs, one per line. Anything sensitive or environment-specific belongs here rather than hard-coded in your source files.
OPENAI_API_KEY=sk-your-secret-key
DATABASE_URL=postgres://user:pass@host/db
SITE_URL=http://localhost:3000The golden rule: keep it out of Git
The whole point of a .env file is that it stays private. You make sure Git never tracks it by listing it in a .gitignore file. The rule is absolute: secrets go in .env, .env goes in .gitignore, and a key never appears in code that gets committed.
# .gitignore
.env
.env.localIn production
On a real deployment you do not upload your .env file either. Instead you set the same names and values as "environment variables" in your hosting dashboard, for example in Vercel. That way production has its own separate keys, and a mistake in development can never touch live data.
Common beginner confusions
A frequent mix-up is between the secret value and its name. Your code refers to the name, like OPENAI_API_KEY, and the real secret only lives in the .env file and the host dashboard, never in the committed code. Another is the difference between a .env file (for secrets and settings) and .gitignore (the list of things Git should never track); they work together but do different jobs. If you ever do accidentally commit a key, do not just delete the line and move on. Treat the key as compromised, rotate it by generating a new one in the provider dashboard, and the old one becomes useless to anyone who saw it. Getting into this habit early means a slip is a minor annoyance, not a disaster.