--- title: How Do I Choose the Right Font Size for My Mobile App? description: A practical guide to choosing the right app font size for mobile, covering type scales, platform specs, dynamic sizing and common mistakes. image: https://weareaffective.com/hubfs/learning-centre-images/how-do-i-choose-the-right-font-size-for-my-mobile-app.webp --- [Skip to content](https://weareaffective.com/learning-centre/how-do-i-choose-the-right-font-size-for-my-mobile-app#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # How Do I Choose the Right Font Size for My Mobile App? Table of Contents Take the app you're working on, step outside into bright sun, hold the phone at arm's length and try to read the body copy. That test settles more [app font size arguments than any spec](https://weareaffective.com/app-ui-design) document. Type that looks clean on a large monitor in a dim studio often falls apart on a phone held at an angle, in glare, by someone who is walking and half paying attention. > Type size is the first thing a person feels about your product, well before they read a word of it. Font size for mobile still gets treated as a styling decision made late, once the layout is signed off and someone needs to fill in the text styles. It's one of the earliest decisions about how hard a person has to work to use your product, and how they feel while they're doing it. Size sets the order people read things in. Size tells them what you think matters. Size decides whether an older user stays or quietly gives up. So the useful question is rarely "what number should body text be". It's closer to "who is reading this, in what state, holding the phone how far away, and what happens if they misread it". The rest of this piece works through units, minimums, scales, what the platforms actually ask for, and the parts that get missed, which are mostly about the person rather than the screen. ## What Counts as a Font Size: Points, Pixels, SP and DP A number on its own tells you very little. "16" means four different things depending on where you write it, and a fair few handover arguments come from a designer and a developer using the same digit for different units. On iOS, type is measured in points. A point is a logical unit, so 16pt comes out at roughly the same physical size on an old phone and a current one, even though the newer screen packs far more hardware pixels into the same space. Android splits this in two. Density-independent pixels (dp) hold still, and scale-independent pixels (sp) do the same job while also growing when someone raises the text size in their system settings. #### Why the unit changes your app font size Raw pixels are the one to keep away from text. Set type in px and it shrinks as screen density rises, and it ignores the user's own settings completely. On Android, text in dp rather than sp has the same effect, and it's one of the [quieter accessibility bugs we find](https://weareaffective.com/learning-centre/what-are-the-most-common-mistakes-startups-make-when-building-their-first-app) in audits because everything looks correct until someone turns their font scale up. | Unit | Platform | Grows with user text setting | Use it for | | --- | --- | --- | --- | | Points (pt) | iOS | Yes, through Dynamic Type | All text | | sp | Android | Yes | All text | | dp | Android | No | Spacing, icons, touch targets | | px | Hardware | No | Nothing in the interface layer | Put the unit in the name of every text style in your design file. "Body / 16sp" survives handover in a way that "Body" doesn't. ## The Minimum Legible Size and Where It Comes From Android's documentation sets the default minimum font size at 12sp, according to [Google, Android developer documentation](https://developer.android.com/develop/ui/views/text-and-emoji/autosizing-textview). That's a platform specification rather than a finding about human eyesight, and reading it as "12 is allowed, so 12 is fine" is how products end up with prices, disclaimers and error messages that nobody over forty can read without bringing the phone closer to their face. Legibility comes out of three things stacked on top of each other. There's the eyesight of the person reading, which varies far more across your user base than most teams assume. There's the typeface, because two fonts set at the same nominal size can read very differently depending on x-height, stroke weight and how open the letterforms are. Then there are the conditions, which we come back to later, because the same size behaves differently in a gym and on a sofa. A minimum is a floor. We treat the platform minimum as the size reserved for the least consequential text in a product, a timestamp or a line of small print that exists for completeness. Anything a person reads in order to make a decision sits comfortably above it, and anything carrying money, health or safety sits further above again. ## UX/UI design built around *real* psychology We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Building a Type Scale Instead of Picking Sizes Choosing sizes screen by screen gives you a product with eleven type sizes and no logic connecting them. Everything sits a little too close to everything else, so nothing reads as more or less relevant, and every new screen restarts the argument. A scale fixes the set in advance and turns each later decision into a choice from a short list. > A type scale is a decision made once so it doesn't get remade badly on every screen. Build it outwards from the body size, in this order. 1. Set the body size first, then read a full screen of real copy at it, on a real phone. 2. Set line height from that body size and check it holds for a long paragraph. 3. Step upwards for headings in jumps big enough to read as deliberate. 4. Add one or two sizes below body, and write down what each one is for. 5. Stop at five or six sizes in total. Line height does as much work as size. W3C guidance says people should be able to raise line height to at least 1.5 times the font size without losing content or function, alongside related rules for paragraph, letter and word spacing ([W3C Web Accessibility Initiative, WCAG 2 for Mobile](https://www.w3.org/TR/wcag2mobile-22/)). We set line height near that from the start, because text that's technically large enough and jammed together still reads as hard work. ## What Apple and Google Actually Specify Both platforms give you named roles rather than a list of numbers to memorise, and using the names is what gets you scaling behaviour for free. Apple's text styles run from Large Title down through Title, Headline, Body, Callout, Subhead, Footnote and Caption. Build with those and Dynamic Type handles resizing, weight adjustment and line spacing without you writing a line of logic. Google's Material type scale works the same way, with Display, Headline, Title, Body and Label roles, each available in large, medium and small. The system fonts on both platforms are drawn with screen reading in mind, which matters more than it sounds when text gets small. #### Where the scaling quietly breaks Custom typefaces, web views and cross-platform frameworks are where this falls over. A brand font dropped into Apple's Body style keeps the size and loses the metrics it was drawn around, so the same number reads smaller. Content loaded in a web view often ignores the system setting entirely, which means a user with large text set sees half your app respond and half of it stay put. That inconsistency reads as broken, and it's worth checking before launch rather than after a one-star review explains it to you. ## Screen Size, Density and Viewing Distance Density is the part people worry about and shouldn't. Points, sp and dp already handle it, so 16pt on a high-density screen comes out at roughly the same physical size as 16pt on a cheaper panel. The pixels get finer and the letters get sharper. The text doesn't shrink. Screen size matters in a different way. A larger phone gives you more room, and the common mistake is spending all of it on more content rather than some of it on bigger text and more breathing space. Small phones and older devices are still very much in use, particularly outside the handful of markets product teams tend to design for, and a layout that only holds together at the top of the range isn't finished. Viewing distance is the one nobody designs for and everybody experiences. People hold phones at arm's length when they're tired, when their eyes are strained, when they've taken their glasses off, and when the phone is propped against something while their hands are busy. A size that works at 30cm starts to struggle at 50cm. The way to know is to hold it there. Mirror your design file to a phone and leave it on your desk all day. Checking type at phone distance becomes automatic once the device is sitting there. ## Dynamic Type and User-Controlled Scaling Dynamic Type on iOS and font scale on Android let people set text size for themselves, across every app they use. Someone with reduced vision has already made that choice before they ever open your product, and it's a choice they made for a reason. Honouring it is the single highest-value typography decision in a mobile app. It also appears to be the accessibility work teams are most willing to do. In a survey of mobile app developers published on [arXiv](https://arxiv.org/html/2601.14131v1), resizable text and scalable fonts was the most commonly selected accessibility feature, at 11.67% of all feature selections. That's self-reported, so read it as what developers say they prioritise rather than what shipped products do, and the gap between those two is usually where the problems live. #### What breaks at large app font size settings Fixed-height containers clip. Buttons with text that no longer fits truncate the verb, so "Confirm payment" becomes "Confirm pay...". Tab bar labels collapse into ellipses. Two-column layouts that made sense at default sizes stop making sense at all. The fixes are mostly structural, so [let containers grow, let text wrap](https://weareaffective.com/learning-centre/what-emotional-pacing-means-and-why-it-decides-whether-users-finish-a-multi-step) onto more lines, switch tight horizontal layouts to vertical at the larger settings, and resist capping the scale. Capping is a decision that someone else's eyesight is their problem. ## Sizing for the Reading Conditions Your App Is Used In Most type decisions get made in near-ideal conditions, which is the opposite of how the product gets used. Someone reading a recipe has the phone flat on a worktop at half a metre with flour on their hands. Someone checking a set in a fitness app has the phone on the floor and about two seconds of attention. Someone looking up a hotel address is doing it on a station platform in the rain with one hand full. Movement, glare, distance and divided attention all push in the same direction, which is towards fewer words at a larger size with more space around them. > Text that works sitting still in good light is a baseline, not a result, because almost nobody uses a phone that way. This cuts the other way too. A long-form reading experience in a home and interiors app, used in the evening on the sofa, can take smaller, more considered type with generous line height, because the reader has settled and wants density. A [supplements reorder screen can't](https://weareaffective.com/learning-centre/how-to-diagnose-which-stage-of-the-emotional-arc-your-reorder-flow-is-losing-cus). The [conditions tell you which one you're designing](https://weareaffective.com/learning-centre/why-charity-donation-flows-should-be-designed-around-doubt-not-around-efficiency), so write them down before you set a single size, and be specific about where the person is and what else their hands are doing. ## Sizing by Information Criticality, Not Just Hierarchy Hierarchy is usually built from how a product is structured. Headings get big because they're headings, body gets medium because it's body, metadata gets small because it's metadata. That logic is about the content model, and the user has no interest in your content model. We worked on a baby monitor product where we surfaced the really critical information parents needed first, and then let them go further into the data behind it if they wanted to. The layering wasn't based on how complicated each piece of information was. It was based on how critical it was at that moment. Size followed the same rule, so the thing a parent needed at a glance got the space, and the supporting detail sat underneath for anyone who chose to look. Applying that to type means asking what happens when each piece of text is misread. A section label misread costs nothing. A dosage, an allergen, a check-out time or a total at checkout misread costs a lot. Those sizes should be set by consequence. Go through a key screen and mark every piece of text with the cost of misreading it. Any mismatch between that and your type sizes is your list of fixes. ## When the User Is Anxious: Size, Density and Reassurance With high stress and high anxiety, what you're trying to do is bring that level down, and [simplification is the main tool](https://weareaffective.com/learning-centre/thought-leader-series-turn-empty-states-in-your-mobile-app-design-into-bold-bran). Size and density are a large part of that. Tight, small, dense text reads as pressure before anyone has processed a single word of it, and someone arriving worried has less capacity to spend on decoding a cramped screen. We worked on a healthcare and health insurance product for African markets where users often arrived in an emotionally heightened state. We went for a dark UI with green undertones, because green carries associations with calm, safety and medical support, while steering clear of a clinical look. The language throughout was simplified and very deliberate, with the medical jargon stripped out, so that people felt looked after rather than tested. There's a limit to how far simplification goes. On a genetics wellness product we worked on, we found that if the language got too simple people stopped trusting it and assumed there was no real science behind it, and if it got too technical they switched off and didn't proceed. The balance we landed on was plain language carrying people through, with the scientific depth available to explore. Type size works the same way, so supporting detail shrunk to the legal minimum reads as something being kept from you. ## Font Size for Interactive Elements and Error Messaging Button labels and touch targets are two separate measurements, and teams conflate them constantly. Apple's Human Interface Guidelines recommend a minimum touch target of 44x44 points for interactive elements ([Apple, Human Interface Guidelines](https://weareaffective.com/learning-centre/what-spacing-rules-create-better-mobile-app-layouts)), and hitting that tells you nothing about whether the label inside is readable. A 44pt tall button with 11pt text passes the target rule and still fails the person using it. Error messages are where small type does the most damage. The pattern is familiar, so the field highlights in red and the explanation appears beneath it at caption size, in the exact moment the user is frustrated and least able to read carefully. Error text should sit at body size, in plain words, close to the thing that went wrong. #### Pre-framing beats a better error message On the genetics wellness app, one of the most effective things we did was pre-frame the states that users might read as errors. Rather than letting somebody see an unexpected result and decide the report was wrong, we rewrote the copy to say things like "this is to be expected" and "everyone is different" before they got there. The error state never formed in their head. Copy set at a size people actually read is what makes that possible. ## Testing Type on Real Devices with Real Users Type reviewed on a laptop in a meeting is type nobody has read. Get it onto a phone, in the hand of someone who isn't on your team, in roughly the place and state they'd normally use it. There's a second problem with test conditions, which we see most clearly around money. In a usability session, people assess a checkout flow functionally and rationally, because they aren't actually parting with their own cash. Live analytics tell a different story, where something that looked fine in testing erodes trust just enough for someone to bail out of the flow. > In a test, people read your screen carefully. In real life, they glance at it and decide. So [watch behaviour rather than asking for opinions](https://weareaffective.com/learning-centre/from-prototype-to-perfect-how-user-testing-transforms-apps). People rarely say text is too small, because they read it as a fault of their eyes rather than your design. What they do instead is pull the phone closer, tilt it, squint, or scroll past a block of copy without their eyes moving across it. Run the same session with the system text size turned up to its largest setting, and again outdoors. ## Common Font Size Mistakes and How to Spot Them Most sizing problems fall into a handful of patterns, and they're easy to find once you know the shape of them. - Too many sizes, with 14 and 15 both in use for no stated reason. - Steps between sizes so small that hierarchy reads as inconsistency. - Body text set below the platform floor to make a dense screen fit. - Prices, totals and dates set smaller than the labels describing them. - Error and helper text at caption size, where frustration is highest. - Hard-coded sizes that ignore the user's own text setting. The last one hides best, because the product looks correct on every device in the studio. Turn the system text size up to maximum, walk through your three main flows and the breakages appear in about four minutes. There's a judgement call underneath all of these. Shrinking type to fit more on a screen is almost always a content decision wearing a design decision's clothes, and the honest fix is removing something. Doing fewer things properly beats cramming more in at lower quality, and users are quick to decide an app isn't worth coming back to after a poor experience. ## Conclusion Choosing an app font size is less about landing on a magic number and more about building a small, deliberate set of sizes and then defending them. Pick the body size on a real phone, build the scale outwards, set line height properly, use the platform text styles so user scaling works, and let the consequence of misreading something drive how big it is. The parts people skip are the human ones. Where is this person, what state are they in, how far is the phone from their face, and what does this screen cost them if they get it wrong. On the baby monitor product we sized by how critical the information was rather than how complicated it was. On the healthcare product for African markets we simplified language and softened the whole interface because people were arriving worried. Both decisions came from understanding the person first and the grid second. If your type feels slightly off and you can't work out why, it's usually the scale rather than any single size, and that's a fixable afternoon's work rather than a redesign. [Let's talk about your app's typography](https://weareaffective.com/get-started) if you'd like another pair of eyes on it. ## Frequently Asked Questions What font size should I use for body text in a mobile app? Most mobile apps land on 16pt or 16sp for body copy, because it reads comfortably at arm's length in real conditions rather than just on a studio monitor. Treat that as a starting point and test it outdoors, in glare, on an older device before you commit to anything smaller. What is the difference between pt, sp, dp and px? Points are the iOS unit for type, while Android uses scale-independent pixels (sp) for text and density-independent pixels (dp) for spacing, icons and touch targets. Raw pixels (px) should never be used for text, as they shrink as screen density rises and ignore the user's own settings entirely. Why does using dp instead of sp for text cause problems? Text set in dp will not grow when someone raises the font scale in their system settings, so the app looks perfectly correct until an accessibility setting is changed. It is one of the quieter bugs found in audits, because nothing appears broken during normal testing. Is 12sp an acceptable minimum font size? Android's documentation sets 12sp as the default minimum, but that is a platform specification rather than a statement about human eyesight. Reading it as permission to use 12sp for prices, disclaimers or error messages tends to leave anyone over forty struggling to read them. How can I test whether my type is actually legible? Take the live build outside into bright sunlight, hold the phone at arm's length and try to read the body copy while standing. That single test resolves more arguments than any specification document, because it reflects how people genuinely use a phone. Should font size be decided early or late in the design process? It belongs early, even though it is usually treated as a styling job done once the layout is signed off. Size determines reading order, signals what you think matters and decides whether some users persevere or quietly give up. How do I stop unit confusion during handover to developers? Write the unit into the name of every text style in your design file, so "Body / 16sp" rather than just "Body". A surprising number of handover disputes come from designers and developers reading the same number as different units. What question should I be asking instead of "what number should body text be"? Ask who is reading this, in what state, holding the phone how far away, and what happens if they misread it. Framing it around the person rather than the screen gives you a far more useful answer than a single fixed number ever will. ## Related Articles [![What Are the Best Practices for Mobile Typography?](https://weareaffective.com/hubfs/learning-centre-images/what-are-the-best-practices-for-mobile-typography.webp)](https://weareaffective.com/learning-centre/what-are-the-best-practices-for-mobile-typography) ### [What Are the Best Practices for Mobile Typography?](https://weareaffective.com/learning-centre/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... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![How Do I Make the Best App Screenshots for the Store](https://weareaffective.com/hubfs/learning-centre-images/how-do-i-make-the-best-app-screenshots-for-the-store.webp)](https://weareaffective.com/learning-centre/how-do-i-make-the-best-app-screenshots-for-the-store) ### [How Do I Make the Best App Screenshots for the Store](https://weareaffective.com/learning-centre/how-do-i-make-the-best-app-screenshots-for-the-store) Open the App Store, search for a sleep app, and watch what your own thumb does. You read the name,... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![Which Languages Should I Prioritise for My Apps International Launch?](https://weareaffective.com/hubfs/learning-centre-images/which-languages-should-i-prioritise-for-my-apps-international-launch.webp)](https://weareaffective.com/learning-centre/which-languages-should-i-prioritise-for-my-apps-international-launch) ### [Which Languages Should I Prioritise for My Apps International Launch?](https://weareaffective.com/learning-centre/which-languages-should-i-prioritise-for-my-apps-international-launch) Most app teams approach international launches by asking how many languages they can afford. The... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.