camelCase, snake_case, kebab-case: Which Case Goes Where

Most text case choices are conventions, but a few are written down by the people who maintain the language, the operating system or the search engine. Where each one goes:

• Python: snake_case for functions and variables, PascalCase for classes, CONSTANT_CASE for constants.
• JavaScript and TypeScript: camelCase for functions and variables, PascalCase for classes and React components.
• Environment variables: CONSTANT_CASE.
• URL slugs: lowercase kebab-case.
• CSS: kebab-case. The language itself does it (background-color, font-size), and class names usually follow.
• Headlines: sentence case in AP style, title case in Chicago style, and the two disagree about small words.

One phrase in every text case

We ran a recipe title with two accented words through all 12 options of our Case Converter. Accents are where a lot of converters break, so it is a fairer test than "hello world".

The slug, creme-brulee-for-beginners, is the one you would actually paste into a CMS. (Until this update our converter produced "cr-me-br-l-e" here; it now keeps accented letters as plain ones.)

Alternating and inverse case are for memes and Caps Lock accidents; dot.case shows up in config keys and Java package names such as com.example.app.

Case rules in code

Python writes its rules down. PEP 8, the official style guide, says "Function names should be lowercase, with words separated by underscores as necessary to improve readability", that class names "use the CapWords convention" (what most people call PascalCase), and that constants are "written in all capital letters with underscores separating words".

JavaScript is less formal, but the language sets the example: document.getElementById, Array.prototype.forEach, and constructors like Map and XMLHttpRequest. Go against that and every call to the standard library looks out of place next to yours.

Trouble starts where two languages meet. A Python API returns snake_case JSON, and the React app reading it wants camelCase:

// From the API (Python, snake_case)
const response = { "user_id": 42, "created_at": "2026-10-14" };

// In the frontend (JavaScript, camelCase)
const { userId, createdAt } = toCamel(response);

Convert once, at the boundary, in one function. Mix user_id and userId through a codebase and eventually some line reads the one that isn't there and gets undefined. SQL has no official rule, but snake_case table and column names are the common choice, partly because many databases fold unquoted names to one case anyway.

Environment variables have an actual standard behind them. POSIX says the variables used by its standard utilities consist solely of uppercase letters, digits and underscores, and it reserves names with lowercase letters for applications. So DATABASE_URL follows the system's own style. Lowercase names are technically the safer namespace, but almost nobody uses them, and we wouldn't start.

URL slugs: lowercase kebab-case

Google's URL structure guidelines (checked 2026-10-14) recommend hyphens instead of underscores to separate words, and say that Google's URL handling is case sensitive. To Google, /Blog/Creme-Brulee and /blog/creme-brulee are two different URLs, so pick lowercase and stick to it.

Accents are allowed in URLs, but the same guidelines say characters outside ASCII should be percent-encoded, so "gemüse" travels as gem%C3%BCse. Many slug generators, ours included, drop the accent instead (é becomes e), which avoids the encoding. Text in other scripts (Cyrillic, Arabic, Chinese) is kept as letters, because there is no plain-letter version to fall back to.

Headline case: AP vs Chicago

AP headlines use sentence case: as the University of Houston-Downtown's AP headline guide puts it, "only the first word and proper nouns are capitalized." Chicago headline style capitalizes the main words but keeps articles (a, an, the), coordinating conjunctions such as and, but and or, short prepositions, and the to in an infinitive lowercase.

"Short" changed in 2024. Earlier editions of the Chicago Manual of Style lowercased prepositions regardless of length; the 18th edition capitalizes prepositions longer than four letters, according to its own Q&A. So "without" and "between" now get a capital, while "for", "in" and "to" still don't.

Our Title Case button capitalizes every word. That makes it a fast first pass for Chicago style: run it, then lowercase the articles, the short prepositions and the to in "how to". For AP headlines, use Sentence case instead and put the capitals back on proper nouns.

Where the converter still needs a hand

• Acronyms in sentence case. "The API is down" becomes "The api is down", because the converter can't tell an acronym from a shouted word. Fix acronyms and names by hand.
• Acronyms in camelCase input. XMLHttpRequest splits into "xmlhttp" and "request", since the converter only breaks where a lowercase letter meets a capital. If the result matters, add a space first: "XML Http Request".
• Apostrophes in code cases. "don't stop" becomes dont_stop. That is usually what you want in an identifier, but check names like O'Brien.

Everything runs in your browser, so you can paste a whole spreadsheet column of headings into the Case Converter without it leaving your machine. If your titles also have a length limit, the guide to word count and character limits lists the ones Google, YouTube and X actually enforce.