camelCase vs. snake_case vs. kebab-case: When to Use Each

Every programming language needs a way to name things — variables, functions, files, URLs — and since most languages don't allow spaces inside a name, four different conventions emerged to mark word boundaries instead. Knowing which one belongs where is a small thing that immediately signals (or undermines) familiarity with a codebase's conventions.

Convert between them in your browser (free, instant)

The Case Converter on keptlocal converts text into all eight common cases at once — including all four naming conventions — as you type.

The four naming conventions

• camelCase — firstWordLowercase, each subsequent word capitalized, no separators. The dominant convention for variables and function names in JavaScript, TypeScript, Java, and C#.
• PascalCase — EveryWordCapitalized, no separators. Used for class names across most object-oriented languages, and for component names in frameworks like React and Vue.
• snake_case — every_word_lowercase, joined with underscores. The standard for Python (per its official style guide, PEP 8), Ruby, and most SQL database column and table names.
• kebab-case — every-word-lowercase, joined with hyphens. The standard for URL slugs, CSS class names, and HTML custom element and attribute names.

Why the split happened

Early languages and file systems restricted what characters an identifier could contain — no spaces, and often limited punctuation. That constraint forced every language community to pick a convention for marking where one word ends and the next begins, and once a community settles on one, consistency within that ecosystem becomes more valuable than any inherent merit of the convention itself. Python's official style guide explicitly recommends snake_case; JavaScript's dominant style (used by most style guides and linters) is camelCase for variables and PascalCase for classes/components. Neither is "more correct" in the abstract — they're just what each community standardized on, decades apart, for reasons that made sense in each context.

URLs and CSS ended up on kebab-case partly for a subtler reason: some older systems (including early search engine indexing) treated an underscore as joining two words into one token rather than separating them, which could hurt SEO or break word-based matching. Hyphens didn't have that ambiguity, so kebab-case became the safe default for anything user- or search-engine-facing — URL slugs, CSS classes, HTML attributes.

Where mixing conventions causes real bugs

The most common place this bites in practice: a backend written in Python (snake_case) exposing a JSON API consumed by a JavaScript frontend (camelCase). If the API returns user_name and the frontend code expects userName, that's a silent bug — no error, just a value that's always undefined. Some frameworks handle this conversion automatically at the API boundary; where they don't, it's a manual translation step worth being deliberate about, and exactly the kind of thing a case converter speeds up while double-checking the field names match.

Privacy: what happens to your text

Every conversion runs locally in your browser using standard JavaScript string methods — nothing is transmitted or stored.

Convert text case now with keptlocal's free Case Converter — no upload, no signup.