Changing the case of a block of text sounds like the least interesting thing a text tool can do, and it is the operation most likely to quietly damage your content. Title case mangles acronyms. Sentence case destroys proper nouns. Lowercasing a German word can change how many letters it has. None of these are edge cases you will avoid by being careful, because the tool cannot see which words are names.
Uppercase maps every letter to its capital form. Lowercase maps every letter to its small form. Both are mechanical and both are reversible only if you know what the original was.
Title case capitalises the first letter of each word and lowercases the rest. Sentence case capitalises the first letter after each sentence boundary and lowercases the rest.
Alternating case flips between lower and upper by position, starting lowercase, which is a meme format rather than a typographic one.
The programming cases (camelCase, PascalCase, snake_case, kebab-case, CONSTANT_CASE) remove spaces and use capitalisation or separators to mark word boundaries instead.
All of these are available as a control on the generator pages, and the fancy text generator applies the case before the style transform so the two combine sensibly.
This is a mechanical detail with a visible consequence.
The styled alphabets are lookup tables keyed on a to z and A to Z. A mathematical bold capital A and a mathematical bold small a are separate entries in the table, and neither is connected to the other by any case relationship the software understands.
So uppercasing text that has already been styled does nothing at all. The characters are not letters as far as a case function is concerned; they are symbols that happen to look like letters.
Running the case conversion on your plain input first, and only then looking up each character in the style table, produces what you expected. That is the order the tools here use, and it is why the case control sits next to the style list rather than being a separate step.
Title case lowercases everything that is not the first letter of a word. That is the definition, and it is what breaks acronyms.
Run it over a line containing NASA, HTML or PDF and you get Nasa, Html and Pdf. There is no way for the conversion to know those are initialisms rather than ordinary words, because nothing in the text distinguishes them from a name.
The same applies to brand names with internal capitals, product names, and any word whose capitalisation carries meaning. A conversion cannot preserve what it cannot detect.
So title case is safe on prose you wrote and unsafe on anything containing names, technical terms or product references. Read the output rather than trusting it, and fix the handful of words that came back wrong.
Sentence case lowercases everything except the character after a sentence boundary, which means every proper noun in the text loses its capital.
Names of people, cities, companies, days, months, languages and nationalities all come back lowercase. On a paragraph with several, the output needs more correction than the original needed.
Sentence boundary detection is its own source of error. A period is used for abbreviations as well as for ends of sentences, so text containing Dr. or e.g. or a decimal number will have capitals inserted mid-sentence.
Sentence case is genuinely useful for one job: fixing text that arrived in all capitals, where you have nothing to lose because the original capitalisation is already gone. For anything else, the correction cost usually exceeds the benefit.
Case conversion is not always one letter for one letter.
The German sharp s, ß, has traditionally uppercased to SS, two letters where there was one. A word containing it gets longer when uppercased and does not come back when you lowercase it, because SS lowercases to ss rather than to ß.
Turkish has a separate problem: the dotted and dotless i are distinct letters, and the correct uppercase of i depends on which language the text is in. A conversion that does not know the language will get one of the two wrong.
These are not obscure. If your text contains any non-English language, verify the output rather than assuming the operation was reversible. Length changes in particular will surprise you in a field with a character limit.
Writing a word in capitals to emphasise it has costs that bold does not.
All-capital text is slower to read, because word shapes carry a large part of recognition and capitals flatten every word to the same rectangle. That effect gets worse the longer the run.
Screen readers vary in how they treat capitals. Some announce a word normally. Some spell out a short all-capital run, on the reasonable assumption that it is an acronym. A capitalised sentence can therefore arrive as a string of letter names.
In a field that has real formatting, bold is better in every respect. In a field that does not, small caps gives you a similar texture change with less of the legibility cost, and the bold text page has the unicode version if the field takes it.
camelCase, PascalCase, snake_case, kebab-case and CONSTANT_CASE all remove the spaces and encode word boundaries in the capitalisation or a separator character.
They exist because identifiers in code cannot contain spaces. Outside code they have one common use: turning a title into a URL slug, which is what kebab-case is for.
They are lossy in a specific way. Converting to snake_case and back does not restore your original punctuation, because everything that was not a letter or a digit became an underscore and there is no record of what it used to be.
So convert in one direction and keep the original. If you need a slug, the conversion is fine. If you need round trips, it is not.
Case conversion assumes your text is already tidy, and pasted text usually is not.
Double spaces between sentences confuse sentence boundary detection. Line breaks in the middle of sentences, which is what a PDF paste usually produces, make every fragment look like a new sentence. Trailing whitespace produces empty words.
Running a cleanup first gives a much better result. Remove line breaks flattens a broken paste back into paragraphs, whitespace remover collapses runs of spaces, and text trimmer strips the leading and trailing padding.
That order is worth making a habit of: clean, then convert, then check. Converting dirty text produces errors that look like conversion bugs and are actually input problems.
Fixing text that arrived in all capitals: sentence case, then restore the proper nouns by hand.
Headings in a document: use the document's own heading styles, which handle capitalisation as a display property and leave the text alone.
A URL slug: kebab-case, one direction only.
Emphasis in a field with no formatting: not capitals. Use small caps or a unicode bold style.
A name or a title containing acronyms: convert nothing automatically. The correction cost is higher than doing it by hand.
And whatever you convert, read the output. Every one of these operations is mechanical, none of them understands your text, and the failures are all of the same kind: something that needed a capital lost one, or something that did not need one got it.
None of these operations is reversible, and that is worth saying before you run one over a document you care about.
Uppercasing destroys the record of which letters were capital. Lowercasing destroys it in the other direction. Title case and sentence case both destroy it selectively, which is worse, because the damage is scattered through the text rather than uniform and you cannot spot it by looking at the shape of the paragraph.
There is no undo that recovers the original from the output, because the information is genuinely gone. A tool cannot know that the word you now see as apple was Apple.
So the habit worth building is trivial: keep the original. Convert into a second window, a second file, or a second column, and compare. If the conversion went wrong you still have the input, and if it went right you have lost nothing.
That applies doubly to the programming cases, which remove spaces and punctuation as well, and to any conversion run on text containing names, product references or acronyms.
Title case lowercases everything after the first letter of each word, and nothing in the text tells it that NASA is an initialism rather than an ordinary word.
Some letters uppercase to more than one character. The German sharp s traditionally becomes SS, so a word containing it grows by one character and does not come back when lowercased.
No. Styled characters are symbols rather than letters as far as a case function is concerned. Apply the case to your plain text first, then the style, which is the order the tools here use.