| Case | Example | Difficulty |
|---|---|---|
| UPPERCASE | THE ANNUAL REPORT IS LATE | Mostly mechanical |
| lowercase | the annual report is late | Mechanical, but destroys information |
| Sentence case | The annual report is late | Needs sentence detection |
| Title Case | The Annual Report Is Late | Needs a style guide and a word list |
Upper and lower look trivial and are, until non-English text arrives — see the locale section below. The other two involve judgement, and any tool that claims to do them perfectly is overselling.
Lowercasing is lossy in a way that cannot be undone. Once Paris becomes paris, nothing in the text records that it was a proper noun. Sentence case applied to a document typed with caps lock on will fix the shouting and simultaneously flatten every name, brand and initialism in it. That is the single most common disappointment with this kind of conversion, and it is worth knowing before you convert several thousand words rather than after.
There is no single correct title case. Every guide capitalises the first and last word and all major words, and they differ on the small ones:
| Guide | Rule for prepositions | Result |
|---|---|---|
| Chicago | Lowercase regardless of length | Look into the Future |
| Associated Press | Capitalise if four letters or more | Look Into the Future |
| APA | Capitalise if four letters or more | Look Into the Future |
So a converter has to pick a side. Beyond that, the cases where automatic title casing reliably fails:
Sentence case has its own trap: sentence boundaries are not full stops. Abbreviations such as Dr. and e.g., decimal numbers such as 3.5, and version strings such as 2.1.4 all produce false boundaries, so a naive splitter capitalises mid-sentence.
| Name | Form | Typical use |
|---|---|---|
| camelCase | parseUserInput | Variables in Java, JavaScript |
| PascalCase | ParseUserInput | Types and classes |
| snake_case | parse_user_input | Python, SQL columns |
| SCREAMING_SNAKE | PARSE_USER_INPUT | Constants, environment variables |
| kebab-case | parse-user-input | URLs, CSS, command flags |
Converting between them looks like a one-line job and is not, because splitting camel case requires deciding where a run of capitals ends. Take parseHTTPResponse. Splitting on every capital gives parse_h_t_t_p_response, which is wrong. Treating a run of capitals as one word gives parse_httpresponse, which is also wrong. The usual rule — a run of capitals is one word, except that its last letter belongs to the following word if a lowercase letter follows — gives parse_http_response, which is right here.
But that rule cannot always be right, because the information is genuinely absent. HTTPSConnection could be HTTPS plus Connection or HTTP plus SConnection, and no algorithm can tell without a dictionary. Round-tripping identifiers through case conversions is therefore not guaranteed to return the original, which matters if you are generating code or migrating a schema.
Case is not a per-character property in every language, and this produces real bugs.
Turkish and Azerbaijani. These languages have two distinct letter i: dotless ı and dotted i, with separate capitals I and İ. In a Turkish locale, uppercasing i correctly yields İ, and lowercasing I correctly yields ı. A locale-aware case conversion applied to English text inside a Turkish locale therefore turns file into FİLE, and a lowercase comparison of FILE returns fıle, which matches nothing. This has broken configuration parsing, command handling and authentication checks in shipped software many times. The lesson is narrow and useful: never use a locale-sensitive case conversion for comparing machine-readable strings such as keys, tags, protocol tokens or file extensions.
German. The letter ß has historically uppercased to SS, so straße becomes STRASSE and lowercasing that gives strasse — a round trip that silently changes the word. A capital form ẞ exists and was admitted as an official alternative in 2017, but most software still expands to SS.
Greek. Lowercase sigma has two forms: ς at the end of a word and σ elsewhere. Lowercasing Greek capitals correctly requires knowing where words end, so it is context-sensitive rather than character-by-character.
A related point: some characters change length when case is changed. One ß becomes two letters. Any code that assumes an uppercased string has the same length as its input, or that character positions line up before and after, is wrong for these inputs.
If your goal is to compare two strings ignoring case, lowercasing both is the intuitive approach and the wrong one. Unicode defines case folding for exactly this purpose: it is locale-independent, it folds ß to ss so the German pair compares equal, and it normalises the two sigmas.
This matters most for usernames and identifiers, where case-insensitive matching decides whether two accounts are the same account. Some characters fold together that do not look alike — the Kelvin sign folds to a plain k, and several mathematical and compatibility letters fold to ordinary Latin ones. Normalising registration input with folding plus Unicode normalisation, and rejecting mixed scripts, is the standard defence against lookalike account collisions.
If you only want text to look uppercase on a web page, a stylesheet text transform is the better tool: the underlying content is unchanged, so copying the text yields the original wording, translators see real sentences, and you can change your mind without re-editing content. Converting the characters themselves is for when the stored value must change.
Two accessibility notes on all capitals. Screen readers may read a run of capitals letter by letter when it looks like an initialism, so a whole heading in capitals can be announced as individual letters. And research on continuous reading, going back to Miles Tinker legibility studies, has consistently found all-capital text slower to read than mixed case — roughly ten percent — because the distinct outline shape of words is lost. Capitals are fine for short labels and poor for sentences.
For search: capitalisation is not a ranking factor, and search engines fold case when matching queries. Titles are shown as written, so a heading in shouting capitals affects click-through rather than position.
Whichever your publication uses. If you have no house style, pick one and stay consistent — inconsistency across headings is more visible to a reader than either convention.
Almost certainly a locale-sensitive conversion applied to data. Use a locale-independent conversion for machine-readable strings and a locale-aware one only for text a person will read in that language.
Not reliably. The capitals carried the information and it is gone. Keep the original until you have checked the result.
No. The conversion runs entirely in your browser. Nothing is uploaded, logged or stored, which is the reason this is safe to use on unpublished or confidential copy.
Every tool comes with a written guide, and every category is one click away.