Text Case Conversion Guide

Every programming language has its naming conventions. Using the right case isn't just style — it's how other developers instantly understand what a name represents (variable, class, constant, or CSS class).

The 6 Common Cases

Name	Example	Used For
camelCase	`myVariableName`	JavaScript variables, functions, object keys
PascalCase	`MyClassName`	Classes, React components, TypeScript types
snake_case	`my_variable_name`	Python variables/functions, Ruby, database columns
SCREAMING_SNAKE	`MY_CONSTANT`	Constants, environment variables
kebab-case	`my-component-name`	CSS classes, URLs, file names, HTML attributes
dot.case	`config.property.name`	Config files, namespaced properties

Convert Between Cases Instantly

Use our Case Converter to transform text between all 6 naming conventions at once — perfect for API mapping and cross-language work.

Language-by-Language Conventions

JavaScript / TypeScript

Variables and functions: camelCase
Classes and React components: PascalCase
Constants: SCREAMING_SNAKE
CSS classes: kebab-case
File names: kebab-case or PascalCase (for components)
Private properties: #camelCase (JS private field) or _camelCase (convention)

Python

Variables and functions: snake_case
Classes: PascalCase
Constants: SCREAMING_SNAKE
Private: _leading_underscore
File names: snake_case.py

Java / C#

Variables: camelCase
Classes and interfaces: PascalCase
Constants: SCREAMING_SNAKE
Methods: camelCase
Properties (C#): PascalCase

Ruby

Variables and methods: snake_case
Classes and modules: PascalCase
Constants: SCREAMING_SNAKE

Go

Exported names: PascalCase
Unexported names: camelCase (no underscores)
Acronyms: userID not userId, httpServer not httpserver

Common Conversion Pitfalls

Acronyms: XMLParser → xml_parser or x_m_l_parser? Most style guides prefer xml_parser
Numbers: utf8Encoding → utf_8_encoding or utf8_encoding? Context-dependent
Consecutive caps: HTTPSCertificate → https_certificate (not h_t_t_p_s_certificate)
Database columns: Always snake_case regardless of your app language

API Design: Bridging Conventions

When your backend uses snake_case (Python/Ruby) but your frontend uses camelCase (JavaScript), you need a consistent conversion strategy:

Option A: API returns snake_case, frontend converts to camelCase on receive and back on send
Option B: API returns camelCase everywhere (common in Node.js backends)
Option C: Use a serialization library that handles it automatically (like camelize in JS or marshmallow in Python)

The Bottom Line

Follow your language's conventions — consistency matters more than personal preference
camelCase for JS/TS variables, PascalCase for classes, snake_case for Python
SCREAMING_SNAKE is universally understood as "this is a constant"
kebab-case for CSS, URLs, and file names
When bridging APIs across conventions, pick one strategy and stick with it