snake_case Converter
Convert text to snake_case for Python variables, database columns, and file names. Free online snake_case converter.
Three steps to get started
Paste your text
Enter text in any format - English phrase, camelCase, kebab-case, or mixed.
Converts to snake_case
All words lowercased and joined with underscores. Separators removed.
Copy the identifier
Click Copy and paste into your Python, SQL, or configuration file.
snake_case: Python, databases, and file names
snake_case writes multi-word identifiers in all lowercase with an underscore between each word, as in total_order_value. It is the house style of Python, Ruby, Rust, C, and virtually every SQL schema - an ecosystem large enough that snake_case is probably the most-typed naming convention in software. Readability studies going back to the 1980s consistently find underscore-separated identifiers slightly faster to read correctly than camelCase, at the cost of a few extra keystrokes.
Where snake_case is the documented standard:
- Python - PEP 8 prescribes it for variables, functions, methods, and modules:
user_profile,get_user_by_id,calculate_total_price - SQL - table and column names:
first_name,created_at,is_active - Rust - the compiler emits a
non_snake_casewarning if you name a function otherwise - Ruby - methods and locals:
find_by_email, per the community style guide - Terraform and Ansible - resource names and variables:
instance_type,vpc_security_group_ids - C standard library -
str_len-style names predate camelCase's popularity entirely
Why databases push you toward snake_case
There is a technical reason SQL schemas are almost universally snake_case, not just a stylistic one. PostgreSQL folds unquoted identifiers to lowercase, so a column created as createdAt is silently stored as createdat and must be written "createdAt" - quotes and all - forever after. Oracle folds to uppercase. Underscores sidestep the whole problem because case folding cannot damage a name that has no case distinctions to lose.
The classic friction point is the boundary between a snake_case backend and a camelCase JSON API. Pick one side to convert on and be consistent: serializer-level mapping (Django REST Framework's djangorestframework-camel-case, Jackson's SNAKE_CASE naming strategy, Ecto's field sources) beats ad-hoc renaming scattered through controllers. Also watch the acronym trap - parse_HTTP_response should be parse_http_response, and a camelCase source like parseHTTPResponse is the input most converters mangle.
This converter splits on spaces, hyphens, dots, and existing underscores, and also detects camelCase and PascalCase boundaries, so helloWorld, Hello-World, and hello world all land on hello_world. Need the constant form instead? SCREAMING_SNAKE_CASE (MAX_RETRIES) has its own converter. Nothing you paste here is uploaded - the transformation is plain JavaScript running inside your own browser tab.