🐍 camelCase & snake_case Converter
Convert variable names between all four naming conventions instantly.
One name per line. Supports camelCase, snake_case, PascalCase, kebab-case, and plain words.
Why Naming Conventions Matter More Than You Think
Every programmer eventually faces the same friction: you're writing Python code and need to call a JavaScript API, or you're documenting a database schema while building a TypeScript frontend. One system wants user_profile_id, another wants userProfileId, and your CSS class needs to be user-profile-id. Manually converting between these formats dozens of times a day is slow, error-prone, and honestly a little soul-crushing.
This guide walks through the four major variable naming conventions used across modern software development, explains exactly when each one applies, and shows you how to convert between them quickly — whether you're doing it by hand, with a tool, or writing your own converter function.
The Four Naming Conventions Explained
camelCase
camelCase starts with a lowercase letter, then capitalizes the first letter of each subsequent word. No separators, no spaces. The name comes from the visual "humps" created by the uppercase letters: getUserData, isLoggedIn, fetchApiResponse.
Where it lives: JavaScript variables, TypeScript interfaces, Java methods, Swift properties, JSON keys in most APIs, React component props. If you're writing frontend JavaScript, you're almost certainly using camelCase for your variables and function names.
snake_case
snake_case uses all lowercase letters with underscores as separators: get_user_data, is_logged_in, fetch_api_response. It reads almost like plain English, which makes it popular in languages and contexts that prioritize readability.
Where it lives: Python (PEP 8 mandates it for variables and functions), Ruby, database column names, PHP variables, C/C++ in many codebases, environment variable names. The PostgreSQL and MySQL ecosystems both prefer snake_case for table and column names, making it essential for backend and database work.
PascalCase
PascalCase (also called UpperCamelCase) capitalizes the first letter of every word, including the first: GetUserData, UserProfile, FetchApiResponse. It's a slight variation of camelCase but carries a distinct semantic meaning in most languages.
Where it lives: Class names in nearly every object-oriented language (Java, C#, Python, TypeScript, PHP), React component names, C# methods and properties, constructor functions in JavaScript. When you see PascalCase in code, your brain is trained to think "this is a class or a constructor" — the convention carries meaning beyond just aesthetics.
kebab-case
kebab-case uses all lowercase with hyphens as separators: get-user-data, is-logged-in, user-profile-card. The name references the visual of items "skewered" on a kebab stick. Most programming languages cannot use hyphens in variable names (because - is a subtraction operator), which limits where this convention appears.
Where it lives: CSS class names and IDs (the dominant convention in all CSS frameworks), HTML attributes, URL slugs and routes, npm package names, Lisp-family languages, YAML keys in Kubernetes manifests. If you're writing class="product-card--featured" in your HTML, that's kebab-case.
The Core Problem: Cross-System Work
Modern applications routinely cross multiple naming-convention boundaries. A typical full-stack project might have:
- A PostgreSQL database with columns like
created_at,user_id,profile_image_url(snake_case) - A Python FastAPI or Django backend that mirrors those names, also in snake_case
- A REST API that returns JSON, often converted to camelCase:
createdAt,userId,profileImageUrl - A TypeScript/React frontend consuming that API with camelCase variables
- CSS classes in kebab-case:
profile-image-url - React components in PascalCase:
UserProfileCard
That single concept — a user's profile image URL — gets written in four different ways across your stack. When you're refactoring, onboarding new API fields, generating code, or writing documentation, manually tracking all those transformations introduces mistakes.
How Conversion Actually Works
Converting between naming conventions is a two-step process under the hood: first you tokenize the input into individual words, then you reassemble them in the target format.
Step 1 — Tokenize: Split the input string into its component words. For camelCase and PascalCase, you detect word boundaries where a lowercase letter is followed by an uppercase letter (or where multiple uppercase letters precede a lowercase one, as in XMLParser). For snake_case and kebab-case, you split on underscores and hyphens. Plain space-separated words are trivially split on spaces.
Step 2 — Reassemble: Join the tokens in the target format. For snake_case: lowercase everything, join with underscores. For camelCase: lowercase the first token, capitalize the first letter of every subsequent token, join with no separator. For PascalCase: capitalize the first letter of every token, join with no separator. For kebab-case: lowercase everything, join with hyphens.
The tricky edge case is consecutive uppercase acronyms: getHTTPResponse. A naive camelCase detector sees "HTTP" as one "word," but it's really four letters forming an acronym. Good converters handle this by detecting sequences of uppercase letters before a lowercase letter as a separate token boundary.
Practical Tips for Daily Use
When copying from a database to your frontend: SQL column names almost always come back in snake_case from ORMs. Before mapping them to your frontend state, run them through a converter to get properly cased camelCase properties. This is especially useful when a new table gets dozens of columns — convert them all at once instead of one by one.
When writing CSS for a component: Take your JavaScript component variable names (camelCase or PascalCase) and convert them to kebab-case for consistent BEM-style class names. ProductCard becomes product-card, and its modifier becomes product-card--featured.
When generating boilerplate: If you're creating a new module and need to declare it in multiple files — a Python module (snake_case), a class (PascalCase), a URL route (kebab-case), and a JS import variable (camelCase) — convert a single canonical name into all four at once.
When switching stacks: Moving from a Node.js project to a Python project? All your camelCase variables need to become snake_case. A batch converter handles a whole file's worth of variable names in seconds.
Common Mistakes to Avoid
Don't mix conventions within a single codebase layer. Using user_name in one Python function and userName in another creates cognitive overhead for every future reader. Pick one convention per context and stick to it — linters like ESLint (for JS) and Flake8/Black (for Python) can enforce this automatically.
Also watch for acronyms. Teams argue about whether ID should be userId or userID in camelCase. Whatever your team decides, be consistent. Most style guides (including Google's and Airbnb's) treat acronyms as regular words: userId, not userID; xmlParser, not xMLParser.
With a reliable converter, you spend zero mental energy on formatting and all your attention on logic — which is exactly where it belongs.