Sentence Case vs Title Case in UI: What the Major Design Systems Actually Do

Microsoft's style guide, the GOV.UK style guide and Material 3 all specify sentence case for interface text, in those words, without hedging. Apple's buttons are title case on every one of its platforms. Four of the most-copied style guides in software, and they do not agree.

That disagreement is why the question keeps coming back in code review. It is rarely a debate about which convention reads better. It is a recurring tax, paid in review comments, on a decision nobody wrote down.

What each convention specifies

Sentence case capitalises the first word and any proper nouns, and leaves everything else lowercase. "Save and continue." "Delete account." "Export your data as CSV." One rule, one answer.

Title case capitalises the significant words in a phrase and leaves the minor ones alone. "Save and Continue." "Delete Account." The trouble is in the word significant, which each style guide draws differently.

There is a third option that still turns up in older interfaces: all caps. Material Design 2 shipped uppercase button labels as its default, and Material 3 moved off them. Microsoft's guidance is blunter — don't use all uppercase for emphasis, and don't use all lowercase as a design choice either.

Title case has more than one rulebook

Microsoft's writing style guide spells out its version in seven rules. Always capitalise the first and last word. Don't capitalise a, an or the unless it opens the phrase. Don't capitalise prepositions of four or fewer letters — on, to, in, up, of, for — unless they land first or last. Don't capitalise and, but, or, nor, yet or so in the middle. Capitalise everything else, including is and other forms of be.

That produces "How to Personalize Windows" but also "To Personalize Windows", because to moved to the front. It produces "Enterprise Agility Is Not an Oxymoron", because Is counts as a verb and gets a capital that most people would not give it by instinct.

Chicago and AP draw the line at different places — AP capitalises prepositions of four letters and up, Chicago goes by function, not length — so three writers applying "title case" from memory will produce three different strings. Sentence case has no equivalent ambiguity. There is one capital at the front, and proper nouns keep theirs.

That asymmetry is the practical argument, and it is separate from any claim about beauty or readability. Sentence case can be checked mechanically. Title case cannot: whether Is deserves a capital is a judgement call, which is why it keeps arriving as a review comment.

Where the big design systems landed

Three of the four largest public style guides now specify sentence case, and they say so without hedging.

Microsoft states that its style uses sentence-style capitalization, and applies it to "the first word of a sentence, heading, title, UI label (such as the name of a button or checkbox), or standalone phrase". Title-style capitalisation is reserved for product names, book and article titles, and job titles.

GOV.UK is the most absolute of the three: "Always use sentence case, even in page titles and service names." Its exceptions are proper nouns, named schemes such as Right to Buy, and act and bill titles.

Material 3 applies sentence case to titles, headings, labels, menu items, navigation, app bars and buttons, and explicitly directs designers away from title case.

Apple is the exception, and it is a significant one. Apple's Human Interface Guidelines allow either convention for interface labels, and buttons across Apple's platforms use title-style capitalisation. A macOS or iOS app that adopts sentence case for its buttons will read as slightly foreign next to the system controls around it.

The platform usually decides

That split is more useful than a ranking. If you are building inside someone else's operating system, the convention is settled for you, and matching it is worth more than any in-house preference. An iOS app whose action sheet says "Save and continue" while the share sheet beneath it says "Copy Link" has introduced an inconsistency the user can see.

Web products have no such constraint, which is why the web has drifted toward sentence case: no platform vendor is enforcing the alternative, and sentence case is the cheaper rule to run. The workable answer for a cross-platform team is a documented split: sentence case in the web app and the marketing site, platform-native capitalisation in the mobile clients.

What the readability evidence supports

Design decks overclaim here.

The finding that holds up is about all caps, not about title case. Miles Tinker's legibility research, collected in Legibility of Print (1963), found that extended passages set in all capitals were read meaningfully slower than the same text in mixed case. The usual explanation is that uppercase text flattens the word shape and removes ascenders and descenders that support recognition. That result was measured on continuous prose. A four-word button is not continuous prose, so the effect on a single label is much smaller, but the direction is consistent, and it is the main reason all-caps labels have fallen out of favour.

Between sentence case and title case, there is no comparable body of evidence. Both preserve mixed-case word shapes; both are read fluently by anyone who reads at all. Screen readers announce them identically, since capitalisation is not exposed to assistive technology in either form. Claims that sentence case is measurably faster to read in short UI strings are repeating a preference, not a study.

So the honest case for sentence case rests on enforceability, tone, and translation. It has one rule instead of seven. It reads closer to speech, which suits products that have decided on a conversational tone of voice. And it survives localisation better, because most languages do not have a title case convention at all — German capitalises all nouns, French and Spanish capitalise almost nothing in headings, and a title-cased English source string gives translators nothing to carry over.

Writing the rule into the design system

The version of this rule that fails is the one that says "we use sentence case" and stops. It fails because the arguments that reach a pull request are always about the edge, and the edge is where a written rule has to do its work.

Start with the surfaces it governs: buttons, headings, page titles, menu items, form labels, empty states, error messages, table column headers, toast notifications. Anywhere a string appears without a full stop is somewhere the question can be asked.

The exceptions matter more, because they are where the fights happen, and they need examples. Product and feature names keep their capitals — "Export to Airtable", not "Export to airtable". Acronyms stay uppercase. Anything a legal or brand team has already fixed stays fixed. Skip this list and sentence case gets applied to a product name once, in public, and the exception becomes its own recurring debate. Write the list before you change a single string, and add to it in the open when a new case turns up.

Say what happens on Apple platforms, so the mobile team is not treated as non-compliant for following the system convention.

Then put the rule somewhere other than code review. A lint rule over the string catalogue, or a check in the component library, catches capitalisation before a human has to spend a comment on it. A documented convention with nothing enforcing it decays as new people join and copy whatever is nearest.

Capitalisation belongs in the same document as your tone words and your error-message patterns.

Frequently asked questions

What is sentence case?

Capitalising only the first word of a phrase, plus any proper nouns, and leaving everything else lowercase. "Save and continue" and "Delete account" are sentence case. It is the convention used by Microsoft, GOV.UK and Material 3 across their interface text.

What is the difference between title case and sentence case?

Sentence case capitalises the first word and proper nouns. Title case capitalises the significant words in a phrase — nouns, verbs, adjectives, adverbs — while leaving articles, coordinating conjunctions and short prepositions lowercase unless they fall first or last. Sentence case has one rule; title case has a rulebook, and the rulebooks disagree.

Should buttons use sentence case or title case?

On the web, sentence case, unless your brand has already committed to the alternative. On Apple platforms, title case, because that is what the system controls around your button use. The consistency the user notices is the consistency across the whole screen, not across your product's own web and mobile surfaces.

Which is better for accessibility?

Neither has an advantage. Screen readers do not announce capitalisation, so sentence case and title case are read out identically. The choice that does affect accessibility is all caps, which slows reading of longer passages and can cause some screen readers to spell out shorter strings letter by letter as if they were acronyms. Where you do need emphasis, handle it in the markup and the accessible name.

Does sentence case help with translation?

Yes, in the sense that it creates fewer problems. Title case is largely an English convention. German capitalises every noun regardless, and French, Spanish and most other European languages use sentence case for headings by default, so a title-cased English string carries no information a translator can act on and often has to be undone.

When should I still use title case?

For proper nouns and named things: product names, feature names, book and article titles, job titles, and formal document titles. Microsoft's own guidance keeps title case for exactly this set while using sentence case everywhere else, which is a reasonable model to copy.

Is sentence case less formal than title case?

It reads closer to natural speech. If your brand is deliberately formal, the lever is word choice and sentence length — "Submit your application" and "Submit Your Application" carry nearly the same register, and the first is easier to keep consistent.

How do I switch an existing product to sentence case?

Change the design system defaults and the string catalogue in one pass. A half-converted product looks like a bug. Inventory the strings first, agree the exception list before editing anything, and add the lint rule in the same change so the old convention cannot come back through new work.

Take it further

A product with no written rule shows you the disagreement directly, in the gap between its buttons and its modals. The UX Clarity framework treats that kind of surface inconsistency as evidence about the system that produced it, and a Full UX Audit looks for the same fracture lines in error messages, empty states and form labels. The rest of the decisions that make interface copy consistent are collected in UX writing.

Sources: Microsoft Writing Style Guide — Capitalization · GOV.UK style guide — A to Z · Material 3 — UX writing best practices · Apple Human Interface Guidelines — Buttons · Tinker, M. A. (1963), Legibility of Print, Iowa State University Press.

Not sure whether your interface copy follows a rule or a habit? Apply for a Full UX Audit →