Naming conventions, and the words your converter is splitting wrong
Every case format is the same two decisions: where the word boundaries are, and what to put between the words. Getting the second right is trivial. Getting the first right on text that is not plain English is where most converters quietly fail.
The word-splitting rule
This tool finds boundaries in three ways, in order:
- at any character that is not a letter, a digit or a combining mark — spaces, hyphens, underscores, dots, punctuation;
- between a lowercase letter or digit and an uppercase letter, so
fooBarbecomesfoo+Bar; - between a run of capitals and a capital followed by lowercase, so
HTTPServerbecomesHTTP+Serverrather thanHTTPS+erver.
Worked example. la città HTTPServer fooBar naïve_test splits into la, città, HTTP, Server, foo, Bar, naïve, test — eight words. A converter written with [a-zA-Z]+ returns eleven, because it cuts città and naïve in half at the accented letter. The identifiers it produces then look almost right, which is worse than looking wrong.
What each format is for
- camelCase — variables, functions and object properties in JavaScript, Java, C#, Swift, Kotlin.
- PascalCase (UpperCamelCase) — classes, React components, types, .NET methods.
- snake_case — Python and Ruby identifiers, SQL column names, protocol buffer fields.
- CONSTANT_CASE — environment variables, compile-time constants,
.envkeys. - kebab-case — CSS class names, HTML attributes, npm package names, URL paths. It is required wherever the language treats
_as valid in an identifier but the format is case-insensitive. - dot.case — configuration keys, i18n message ids, Java package names.
- Title Case — headings, in the English convention where minor words such as a, the, of and in stay lowercase unless they open the phrase.
Slugs on alphabets that are not Latin
The URL slug here is produced by the same function that generates this site's own addresses, and it makes one distinction most slug libraries do not.
De-accenting is applied to Latin script only. In Latin, é is e with an ornament and dropping the mark is harmless. In Devanagari, Bengali, Thai, Arabic, Hebrew and Japanese, the marks classed by Unicode as combining are vowels, matras, dakuten and hamza — dropping them does not simplify the word, it destroys it. A library that runs a blanket NFD + strip over any script turns Thai and Hindi into consonant soup, which is exactly how a page ends up with an unreadable, non-searchable URL.
So La città di São Paulo becomes la-citta-di-sao-paulo, while text in Japanese, Korean, Thai or Arabic keeps its own characters. Modern browsers and search engines handle non-ASCII URLs correctly; a mangled transliteration is the bigger risk.
FAQ - Frequently Asked Questions
userName is camelCase, UserName is PascalCase — also called UpperCamelCase. The convention in most languages is camelCase for variables and functions, PascalCase for classes, components and types, which is why both are shown separately here rather than as one "camel" option.ß is its own character with no decomposition into a base letter plus a mark, so Unicode normalisation leaves it untouched — the same is true of ø, ł and đ. If you need ASCII output for those, the correct transformation is a language-specific transliteration (ß → ss in German), not accent stripping, and the two should not be conflated.