What Are the Best Practices for Mobile Typography?

A phone screen is about the size of a postcard, and most people read one while walking, queuing, or half-watching something else at the same time. That's the real condition your words have to survive, which is why app typography principles sit much closer to behaviour than to styling. When the sizes, spacing and contrast are right, people take in what you wrote without noticing they're reading. When they're wrong, people skim, guess, and tap the wrong thing.

Type is the first thing anyone experiences in an app, and usually the last thing a team looks at.

We spend a lot of our time on emotional design, and type does more emotional work than almost anything else on a screen. A cold, clinical typeface makes a wellness product feel like a lab report. Tight line spacing makes a calm app feel rushed. Grey-on-grey body copy makes people feel like they're being hidden from, even when nothing is being hidden.

So this piece walks through the whole thing. Which typefaces hold up small, what font sizes for mobile actually work, how to set line height and measure, how to build a scale, how to order information by how much it matters, and how to test it on real hardware. Along the way we'll use work we've done on a baby monitor, a travel booking product, a gifting platform and a genetics app, because the decisions get clearer when there's a real screen behind them.

What Makes Type Hard to Read on a Phone

Reading on a phone is a worse experience than reading on a laptop, and it's worth being honest about why. The line is short, so the eye jumps back to the left margin every six or seven words. The device moves. The light changes. The hand holding it is often the hand doing something else.

Comprehension takes a real hit as a result. Measured with a cloze test, it drops from 39% on desktop to 19% on mobile, according to UX Magazine. That gap isn't a reason to write less. It's a reason to set type so that the words people do read are the ones that matter.

Attention is borrowed, not given

Most phone reading happens in short bursts between other things. Someone opens your app at a bus stop, reads for eleven seconds, locks the screen, comes back four minutes later and has to find their place again. Type that's set tightly, in one undifferentiated grey block, offers nothing to find your place with.

Then there's the physical stuff. Glare on a train window. A cracked screen protector. Reading glasses left at home. Brightness turned down to save battery. All of it eats into legibility before a single design decision has been made, so the design has to start with headroom built in.

Choosing a Typeface That Survives a Small Screen

The best fonts for mobile apps share a short list of qualities. A generous x-height, so lowercase letters stay big at small sizes. Open counters, so the holes in a, e and o don't fill in. Letterforms you can tell apart, which mostly means checking that capital I, lowercase l and the number 1 don't look identical. And numerals that line up in a column, which matters more than people expect once you've got prices or readings on screen.

System fonts do all of this well. San Francisco on iOS and Roboto on Android were drawn for these screens, they're already on the device, and they respond properly to accessibility settings. A custom face can work beautifully, and it has to earn the download size and the extra testing.

Type that works at thumbnail size

We worked on a gifting and wishlist platform where the client was reluctant to spend anything on the App Store listing, because the product was social and group-based and they expected word of mouth to carry it. Our view was that the listing still had to do its job. The icon, the category, the first screenshot caption, all of it is read at thumbnail size by someone deciding in two seconds.

People really need to understand what the product is about from the very first screen, and that's a typographic question as much as a copy one. We'd rather fewer people download and the right ones stay, than a wave of installs from people who open the app and find it isn't for them.

Font Sizes for Mobile: The Numbers That Actually Work

Start body copy at 17px on iOS or 16sp on Android and treat that as your default, not your maximum. Supporting text sits at 15px. Captions, labels and metadata sit at 13px. Below that you're in territory where a lot of people simply stop bothering.

Google's Android documentation puts the default minimum at 12sp, and that number gets misread constantly. It's a floor for the rare label, not a size for anything a person has to read and act on.

Twelve is a floor, not a size, and if the layout needs it, the layout is the problem.

Headings need less size than most teams give them. On a 390px-wide screen, a 28px screen title already fills most of the line. Going to 34px buys you a line break and very little clarity. Weight, space and colour separate things far more cheaply than size does.

One pattern worth stealing from the platforms. Set the size on the smallest common device you support, usually something around 375px wide, and let the larger phones have the breathing room. Designing at 430px and scaling down is how body copy ends up at 14px on the devices that needed it biggest.

Line Height, Measure and Spacing

Line height is where mobile app typography gets fixed or ruined. Body text wants around 1.5 times the font size. W3C accessibility guidance says people should be able to push line height to at least 1.5 times the font size without losing content or breaking the layout, along with paragraph spacing at twice the font size. If your design breaks when text spacing increases, it was too tight to begin with.

Set headings tighter than body text, around 1.2, and small print slightly looser, around 1.45. The eye needs more help finding the next line when the letters are smaller.

Measure, the number of characters on a line, is mostly decided for you by the screen width. Around 35 to 50 characters reads comfortably. The lever you control is horizontal padding, and 16 to 20px each side is usually right.

Spacing between blocks does more than most people credit. On a travel booking product we worked on, we'd folded the platform fee into one total price because a single number looked simpler. It made people anxious about hidden charges. Breaking the fees into separate lines gave them much more confidence they were seeing the real price, and typographically each line then needed enough air around it to read as its own separate fact rather than a wall of figures.

Building a Type Scale and Visual Hierarchy

A scale is just a short list of agreed sizes with jobs attached. Five or six steps is plenty for an app. Any more and the differences stop being readable as differences, and your developers start guessing.

Two weights carry almost everything. Regular for reading, semibold for anything that needs to be found. Light weights look lovely in a design file and fall apart on a bright day outside.

Hierarchy comes from the gaps between steps, so keep them obvious. A 20px heading above 17px body reads as the same thing twice. Push the heading to semibold, give it space above, and the difference lands without any extra size at all. That's also kinder to translation, where German or Finnish strings run a third longer and a big heading suddenly wraps to three lines.

Ordering Information by Importance, Not by Length

Teams tend to lay screens out by how much content each thing has. The paragraph gets the top, the single number gets tucked underneath. People read it the other way round, by what they came for.

We worked on a baby monitor product where we surfaced the really critical information parents needed first, then let them go deeper into the data behind it if they wanted to. The ordering was driven by how critical each piece of information was rather than how complex it was. A parent checking at two in the morning needs one fact in big, high-contrast type. The sleep trends and the history can sit a layer down.

That's progressive disclosure done by criticality, and typography is how you express it. The thing that matters gets size, weight and space. The supporting detail gets a smaller step on the scale and a quieter colour. Everything else goes behind a tap.

A quick way to pressure-test a screen is to squint at it. Whatever you can still read is what you've prioritised. If that isn't the thing the user came for, the scale is being applied to the wrong content, and no amount of copy rewriting will fix it.

Writing Tone Into the Typography

We run a game internally and with clients where we imagine the product as a person sitting in your home, doing whatever the product does. How do they talk? What do they ask first? How do they make you feel reassured? Once you've got that person, you can judge every design decision and every piece of copy against them.

Type is part of that voice. A tight, condensed, all-caps label sounds clipped. Generous spacing and a warm weight sound patient. Headspace does this well in its onboarding, where the illustrated character does the emotional work the copy usually attempts and fails at. It isn't asking you to be calm, it's just being calm at you, and you mirror that.

Type has a voice before anyone reads a word of it, and people hear it either way.

Typography can do the same job. Looser line height and a softer weight slow the reading down, which slows the person down a little too. Dense, clinical settings push them forward and raise the pressure.

So match the setting to the emotional state of the moment. A results screen in a wellness product wants warmth and air. A payment confirmation wants clarity and firmness. Same scale, different emphasis.

Contrast, Colour and Reading in Daylight

Light grey text on white is the most common legibility failure we see, and it's almost always a taste decision that nobody pressure-tested outdoors. W3C guidance sets the minimum at 4.5:1 for normal body text and 3:1 for large text, and that's a floor rather than a target. Comfortable reading usually sits well above it.

The practical test costs nothing. Take the build outside at midday, turn brightness down to about 40%, and read a full screen. Anything you have to lean into has failed, whatever the contrast checker says.

Dark mode needs its own pass

Pure white text on pure black looks sharp in a design file and glows unpleasantly in a dark room. Soften the text to something like a very light grey and lift the background off true black. Then check the ratios again, because those thresholds apply in both themes and a palette that passes in light mode often fails when it's inverted.

Colour also carries meaning in type, so keep that meaning consistent. If red means an error in one place, it can't mean a sale price somewhere else. And never let colour be the only signal, because a muted link in a brand shade is invisible to plenty of people. Pair it with weight or an underline.

Supporting Dynamic Type and Accessibility Settings

Plenty of people have already set their phone's text size larger, and they did it once, years ago, for everything. An app that ignores that setting is telling those users it knows better.

Supporting it properly means designing in relative units and testing at the extremes. Build every key screen at the default size, at the largest standard setting, and at the largest accessibility setting. Three states, checked before build, saves a lot of argument later.

Give text containers room to grow downwards instead of fixing their height. Most dynamic type bugs are a box that can't get taller, not a font that can't get bigger.

Things that break first are predictable. Buttons with text on one line, tab bar labels, cards in a horizontal row, and anything with an icon pinned next to a word. Plan for the label to wrap, or to drop the icon, or for the row to become a stack.

Bold text settings, reduced transparency and increased contrast are worth a pass too. They're a few minutes of checking each, and they're the difference between an app someone can use on a bad day and one they put down. Resizable, scalable text is one of the first accessibility features development teams reach for, and getting it right early is far cheaper than retrofitting it.

When Your Type System Meets Your Brand

We worked on a mobile app in the health and wellness genetics sector where the brand promise and the product experience had come apart completely. The packaging and the online presence were luxurious and aspirational, all about transformation and becoming a better version of yourself. The app the client had already built was cold and clinical, purely functional in its copy and its design.

Think about that journey from the user's side. You see the aspirational marketing, you order a kit, you do the test, you wait, and then you open the app to see your results. It was a very jarring experience, and it broke down entirely at the product touchpoint, which is the one that matters most.

Type was doing a lot of that damage. Dense data labels, tight spacing, a clinical face, numbers presented like a lab printout. None of it said transformation.

The fix wasn't about making it decorative. It was about translating the brand's emotional promise into a scale. More space around the headline result, a warmer weight for the words a person reads first, data pushed down the hierarchy into a place they can go when they want it. The same information, set so it feels like the product they bought.

Typography for Loading, Offline and Error States

These screens get designed last, in a hurry, and they're where people are most stressed. Someone reading an error message is already frustrated, and their capacity for dense text has dropped through the floor.

So set these states more generously than the rest of the app. Bigger body size, looser lines, higher contrast, shorter lines of copy. Say what happened and what to do next, with the action in the strongest weight on the screen.

People forgive a product that breaks, and they don't forgive being left to guess what just happened.

When somebody is struggling, take things away. Anything that requires a lot of input and isn't needed right now can wait. Simplify down to exactly what's needed at this moment, and ask for the rest later when they're in a better state. That's a typographic decision as much as a functional one, because the fewer labels on screen, the bigger the remaining ones can be.

Loading states deserve the same care. A skeleton screen that matches your real type sizes feels like the content is nearly there. One with generic grey bars at the wrong proportions feels like a stall, and people don't come back often after an experience like that.

Testing on Real Devices and Reading the Behaviour Data

A design file at 100% zoom on a 27-inch monitor tells you almost nothing about legibility. Type has to be checked on glass, in hands, in real light.

1. Build the key screens and put them on the cheapest small Android phone you support.
2. Read every screen outdoors, at 40% brightness, standing up.
3. Repeat at the largest accessibility text size.
4. Hand the phone to someone who's never seen the product and watch where they slow down.
5. Check it again in dark mode, at night, in a dark room.

Then let the behaviour data tell you where reading is failing. Most teams only have high-level funnel numbers, which is nowhere near granular enough. What we're actually looking for is time on screen, people going into a screen, coming back out, then going back into it, and scrolling up and down repeatedly through terms or detail. That pattern signals either a lack of comprehension or a lack of trust.

Repeated scrolling over the same block of text is usually a typography problem before it's a copy problem. The words may be fine and the setting is making them hard to hold onto.

Common Mobile Typography Mistakes

The same handful of problems turn up in nearly every app audit we do, and all of them are cheap to fix before build.

• Body text at 14px because the design was drawn on a large phone.
• Line height left at the default 1.2, which suits headings and strangles paragraphs.
• Seven heading sizes, three of which nobody can tell apart.
• Light grey placeholder text that people read as a filled-in field.
• All-caps labels with no extra letter spacing, which slows reading right down.
• Fixed-height buttons that clip their own text at larger accessibility settings.

Check your empty states, your legal copy and your push notification previews. They're written late, set in whatever the default is, and read by everybody.

One more worth calling out. Centred paragraphs look tidy in a mockup and cost real reading speed, because the left edge moves on every line and the eye has to hunt for it. Centre a short headline if you like. Left-align anything longer than two lines.

And watch the temptation to shrink type to avoid a scroll. A screen that fits with nothing readable on it has solved the designer's problem rather than the user's.

Documenting Type for Developers

A type system that only exists in a design file gets reinterpreted the moment it reaches code. The handover is where most of the care leaks out, so write it down properly.

Turning app typography principles into tokens

Give every step on your scale a name tied to its job rather than its size. Body, body-small, title, label. Then define each one fully, with family, size, weight, line height, letter spacing and colour, so there's nothing left to guess. Note the unit too, because sp on Android scales with the user's setting and dp does not, and that single detail decides whether accessibility support works.

Include the rules alongside the values. How many lines a label can wrap to. What happens at the largest text size. Which colours are allowed on which backgrounds. Whether a string truncates or wraps, and where.

The quickest validation step is the one we use on emotional design decisions generally. Put the built screens in front of the client and simply ask how it feels to them, because fundamentally everybody in the room is a user of products like this. That reaction usually surfaces a spacing or weight problem faster than another round of specification ever does.

Conclusion

Good mobile app typography is mostly a set of unglamorous decisions made early and held to. Pick a face that holds up small. Start body copy at 16 or 17px. Give it line height around 1.5. Build a five-step scale, two weights, generous contrast. Order the screen by what matters rather than what's longest. Then test it outside, on a cheap phone, at the biggest text size.

The part people underestimate is how much feeling type carries. On the genetics app we worked on, nothing about the data was wrong. The setting of it was cold, and that was enough to break a journey the brand had spent real money building. On the baby monitor, deciding what got the biggest type was the whole design, because at two in the morning a parent has room for one fact.

So treat your type scale as part of the brand, not a layer applied over it. It's the cheapest emotional lever you have and the one people feel first.

If you're working through a type system for an app and want another pair of eyes on it, let's talk about your mobile typography.

Frequently Asked Questions