Convert snake_case to kebab-case

snake_case to kebab-case Converter

Before Python names become URLs, CSS properties, or CLI flags, their separator needs to change. Python variable names (snake_case) map to URL slugs (kebab-case). Database column names (snake_case) map to CSS custom properties (kebab-case). Getting this separator swap right across a large set of names is exactly what this tool handles.

Yet this is not just a find-and-replace for underscores. The converter lowercases the full string and collapses consecutive separators before joining with hyphens.

Where snake_case names need kebab-case equivalents

Google's URL guidelines recommend hyphens as word separators in URLs rather than underscores, because search engines treat hyphens as word boundaries but not underscores.¹ Consequently, if your database stores article slugs in snake_case, converting them to kebab-case before rendering URLs improves search visibility. This separator swap also applies to CSS custom property names, which require kebab-case after the double-hyphen prefix, and to CLI flags that follow the GNU convention of hyphen-separated long options.

URL slugs and CSS custom properties

Google's Search Central documentation states that hyphens in URLs are treated as word separators, while underscores are not. This means a URL like "/new-york-city" is indexed as three separate tokens, whereas "/new_york_city" may be indexed as a single token. CSS custom properties also use kebab-case after the two-hyphen prefix, so a Python configuration key like "max_file_size" becomes "max-file-size" as the CSS variable name.² Converting your snake_case names to kebab-case before using them as URL slugs or CSS variable names ensures consistency across your project.

Applying the same conversion at both ends of a name keeps a project consistent without a lookup table. A slug stored in the database, the URL rendered in the browser, and the CSS variable referenced in the stylesheet can all derive from one kebab-case value. When a new route or token is added, generating its kebab-case form once and reusing it everywhere prevents the drift where the database holds snake_case, the URL shows kebab-case, and the stylesheet expects yet another spelling. That single source of truth is what makes a rename safe to apply across the stack.

Edge cases: uppercase, consecutive underscores, and numbers

SCREAMING_SNAKE_CASE input,like "MAX_FILE_SIZE",converts to "max-file-size" (lowercased and hyphens substituted). Consecutive underscores ("first__name") collapse to a single hyphen: "first-name". Numbers maintain their position: "address_2" becomes "address-2". Yet if a snake_case name contains a hyphen,which it should not by convention,the hyphen is also treated as a separator. PascalCase input like "UserProfile" converts to "user-profile" because the splitter detects camelCase boundaries before replacing separators. Mixed-format input from multiple sources, such as a configuration file that mixes SCREAMING_SNAKE keys with regular snake_case keys, normalizes to a consistent kebab-case output. Empty lines pass through unchanged, so pasting a list with blank separators between groups does not produce unwanted hyphens or empty segments.

Workflow: converting a Python route registry to URL slugs

Building on this, if your Python Flask or Django routes use snake_case function names and you want to generate the corresponding URL paths, paste the function names into this converter and copy the kebab-case output as your URL segments. "user_profile" becomes "user-profile", "order_history" becomes "order-history". CapyToolkit processes each line independently. For Django REST Framework viewsets, the basename in your URL configuration often derives from the model name in snake_case. Converting it to kebab-case before registering the route produces clean, readable URLs that follow Google's recommendation for hyphen-separated path segments. When you migrate an existing API from snake_case URL segments to kebab-case, running the old segment names through this converter gives you the exact mapping for your 301 redirect rules, ensuring existing bookmarks and external links continue to resolve.

Google Search's treatment of URL word separators for indexing

Google Search treats hyphens and underscores differently when indexing URLs, which has direct SEO implications for pages whose slugs come from snake_case database fields or Python route identifiers. When a URL path uses underscores to separate words, Google may not recognize those words as individual tokens during indexing, reducing the page's relevance for multi-word search queries. Converting snake_case slugs to kebab-case before they reach the browser ensures each word in the path contributes to the page's search profile.

Google's Search Central documentation states that hyphens are treated as word separators in URLs, while underscores are not.¹ A URL like /new-york-city is indexed with three separate tokens: "new", "york", "city". A URL like /new_york_city is indexed as a single token "newyorkcity" in some contexts. For competitive keywords where individual word matching matters, hyphens produce more accurate indexing. This matters most for long-tail URLs built from database slugs that were originally stored as snake_case.

URL normalization in existing Python codebases

Django's slug fields default to snake_case for legacy reasons in some codebases. Converting existing slug fields to kebab-case requires a migration that updates the stored values, plus 301 redirects from the old snake_case URLs to the new kebab-case ones. Before starting that migration, paste a sample of your existing slugs in to see how each underscore becomes a hyphen and confirm the conversion produces valid, readable URLs. CapyToolkit processes each line independently, so testing a batch of existing slug values takes one paste. Run the migration only after confirming the output looks correct for all edge cases in your slug set, including slugs that contain numbers, consecutive underscores, or uppercase letters that appear in older database records.

Ansible and Kubernetes YAML variable naming across kebab-case and snake_case

Ansible uses snake_case for variable names in playbooks and roles.³ Kubernetes YAML uses kebab-case for resource label keys and some annotation keys.⁴ When you share configuration values between Ansible provisioning and Kubernetes manifests, you encounter both naming formats in the same infrastructure codebase. This naming mismatch appears most often when Ansible defines infrastructure parameters that Kubernetes consumes as labels or selectors, forcing you to maintain a consistent mapping between the two separator styles across your deployment pipeline.

Ansible variable names in defaults/main.yml files are snake_case: database_url, replica_count, max_memory_mb. Kubernetes label keys in metadata.labels use kebab-case: app.kubernetes.io/name, component: database-primary. The same conceptual value often appears in both places with different separator characters, requiring a consistent conversion strategy. When you paste Ansible variable names into this converter, you get the exact kebab-case equivalents that Kubernetes expects, eliminating the manual separator substitution that introduces typos in infrastructure-as-code repositories.

Helm chart values and naming conventions

Helm chart values.yaml files use camelCase for user-configurable values by the Helm community convention, but the rendered Kubernetes YAML uses kebab-case label keys. When your Helm templates read Ansible-generated configuration and render it into Kubernetes labels, the conversion from snake_case Ansible variables to kebab-case label values must happen in the template. Paste your Ansible variable names into this converter to preview the kebab-case label values before writing the Helm template logic. CapyToolkit processes each line independently.

When to use this

Use this when converting Python variable names to URL slugs, transforming database column names to CSS custom property names, or mapping snake_case config keys to kebab-case CLI flags.

Examples

user_profile
order_history
payment_summary
account_settings

user-profile
order-history
payment-summary
account-settings

background_color
font_size_large
border_radius

background-color
font-size-large
border-radius