How to Convert to CONSTANT_CASE (Constants and Environment Variables)
CONSTANT_CASE, also called screaming snake case, uppercases every word and joins them with single underscores. Constants, config keys and environment variables mostly use it.
Open the tool：CONSTANT_CASE Converter
When you need all caps with underscores
Integrating a third-party service usually brings a dozen settings at once: max retry count, request timeout, api base url. When they go into a .env file or a config module, the keys need one shape, or half the file is uppercase and half is not and every reader rechecks the spelling.
Constants in code behave the same way. A module holding both maxRetries and MAX_TIMEOUT has no consistent style. Converting a batch to one form and then reviewing what each constant is for beats deciding the casing while you type.
- Environment variables and .env keys
- Code constants, enum values and config defaults
- Strings conventionally written in caps, such as header names
- Normalising old constants that mix styles
The rule and two easily missed details
The order is: split on the boundary between a lowercase letter or digit and an uppercase letter, trim the ends, uppercase everything, then collapse runs of non-alphanumeric characters into one underscore. So max retry count, maxRetryCount and max-retry-count all become MAX_RETRY_COUNT.
Digits stay attached rather than forming their own segment: version2 gives VERSION2, and max retry 2 gives MAX_RETRY_2. Trimming happens before uppercasing, so input starting with a symbol can leave a leading underscore. Glance at the first and last characters before pasting into a .env file.
- Camel boundaries split: maxRetryCount → MAX_RETRY_COUNT
- Repeated separators merge into one underscore
- Digits follow the neighbouring word: version2 → VERSION2
- Chinese is dropped, so translate first
- Check for stray underscores at the ends
What platforms actually allow
POSIX shell variable names use letters, digits and underscores and cannot start with a digit, so 2FA_KEY is unusable in a shell and has to become TWO_FA_KEY or KEY_2FA. Windows environment variables are case-insensitive, so PATH and Path are the same variable. A .env file has no formal spec, but the common loaders all parse KEY=VALUE.
The tool checks none of that. It does not validate length, detect duplicate keys, or judge whether a value should be a secret at all. Before trusting a name, read it back in the target environment with printenv or your config loader, so a silently unset variable does not surface as a runtime error.
- Shell names cannot start with a digit
- Windows environment variables are case-insensitive
- No duplicate or length checks
- Verify the variable reads back before deploying
FAQ
Why are environment variables usually uppercase?
It comes from history and readability. Early terminals had only uppercase, and the habit carried into C macros and shell conventions, where case separates configuration from ordinary variables. Most systems do not enforce it, but a config key still stands out.
What happens to digits?
Digits stay attached to the neighbouring word and no underscore is inserted automatically. max retry 2 becomes MAX_RETRY_2 and version2 becomes VERSION2. Separate the number with a space in the input, or add the underscore afterwards, if you want it on its own.
Is there a length limit on constant names?
It depends on the platform. Shell and most languages put no hard cap on identifier length, but some systems limit the total environment block and Windows caps individual names and values. The tool does not check length, so test long names where they will run.
Related tool：CONSTANT_CASE Converter