Text case conventions: which one to use, and where each one breaks

Eight conversions, and each one exists for a reason

Case conversion looks like a cosmetic operation and is not. Each convention encodes a different set of rules about what is significant, and using the wrong one produces text that is technically transformed and genuinely wrong.

Title case: the rules depend on which guide you follow

Title case is the convention people argue about, because there is no single rule. The style guides disagree on which words stay lowercase and on how to handle hyphenated compounds, and a converter has to pick one.

The rule most implementations use, and the one this converter applies, is the widespread convention: capitalise the first and last word and all significant words, and keep minor words lowercase when they appear in the middle.

• Minor words kept lowercase mid-title: a, an, the, and, but, or, nor, for, on, at, to, of, in, with.
• Capitalised regardless: the first word, the last word, and every word that is not on that list.
• Hyphenated compounds are capitalised on both parts, so State-of-the-Art and not State-Of-The-Art.

Two consequences follow. First, a title that ends on a minor word capitalises it, because the last word is always capitalised. Second, if your style guide differs — Chicago and AP genuinely differ on hyphenated compounds — you will need to adjust the output by hand rather than trusting any converter.

The caps-lock problem, and how a converter should handle it

Paste THE QUICK BROWN FOX into a title-case function and there are two defensible behaviours. Treat every word as an initialism and leave it alone, which returns the shouting unchanged. Or recognise that the input is entirely uppercase and is therefore most likely caps lock, and normalise it.

This converter takes the second path. An input that is entirely uppercase is treated as a case error to repair rather than a deliberate set of capitalised words, so THE QUICK BROWN FOX becomes The Quick Brown Fox.

The tell is that the rule applies only when the entire string is uppercase. THE API REFERENCE has mixed case at the word level and is treated as deliberate, so the acronym survives. A single all-caps word in an otherwise normal string is never touched.

Sentence case cannot know what a proper noun is

Sentence case lowercases everything except the first word — and that is a rule a machine cannot apply correctly, because deciding whether a word needs a capital requires knowing what it is.

paris in the spring will not become Paris in the spring, because the function has no way to know that Paris is a place. Neither will it preserve a product name, a person's name, or a brand's own capitalisation.

Sentence case is a normaliser, not an editor. Use it to flatten text you are about to review, and fix proper nouns yourself afterwards — a tool that guessed at them would be worse, because it would sometimes be confidently wrong.

Identifiers: the case you choose is a syntax, not a preference

In code, case is part of the grammar of the language rather than a style choice, and using the wrong one is a bug rather than an inconsistency.

• camelCase for variables and functions: userIdField.
• PascalCase for types, classes and React components: UserIdField.
• snake_case for database columns and Python names: http_server_config.
• url-slug for anything appearing in a URL: http-server-config.

Two limitations are worth knowing before you trust the output. Splitting a camelCase identifier into words requires recognising where the boundaries are, and the algorithm handles HTTPServerConfig as http_server_config correctly — but the URL slug path does not split those boundaries, so the same input becomes httpserverconfig as a slug. If you need a slug from a camelCase identifier, convert to snake_case or kebab first, then slugify.

The second limitation is acronyms. user ID field becomes userIdField, with the D lowercased — because the function sees a word ending in a capital and treats it as an ordinary word boundary. No case converter can know that ID is an initialism unless it holds a list of them, and most do not. Rename it by hand.

URL slugs, and why accents must be transliterated

A slug is the readable part of a URL, and it has the tightest constraints of any convention here: lowercase letters, digits and hyphens, with nothing else safe.

The failure modes are ordered by how badly they break. Deleting accented characters rather than transliterating them turns Café into caf, which is a broken word rather than an accented one, and turning a name in a non-Latin script into an empty string is worse still. The correct behaviour is to decompose the character and strip the combining marks, so Café becomes cafe and Straße becomes strasse.

Punctuation and symbols are dropped rather than encoded, because a slug containing % would need escaping and a slug that needs escaping has stopped being readable. Digits are kept, which is why a percentage in a title survives as a number rather than vanishing.

Why you cannot convert back

Case conversion discards information permanently. userIdField and user_id_field and user-id-field all reduce to the same words, so converting to snake_case and back to camelCase will not restore a name that used different word boundaries originally.

This is why a converter is a one-way tool rather than a normaliser you can apply freely. Once the original capitalisation is gone it cannot be recovered, and the only safe approach to text you might need again is to keep the original and convert a copy.

Convert with the rules visible

The Case Converter offers all eight conventions, handles accents by transliteration rather than deletion, and repairs an all-caps paste rather than leaving it shouting — so the output matches the convention you selected instead of approximating it.