Free Case Converter

Why Naming Conventions Matter and How This Case Converter Helps

Every programming language, framework, and platform enforces its own naming convention. JavaScript and TypeScript use camelCase for variables and functions. Python, Ruby, and Rust use snake_case. CSS uses kebab-case for class names and custom properties. Java, C#, and React use PascalCase for classes and components. Go uses PascalCase to mark identifiers as exported and camelCase for package-private names. Environment variables, constants, and enum values universally use CONSTANT_CASE (also called SCREAMING_SNAKE_CASE). Violating these conventions does not always cause errors, but it makes code harder to read, triggers linter warnings, and signals inexperience to other developers reviewing your work.

This tool converts text to all 9 common cases simultaneously, so you can see every option at once and copy the one you need. It handles mixed-case input, acronyms like "HTMLParser" or "APIKey," and special characters, splitting words intelligently at case transitions, separators, and whitespace before reassembling them in each target convention. Whether you are converting database column names from snake_case to camelCase for a REST API response, turning a blog post title into a URL slug, or renaming a Python function to match JavaScript conventions, you get the result in one paste and one click.

A Brief History of Programming Naming Conventions

The underscore convention that became snake_case dates back to the 1960s, when IBM mainframe systems used underscores to separate words in data field names. It was popularized in the 1970s by the C programming language and later formalized in Python PEP 8 in 2001. The term "snake_case" itself first appeared on Usenet in 2004, coined in the Ruby community by Gavin Kistner, the name comes from the visual resemblance of underscores to a snake slithering between words.

camelCase emerged at Xerox PARC in the late 1970s. The PARC Mesa Language Manual (1979) included strict coding standards using medial capitals, and the convention spread through the Smalltalk language in the early 1980s. Niklaus Wirth, creator of Pascal, adopted the style after a PARC sabbatical and carried it into Modula. The term "CamelCase", referring to the humps formed by capital letters, appeared on Usenet by 1990. PascalCase is simply camelCase with the first letter also capitalized, named after the Pascal language where it was standard.

kebab-case is the youngest convention by name. While hyphens have been used in CSS property names (background-color, font-family) and HTML attributes (aria-label, data-*) since the earliest web standards, the term "kebab-case" was first recorded in a Stack Overflow post in 2013. It is now the standard for CSS class names (BEM uses it), URL slugs (Google treats hyphens as word separators), and CLI flags (--output-dir). CONSTANT_CASE, meanwhile, inherited from C preprocessor macros (#define BUFFER_SIZE) and became the universal convention for compile-time constants, enum values, and environment variables across nearly every language.

Case Conventions Across Languages, APIs, and Databases

Choosing the right case convention depends on context. For code identifiers, follow the language standard: camelCase for JavaScript/TypeScript variables and functions, snake_case for Python/Ruby/Rust, PascalCase for classes in Java/C#/TypeScript and for React/Vue components, and CONSTANT_CASE for constants everywhere. In Go, the convention does double duty, PascalCase identifiers (MyFunc) are exported from a package, while camelCase identifiers (myFunc) are package-private, replacing public/private keywords entirely.

For REST API JSON fields, the ecosystem is split. camelCase is the most common choice for APIs consumed by JavaScript frontends, since it matches the language convention and avoids runtime field-name mapping. Google, Twitter, and Stripe all use camelCase in their JSON APIs. APIs consumed primarily by Python or Ruby backends sometimes prefer snake_case for consistency. The key rule is consistency, pick one and enforce it across every endpoint, using a DTO layer to translate between your database convention and your API convention if they differ.

For databases, snake_case is the safest and most widely recommended convention. PostgreSQL folds unquoted identifiers to lowercase, so CreatedAt becomes createdat unless double-quoted in every query, a maintenance burden that snake_case (created_at) avoids entirely. MySQL behaves differently on Linux (case-sensitive) versus macOS/Windows (case-insensitive), making snake_case the most portable choice. For URL slugs, kebab-case is the clear winner: Google treats hyphens as word separators for indexing, and every major CMS and static site generator (WordPress, Ghost, Hugo, Next.js) generates hyphenated slugs by default.

Where a case converter earns its keep in a real project

It shows up during API migrations, when a backend team switches a database from snake_case columns to a camelCase JSON response and needs to rename dozens of fields consistently. It shows up during codebase refactors, when a team standardizes on one convention and someone has to rename existing variables, functions, and files without introducing typos along the way.

Designers and design-system maintainers use it to translate a token name between a Figma variable (often camelCase or Title Case) and its CSS custom property equivalent (kebab-case). Writers and content editors use the Title Case and Sentence case outputs directly for headings, so it is not only a developer tool.

Naming mistakes a consistent converter helps you avoid

Mixing conventions in the same file, a function called getUserData sitting next to another called get_user_profile, is one of the most common findings in a code review, and it usually happens because someone typed a name by hand instead of converting it consistently. Linters like ESLint's camelcase rule and Python's PEP 8 checkers will flag these inconsistencies, but by then the wrong name is already in a pull request.

Case mistakes also cause real bugs, not just style complaints: a case-sensitive Linux filesystem will fail to find MyComponent.tsx if an import references mycomponent.tsx, even though the same code runs fine on a case-insensitive macOS or Windows machine during development. Converting names consistently at the point of creation, rather than fixing them after a broken build, avoids that entire class of surprise.

A note on non-English text and casing

Case conversion looks like a solved problem until non-English text is involved. Turkish has two distinct letter "i" pairs, so uppercasing a lowercase dotless "i" under Turkish locale rules produces a different character than under English rules, a mismatch that has caused real production bugs in software that assumed English casing everywhere. German's eszett character uppercases to "SS," a transformation that loses information and cannot be cleanly reversed back to the original.

This tool applies standard JavaScript casing behavior, which follows English rules, so it is built for programming identifiers, API fields, and English-language headings rather than for casing arbitrary text in every language. For code and URLs this is exactly the right behavior, since identifiers are virtually always ASCII regardless of the project's primary language.