Convert Anything to snake_case

Convert any text, identifier, or heading to snake_case instantly. Handles camelCase, PascalCase, kebab-case, spaces, and mixed input. Runs entirely in your browser.

ZERO UPLOAD · ALL LOCAL
  1. Type or paste text into the input box — all 14 conversions appear instantly.
  2. The Character Case Formats section shows 5 character-level transformations.
  3. The Word Case Formats section shows 9 word-level transformations.
  4. Use the Copy buttons to grab any individual result.
  5. Click "Use as input" to chain conversions (e.g. snake_case → camelCase → kebab-case).

Worked examples for this use case

TypeScript interface → PostgreSQL column names

Before
userId
firstName
createdAt
isEmailVerified
phoneNumber
After
user_id
first_name
created_at
is_email_verified
phone_number

Title Case article fields → Python dataclass attributes

Before
Article Title
Published Date
Author Name
Category Tag
After
article_title
published_date
author_name
category_tag

INPUT TEXT

CHARACTER CASE FORMATS

lower case
UPPER CASE
Capitalized Case
aLtErNaTiNg cAsE
InVeRsE CaSe

WORD CASE FORMATS

camelCase
PascalCase
snake_case
SCREAMING_SNAKE
kebab-case
dot.case
path/case
sentence case
Title Case

snake_case Converter,Convert Anything to snake_case

When backend data crosses into Python, SQL, YAML, or JSON, snake_case is the format that usually survives. Getting identifiers into that shape before committing saves a round of find-and-replace later.1

This tool handles any input format (camelCase fields, PascalCase class names, Title Case headings, kebab-case slugs) and converts each to snake_case by splitting on all boundary types before joining with underscores. It is useful before linting, migrations, API mapping, or documentation updates.

Where snake_case is used

Python enforces snake_case for variables, functions, and module names per PEP 8, the language's official style guide.1 Beyond Python, PostgreSQL column names follow snake_case by convention, making ORM mappings cleaner.2 Environment variable naming in Linux shells and Docker Compose files uses SCREAMING_SNAKE, the uppercase cousin. Furthermore, Ruby, Rust, and Elixir all default to snake_case for function and variable names, making it the most cross-language-compatible identifier style for backend code.3 YAML and TOML configuration files across the DevOps ecosystem, from GitHub Actions workflow files to Helm chart values, use snake_case keys by convention. Even C and C++ projects that predate Python often adopt snake_case for internal APIs, and the Linux kernel coding style mandates it for all function and variable names across millions of lines of code.4

Edge cases: acronyms, numbers, and empty input

Acronyms in camelCase inputs (like "parseHTML" or "getHTTPCode") split at each letter boundary. "parseHTML" becomes "parse_html" and "getHTTPCode" becomes "get_http_code". Numbers follow the same logic: "address2" becomes "address_2" and "h1Tag" becomes "h_1_tag". Yet empty lines are passed through unchanged, so pasting a list with blank separators between groups does not produce unwanted underscores. Mixed input formats combine correctly: a string like "XML-HTTP-Request" produces "xml_http_request" regardless of whether the original separators were hyphens, spaces, or camelCase boundaries. PascalCase class names like "UserProfile" convert cleanly to "user_profile". When your input already contains underscores, the converter preserves them as word boundaries rather than doubling them up, so "first__name" correctly yields "first_name" with single underscore separation.

Workflow: renaming fields before writing a database migration

Building on this, here is a practical pattern. When you have a TypeScript interface with camelCase fields and need to write a PostgreSQL migration, paste the field names into this tool, copy the snake_case output, and use those names directly in your CREATE TABLE statement. You avoid manual renaming one field at a time, and your column names match the ORM expectations on the first try. The same process works when mapping a REST API response to a Python dataclass. For Alembic migrations in SQLAlchemy, the column names you write in op.add_column() calls must match the model attribute names exactly. Getting them right in one conversion pass before writing the migration prevents a follow-up renaming migration later, which is especially important once the migration has run in production and rollback requires coordinated downtime.

Preparing field names before writing database migration files

Database migration scripts are permanent. Once a migration runs in production, renaming a column requires another migration, a deploy, and coordination with any queries that reference the old name. Getting the name right the first time matters, and snake_case is the column-naming convention across PostgreSQL, MySQL, and SQLite. A single poorly named column in a production migration can trigger hours of coordinated downtime across multiple services, which is why batch-converting your field names before writing the migration is a small investment that prevents an expensive operational incident. The converter handles every input format you might paste into it, including camelCase, PascalCase, kebab-case, and mixed separators, so you can standardize from any source without manual cleanup.

ORM field mapping and column naming

SQLAlchemy, Django ORM, and Active Record all use snake_case Python or Ruby attribute names and map them directly to column names unless you override explicitly.5 Paste your planned attribute names in to verify the column names before migrating, then copy those names into both your migration file and your model definition at the same time. The two stay in sync because they come from the same conversion pass. CapyToolkit processes each line independently, so a schema with 40 fields converts in one paste.

Keeping the model and migration aligned prevents a common class of bugs. When the model attribute and the column name diverge, queries fail at runtime in ways that unit tests rarely catch. You can confirm the names match by running your field list through CapyToolkit and checking that the converted output is identical in both files, which removes the manual cross-check from the review process.

Converting identifiers for environment variables and shell scripts

Environment variables in UNIX-like operating systems are uppercase by convention, but the internal naming still uses underscores between words. Bash scripts, Docker Compose files, and .env templates all follow this pattern, and snake_case is the intermediate step in generating those names. Converting your source identifiers to snake_case first and then applying an uppercase step is a reliable two-step workflow that avoids the naming inconsistencies that arise from manual editing.

From camelCase config keys to SCREAMING_SNAKE environment variable names

Application configuration often starts as camelCase in source code: maxConnections, dbHost, apiTimeout. Converting to snake_case first gives you the lowercase form: max_connections, db_host, api_timeout. From there, applying UPPERCASE produces the final environment variable name. This two-step approach prevents the naming inconsistencies that arise when developers manually edit environment variable names from memory. Paste your camelCase config key list into this converter, copy the snake_case output, then run it through the UPPERCASE converter for the final result. CapyToolkit handles the first conversion; the UPPERCASE converter handles the second.

Shell variable naming in CI pipeline scripts

GitHub Actions, GitLab CI, and Bash scripts use uppercase snake_case for environment variables passed between steps. When your pipeline sets output variables from a Node.js script that uses camelCase property names, you need to convert before exporting. Running the camelCase property names through this converter first gives you the intermediate snake_case form, and from there the SCREAMING_SNAKE form follows directly.

When to use this

Use this when you need to convert TypeScript interface fields to database column names, rename Python variables to match PEP 8, or produce snake_case keys for a YAML config file.

Examples

TypeScript interface → PostgreSQL column names

Before
userId
firstName
createdAt
isEmailVerified
phoneNumber
After
user_id
first_name
created_at
is_email_verified
phone_number

Title Case article fields → Python dataclass attributes

Before
Article Title
Published Date
Author Name
Category Tag
After
article_title
published_date
author_name
category_tag
Sources
  1. 1.

    Guido van Rossum et al., "PEP 8 – Style Guide for Python Code," peps.python.org, accessed June 2026. https://peps.python.org/pep-0008/#function-and-variable-names

  2. 2.

    PostgreSQL Global Development Group, "PostgreSQL: Documentation: 18: 4.1. Lexical Structure," postgresql.org, June 2026. https://www.postgresql.org/docs/current/sql-syntax-lexical.html

  3. 3.

    Aaron Rusbatch et al., "The Rust Style Guide: Naming Conventions," doc.rust-lang.org, accessed June 2026. https://doc.rust-lang.org/1.7.0/style/style/naming/README.html

  4. 4.

    Linux kernel maintainers, "Linux Kernel Coding Style: Chapter 4 – Naming," docs.kernel.org, accessed June 2026. https://docs.kernel.org/process/coding-style.html

  5. 5.

    SQLAlchemy contributors, "ORM Mapped Class Configuration — SQLAlchemy 2.0 Documentation," docs.sqlalchemy.org, accessed June 2026. https://docs.sqlalchemy.org/en/20/orm/mapper_config.html

FAQ