Database columns are snake_case, JavaScript variables are camelCase, React components are PascalCase, CSS classes and URLs are kebab-case, environment variables are CONSTANT_CASE. One identifier crossing the layers of a project needs rewriting at every boundary, and hand-editing introduces typos.
Type once and see fourteen conventions at the same time. Acronym runs like XMLHttpRequest are split at the right word boundaries, and non-Latin text is handled safely on whitespace. Click any result to copy it, or grab all of them at once.
How to use
- Enter your text — Paste anything —
user profile image URL,last_login_at,myCoolVariable. The starting convention does not matter. Multi-line input is treated as one string. - Copy what you need — Click a row to copy that value; a check mark confirms briefly.
- Export the whole set — Copy all puts every conversion on the clipboard as tab-separated
name → valuepairs, which pastes into a spreadsheet or document as a table.
Frequently asked questions
Are acronyms handled correctly?
Yes. XMLHttpRequest splits into XML, Http and Request.
The rule is that a run of capitals followed by a capital-plus-lowercase marks a word boundary. When building camelCase, every word after the first is capitalised except fully uppercase acronyms (ID, URL, API), which keep their form. So user profile image URL becomes userProfileImageURL, matching what you would write by hand.
Does it work with non-Latin scripts?
Words separated by whitespace or punctuation are treated as words regardless of script.
Scripts without letter case — Korean, Japanese, Chinese — effectively just have their separators changed, since camelCase and PascalCase have nothing to capitalise. Most languages technically allow non-ASCII identifiers, but for collaboration and tooling compatibility, keeping code identifiers in Latin script is the safer default.
Title Case leaves some words lowercase.
That follows English title conventions.
Short articles, prepositions and conjunctions — the, of, and, in, to — stay lowercase in the middle of a title, while the first and last words are always capitalised. So the lord of the rings becomes The Lord of the Rings. If you want every word capitalised, use the Capital Each Word result instead.
Concepts worth knowing
Where each convention belongs
camelCase for variables and functions in JavaScript, Java and C#. PascalCase for classes, types and React components. snake_case for Python identifiers and SQL columns. kebab-case for CSS classes, HTML attributes and URL paths. CONSTANT_CASE for environment variables and constants.
The point is predictability, not aesthetics. Seeing UserService tells you it is a class and MAX_RETRY tells you it is a constant, and that speeds up reading. Where a team convention exists, it wins.
Converting at the API boundary
A Python backend emitting created_at to a front end that expects createdAt is an extremely common situation. There are three sane answers.
Convert during serialisation on the backend (Pydantic's alias_generator, Jackson's naming strategy). Convert once in the front end's API layer. Or agree to use one convention everywhere and live with it. The worst option is converting ad hoc in scattered places, which guarantees both spellings end up in circulation.
URL slugs and kebab-case
Using hyphens in URL paths is also a search recommendation: Google treats hyphens as word separators and warns that underscores can join words together.
Many servers also treat paths as case-sensitive, so lowercase is safer. That is how /tools/sql-to-typescript became the de facto standard shape. Non-Latin URLs work but get percent-encoded into something long and unreadable when shared, so keeping slugs in Latin script while titles stay localised is the usual compromise.