Snake Case Converter Online
Snake case writes all words in lowercase and joins them with underscores: “user_account_balance” rather than “userAccountBalance” or “user-account-balance”. It is the naming convention mandated by Python’s PEP 8 for variables, functions, and module names, and the default for database column names in PostgreSQL and MySQL. Paste your text above to convert instantly. Nothing is uploaded.
Related case converters
How the snake case converter works
Paste your text into the input panel and it converts to snake_case automatically. Every letter is lowercased, spaces and hyphens become underscores, and camelCase or PascalCase input is split at uppercase letter boundaries before converting. Turn off auto-run and hit convert manually if you prefer to control when the conversion runs.
What snake_case is
snake_case is a naming convention where all words are lowercase and separated by underscores. “Get user profile data” becomes “get_user_profile_data”. The name comes from the visual effect of underscores lying flat between words like a snake on the ground.
It is also called snail_case and pothole_case in some references, though both names refer to the same format. Lower snake_case is the most common variant. SCREAMING_SNAKE_CASE, the uppercase variant, is a separate convention covered below.
snake_case vs camelCase
Python chose snake_case over camelCase when the PEP 8 style guide was written in 2001, partly for readability reasons. Research on identifier readability found that underscore-separated names are easier to read for most people when the names are longer than two or three words. “calculate_total_order_price” reads more naturally than “calculateTotalOrderPrice” for many readers, particularly those for whom English is not a first language.
JavaScript chose camelCase, establishing a split that defines where each convention lives today: snake_case in Python and database work, camelCase in JavaScript and Java. If you are building an API that bridges both worlds, you often need to convert between the two. The camelCase converter handles the reverse direction when you need to go from snake_case back to camelCase for a JavaScript consumer.
Where snake_case is used
Python variables and functions are the primary use. PEP 8, the official Python style guide, explicitly mandates snake_case for variable names, function names, method names, module names, and package names. Class names use PascalCase. Constants use SCREAMING_SNAKE_CASE. These rules are enforced by most linters including Pylint and Flake8.
Database column names across PostgreSQL, MySQL, and SQLite follow snake_case by convention. PostgreSQL is case-insensitive by default and folds all unquoted identifiers to lowercase, which effectively makes snake_case the only practical naming format for column names. Django’s ORM generates snake_case column names from model field names by default. SQLAlchemy follows the same pattern.
Ruby on Rails uses snake_case throughout. Variable names, method names, file names, database column names, and route helpers are all snake_case. Rails generates database migrations, model files, and controller names in snake_case automatically when you use the generators.
Configuration files and environment variables in many frameworks use snake_case. Python’s dotenv files, Django settings modules, and many YAML and TOML configuration files all use snake_case keys. This is distinct from SCREAMING_SNAKE_CASE which is used for environment variables at the OS level.
File names in Python projects use snake_case to match module names. A file named “user_profile.py” imports as “import user_profile”. Using camelCase or kebab-case in Python filenames creates import name mismatches since Python module names follow the same snake_case convention. For the web URL layer where hyphens are needed instead of underscores, the kebab-case converter handles that conversion separately.
SCREAMING_SNAKE_CASE
SCREAMING_SNAKE_CASE is the uppercase variant where every letter is capitalized and words are separated by underscores. It is used for constants in Python, environment variables at the OS level, and configuration values that should not be reassigned at runtime.
In Python, a constant like the maximum number of login attempts is written MAX_LOGIN_ATTEMPTS, not max_login_attempts. Django settings are all SCREAMING_SNAKE_CASE: DEBUG, DATABASES, ALLOWED_HOSTS, SECRET_KEY. Environment variables loaded via os.environ or dotenv are typically SCREAMING_SNAKE_CASE: DATABASE_URL, AWS_ACCESS_KEY_ID, SENDGRID_API_KEY.
To produce SCREAMING_SNAKE_CASE, convert to snake_case here first, then run the output through the uppercase converter to capitalize all letters. The result is the correct format for constants and environment variable names.