Project Tips for When Your UI Design Includes ALL CAPS Text

From design and implementation to translation concerns, here are some tips for your project when your UI design includes ALL CAPS text elements.

Whether you’re following a standard design language like Material Design, or have developed your own custom look and feel, your new website or app design might include UI elements that use uppercase text (“ALL CAPS”).

Subheadings, button labels, tiny links, etc. are common candidates for ALL CAPS treatment.

Below are some tips for you to apply to your project when handling ALL CAPS text in parts of your UI design. (These tips would also apply if your website styling used forced lowercase in some places, e e cummings style.)

These tips might just save you time, money, and hassle!

Note: By my reckoning, these tips are in rough order from more obvious to less obvious. Your mileage may vary.

1. Make sure ALL CAPS isn’t used in places where there will be a lot of text to read.

As it is commonly believed, all-caps text is somewhat harder to read than regular sentence-case (“mixed-case”) text.

I’ll spare you the controversy, conflicting cases, and misapprehensions on this matter. Suffice it to say, readers tend to read ALL CAPS text a bit more slowly, and tend to dislike reading long passages of ALL CAPS text.

None of this means you can’t use ALL CAPS in your UI designs. But it does mean you should use it sparingly, and in places where there won’t be chunks of text for you users to read.

Body text (article text, product descriptions, etc.) should obviously not be displayed in all uppercase. However, tab labels, button labels, and the like are supposed to be concise, so ALL CAPS is certainly an option for those elements.

Further, elements that tend to be as long as medium-length sentences or phrases—such as certain heading types—may warrant an ALL CAPS treatment in your design. For example, ALL CAPS might help you establish visual contrast for one heading type versus other headings and body text, without having to otherwise exaggerate size, weight, or color differences. (This is not a recommendation, it’s just one way to go. It’s up to you what works for your overall design and brand aesthetic.)

But again, the thing to watch out for is long blocks of text. Let’s say, for example, your H3 headings are styled in ALL CAPS. But if some pages of your website might use H3s for potentially long lines of text (e.g., the title + subtitle of non-fiction books), you may want to change the styling of your H3s, at least in those contexts.

2a. Use CSS or string functions to convert text to ALL CAPS for display

You don’t want to store your display text strings (see below) in ALL CAPS and just display them. Instead, you’ll want to use CSS or string transform functions to convert text to ALL CAPS for display only.

CSS Example

h3 {
text-transform: uppercase;


  • Future flexibility – You’ll be able to change your styling later with just a few changes to your CSS or presentation code, without having to hunt down and rewrite a bunch of text labels.
  • Reusability – There may be some instances of text labels you wish to reuse in different places throughout your site or app. In different contexts, the styling of the same text might be different.

2b. Store text strings with normal (appropriate) capitalization

Whether you’re keeping your UI text strings in a database, in text resource files, in your source code (I won’t tell anyone!), or a mix of these, you’ll want to store those text strings with appropriate capitalization, not in ALL CAPS.

Ask yourself: if this piece of text wasn’t going to be styled in ALL CAPS, what kind of capitalization would it have? However you answered, that’s how that text should be stored.

Most text strings should be stored using either:

  • Sentence-style capitalization – e.g., “Tools, resources, and help files”
  • OR Book-title capitalization – e.g., “Tools, Resources, and Help Files”

…even if it will wind up being displayed as all uppercase (e.g., “TOOLS, RESOURCES, AND HELP FILES”) in the user interface.

3. Tell your devs and writers what’s up!

Make sure to inform your team that text strings are not to be stored in ALL CAPS.

Depending on the project, UI text may originate from visual specs, prototypes, word docs, etc. UI text might initially be typed up by developers or by copywriters. Later on, UI text additions and modifications may come from change requests, bug reports, etc.—and perhaps handled by entirely different team members. You likely won’t be in the position to review every change.

Everyone is busy and focused on getting their own work done. Writers might not know what implementation is possible; developers might not think about how best to handle text strings from your perspective. And neither is likely to automatically have your best-practice plans in mind when they are doing their work. It helps to let them know.

Further, your style guide should include which UI elements should use sentence capitalization and which should use book-title capitalization.

4. Double-check your text resources before you have them translated!

Allowing ALL CAPS text to go out to translators could be an expensive mistake.

Different languages have different capitalization rules. If you discover you’re storing ALL CAPS source text after it’s already been translated, you won’t be able to properly fix those instances yourself without sending them back to translators.

That’s time and money you didn’t anticipate spending!

Note: You might be able to check this yourself without having to pore over all your text resource files or poke through your CMS database. If you can temporarily turn off uppercase styling, you can run through your site or app and look out for labels that still appear in ALL CAPS.

For example, you might be able to use your browser’s inspection tools to change text-transform: uppercase; to text-transform: none; for all buttons on the page, and then inspect the result.

5. Don’t trick your users to into entering data in ALL CAPS

One last weird consideration.

If your application supports user-entered content, make sure not to use ALL CAPS styling on the same kind of data your users will be entering into a form.

For example, if you display message titles in uppercase in your UI, then users might naturally follow suit and enter their message titles in ALL CAPS to match. That is not desirable.

Learn about how BetaTesting can help your company launch better products with our beta testing platform and huge community of global testers.

%d bloggers like this: