Loading page
About this tool
Check environment variable names against POSIX rules, UPPER_SNAKE_CASE convention, reserved names and risky prefixes.
This tool checks environment variable names against the POSIX portable rule [A-Za-z_][A-Za-z0-9_]* (IEEE Std 1003.1, section 8.1), the UPPER_SNAKE_CASE convention, reserved system names such as PATH and IFS, and platform-owned prefixes like GITHUB_, LD_, npm_ and NEXT_PUBLIC_. It is for developers naming new configuration variables who want them to work identically in shells, Docker, CI runners and frontend build tools.
Open Env Var Naming Checker on AltFTool — it loads instantly in your browser.
Paste your code or data sample into the workspace.
Pick the format, conversion, or analysis you need.
Copy the polished result straight back into your project.
The core rule is POSIX IEEE Std 1003.1 §8.1, so an accepted name is portable across shells, exec environments and Docker.
Flags GITHUB_ (rejected by GitHub Actions), LD_/DYLD_ (linker-interpreted), npm_, AWS_, KUBERNETES_ and more, each with the reason.
A secret-looking name under a client-exposing prefix like NEXT_PUBLIC_ is reported as an error, not a style nit.
Portably: an uppercase or lowercase letter or underscore, followed by letters, digits or underscores — the POSIX pattern [A-Za-z_][A-Za-z0-9_]*. Hyphens, dots and names starting with a digit may work in some language-level parsers like npm's dotenv, but shells, docker --env-file and most CI systems reject them.
GitHub's documentation reserves the GITHUB_ prefix for variables the runner itself sets (GITHUB_SHA, GITHUB_REF and so on), and attempts to set a custom GITHUB_-prefixed variable via the environment files API fail with an error. Use a project-specific prefix instead.
No. Next.js inlines every NEXT_PUBLIC_ variable into the JavaScript shipped to browsers at build time, so the value becomes public to anyone who opens dev tools. The same applies to VITE_, REACT_APP_, GATSBY_ and EXPO_PUBLIC_ prefixes — keep secrets in server-only variables.
By convention, yes — POSIX section 8.1 notes that uppercase names are used by the system and standard utilities, while lowercase names are reserved for application and shell-local use. UPPER_SNAKE_CASE also prevents case-confusion bugs, because environment lookups are case-sensitive on Linux but case-insensitive on Windows.