Convert Anything to CONSTANT_CASE

CONSTANT_CASE Converter,Convert to SCREAMING_SNAKE

For values that never change at runtime, CONSTANT_CASE makes the intent visible immediately. Python constants, JavaScript config flags, C preprocessor macros, and environment variables all follow this pattern.

This tool converts any input (camelCase, PascalCase, kebab-case, or spaces) to CONSTANT_CASE by splitting on all word boundaries and joining with underscores in uppercase.

Where CONSTANT_CASE is used

Python uses SCREAMING_SNAKE_CASE for module-level constants, as specified in PEP 8.¹ JavaScript and TypeScript use it for compile-time constants and immutable config values, per the Google JavaScript Style Guide.² C and C++ preprocessor macros are written in SCREAMING_SNAKE by the GNU Coding Standards.³ Furthermore, all environment variables passed to Docker containers, shell scripts, or CI systems use this format: DATABASE_URL, SECRET_KEY, MAX_RETRIES.⁴ AWS Systems Manager Parameter Store paths, Azure App Configuration keys, and Google Cloud Secret Manager secret names all follow CONSTANT_CASE by convention. Even in languages that do not enforce it at the compiler level, like Ruby (which uses SCREAMING_SNAKE for constants as a community convention), the pattern signals immutability to anyone reading the code.

Edge cases: acronyms, mixed inputs, and single-word values

When an input already contains uppercase letters, like "parseHTML", the splitter separates on camelCase boundaries and produces "PARSE_HTML". Numbers act as word boundaries: "retryAfter3Seconds" becomes "RETRY_AFTER_3_SECONDS". Yet single-word inputs like "timeout" convert simply to "TIMEOUT" with no underscores added. Empty lines pass through unchanged, making it safe to paste a block of mixed declarations. Mixed separator inputs like "my-mixed_separator" produce "MY_MIXED_SEPARATOR", correctly handling the case where configuration keys from different sources use different separator conventions. PascalCase class names like "UserProfile" convert to "USER_PROFILE", which is the standard format for feature flags or permission names derived from class identifiers. SCREAMING_SNAKE input that is already in the target format passes through unchanged, so re-converting an already-formatted list is safe.

Workflow: converting a .env template to exported constants

Building on this, a common pattern is to draft new environment variable names in camelCase during development (since most code editors autocomplete camelCase identifiers), then convert the entire list to CONSTANT_CASE before adding them to a .env file or a configuration module. Paste all the camelCase names at once, copy the CONSTANT_CASE output, and you have the canonical variable names for documentation, CI configuration, and the application code simultaneously.

.env templates from camelCase drafts

When drafting new configuration entries, developers often start with camelCase names in source code. Converting those drafts to CONSTANT_CASE gives you the canonical environment variable names that belong in your .env file. Use the output as the single source of truth for both your .env template and your application config module so the names stay consistent across documentation, CI configuration, and the running application before code review.

The single source of truth approach removes a frequent source of bugs. When the .env template, the config module, and the docs all derive their names from one converted list, a typo cannot hide in just one of them. You can generate that list in CapyToolkit by pasting your camelCase drafts and converting them, then copying the output into each location so the casing stays identical everywhere.

Environment variable naming in .env files and the dotenv specification

The .env file format originated with the Ruby dotenv gem⁵ and became the standard for twelve-factor application configuration across all languages. Every key in a .env file follows CONSTANT_CASE by convention, though the format itself does not enforce it. Libraries like python-dotenv, Node.js dotenv, and the Go godotenv package parse the file without casing validation, which means inconsistently named keys silently coexist.

Validation at the application startup level catches naming inconsistencies before they cause runtime surprises. The Python pydantic-settings library reads environment variables into a Pydantic model where field names must match the variable names, with an option for case-insensitive matching. The Node.js envalid library provides explicit spec-declaration for each required variable, raising errors at startup for missing or incorrectly named variables.

Validation at application startup

pydantic-settings v2 maps environment variables to model fields using the env parameter or by convention: a field named database_url reads DATABASE_URL from the environment. Configuring env_prefix = "APP_" on the SettingsConfigDict means APP_DATABASE_URL maps to database_url. Run the app with missing variables to confirm the error message names the missing key in CONSTANT_CASE. This makes debugging environment configuration much faster than discovering a missing variable only after a specific code path executes.

Terraform variable naming: HCL inputs versus CONSTANT_CASE environment overrides

Terraform uses lowercase snake_case for variable names in HCL configuration files. However, when you override those variables using environment variables (the TF_VAR_ prefix), the environment variable uses TF_VAR_ in uppercase followed by the lowercase snake_case variable name.⁶ This two-format system trips up developers who expect the same casing in both places.

A Terraform variable declared as variable "database_url" {} is overridden by the environment variable TF_VAR_database_url. Note that the TF_VAR_ portion is uppercase but the variable name segment stays lowercase, unlike the CONSTANT_CASE convention used for other environment variables. Knowing this distinction prevents mistakes when you use this converter to generate environment variable names for Terraform overrides.

AWS Systems Manager Parameter Store and CONSTANT_CASE paths

AWS SSM Parameter Store paths often use CONSTANT_CASE for the leaf parameter name segment: /myapp/production/DATABASE_URL. Applications that read parameters from SSM at startup must request the exact path, and the leaf name must match the expected environment variable name exactly. Paste your planned environment variable names into this converter before registering them in SSM and in your .env files to ensure both sources use consistent CONSTANT_CASE. Mismatches between SSM parameter names and application variable names are silent: the variable reads as undefined rather than raising an error.

When to use this

Use this when naming new environment variables, declaring Python module constants, or writing C preprocessor macros, and draft the env var names in CONSTANT_CASE before code review so the same spelling reaches your config module, your CI settings, and your documentation.

Examples

databaseUrl
secretKey
maxRetries
apiTimeoutMs

DATABASE_URL
SECRET_KEY
MAX_RETRIES
API_TIMEOUT_MS

default_page_size
max_upload_size_mb
allowed_hosts

DEFAULT_PAGE_SIZE
MAX_UPLOAD_SIZE_MB
ALLOWED_HOSTS