Case converter for text and code.

Eleven outputs update as you type: Title Case, sentence case, lowercase, UPPERCASE, camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE, dot.case and a URL slug. dot.case shows up in configuration keys such as app.server.port. Each line of the input is converted separately, so you can paste a list of headings or column names and convert them all at once.

For the identifier cases, the text is first split into words on spaces, punctuation, underscores and hyphens, and on camelCase humps. An acronym run followed by a word is split before the word's capital, so XMLHttpRequest becomes XML, Http, Request, and getHTTPResponseCode becomes get, HTTP, Response, Code. Apostrophes inside words are dropped (don't becomes dont) so they do not create stray words. Letters and digits from any script are kept, and leading or trailing punctuation is ignored, so a heading pasted with quotes or a trailing colon still converts cleanly.

JavaScript and TypeScript use camelCase for variables and functions and PascalCase for classes, types and React components. Python's PEP 8 uses snake_case for functions and variables, PascalCase for classes and CONSTANT_CASE for constants. Go exports names that start with a capital letter (PascalCase) and keeps others camelCase. Rust uses snake_case for functions, PascalCase for types and SCREAMING_SNAKE_CASE for constants. Kotlin and Swift follow the JavaScript split: camelCase for members, PascalCase for types.

Outside code: CSS classes, HTML attributes, file names and URLs are usually kebab-case, database columns snake_case, and environment variables CONSTANT_CASE. JSON APIs are split between camelCase and snake_case; either is fine as long as one API never mixes them, a point our REST API design guide makes too.

Style guides disagree on acronyms. Google's Java and JavaScript guides treat them as ordinary words (XmlHttpRequest, userId), which keeps word boundaries obvious. Microsoft's .NET guidelines keep two-letter acronyms in capitals (IOStream) and write longer ones like words (HtmlParser). Browser APIs mix both, as XMLHttpRequest shows.

This converter follows the treat-as-a-word convention: XMLHttpRequest becomes xmlHttpRequest and XmlHttpRequest. If your codebase keeps acronyms in capitals, adjust those few letters after copying.

All four capitalise the first and last word and the first word after a colon (this converter does the same after a question mark, exclamation mark or dash, so subtitles read correctly), and keep articles (a, an, the) lowercase. They differ on short words. Chicago and MLA lowercase every preposition, however long (with, from, between), plus and, but, for, or and nor. AP and APA capitalise any word of four letters or more, so With and From are capitalised, and lowercase only short conjunctions and prepositions.

Hyphenated compounds capitalise each major part (Self-Driving, Up-to-Date). Words that already contain capitals after the first letter, such as iPhone, NASA or JavaScript, are left as written, and text typed in all capitals is lowercased first so every word is not mistaken for an acronym.

One limit applies to every automatic tool: a word such as up or on can be a preposition (lowercase) or part of a phrasal verb (Set Up Your Account, capitalised). The converter cannot tell which, so read headlines once before publishing.

Sentence case capitalises only the first word and proper nouns. GOV.UK and Google's Material Design guidelines use it for headings, buttons and labels because it is easier to scan and avoids arguments about which words to capitalise. The converter capitalises the start of each sentence and the pronoun I, keeps words like iPhone and NASA as written, and does not treat e.g. or i.e. as the end of a sentence. Proper nouns typed in lowercase cannot be detected, so capitalise those yourself. For product copy, decide once and write it into your style guide for buttons, menus, headings and email subjects; mixed conventions make an interface feel unfinished far more than the choice itself.

Converting a name is the easy part; renaming it across a codebase is where bugs come from. Use your editor's rename refactoring, which understands scope, rather than search and replace, and remember the places a refactor cannot see: JSON payloads, database columns, environment variables, CSS classes referenced from strings and URLs that other people have bookmarked.

When an API changes convention, for example from snake_case to camelCase, translate at the boundary with a serializer setting instead of renaming every field by hand, and keep the old form working through a deprecation period. Most web frameworks and ORMs have a setting for exactly this.

For lists, paste one name per line: line order is kept, so the output can go straight back into a spreadsheet column, an enum or a migration.

The slug is lowercase, uses hyphens between words, turns & into and, and transliterates common Latin letters (é to e, ß to ss, ø to o, æ to ae). Numbers are kept, so a year or version in a title survives into the slug. Google recommends hyphens rather than underscores in URLs because hyphens separate words for search engines; the underscore option is there for systems that need it.

Untick ASCII only to keep letters from other scripts, such as Cyrillic or Devanagari. Browsers display them, but they are percent-encoded when copied, which makes shared links long. Keep slugs short and stable, since changing one later means setting up a redirect. Our technical SEO entry covers URL structure in more depth, and the URL encoder shows the percent-encoded form.