← All Guides🛠️ Developer

Text Case Conversion: camelCase, snake_case, kebab-case, and More

4 min read · Updated September 2026

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

NameExampleUsed For
camelCasemyVariableNameJavaScript variables, functions, object keys
PascalCaseMyClassNameClasses, React components, TypeScript types
snake_casemy_variable_namePython variables/functions, Ruby, database columns
SCREAMING_SNAKEMY_CONSTANTConstants, environment variables
kebab-casemy-component-nameCSS classes, URLs, file names, HTML attributes
dot.caseconfig.property.nameConfig 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: XMLParserxml_parser or x_m_l_parser? Most style guides prefer xml_parser
  • Numbers: utf8Encodingutf_8_encoding or utf8_encoding? Context-dependent
  • Consecutive caps: HTTPSCertificatehttps_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

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

Why did the fish get bad grades?

Free core, forever

Keep the Free Edition Free

No signups, no data sold. The core of every tool is free forever — the optional Pro plan adds batch processing, unlimited downloads, white-label exports and an ad-free experience.

Support me on Ko-fi— keep tools free

100% of proceeds go towards hosting & building more free tools.