Skip to content
InsideUX Design
Design 17 min read

Touch Targets: How Big Buttons on a Phone Need to Be

44, 48 or 24? Where the well-known minimum sizes for touch targets come from, why the hit area matters more than the visible size and what is really behind the thumb zone.

Picture a city’s parking app. Someone is standing next to their car with a shopping bag in one hand and their phone in the other. You set the parking time with two small icons, “minus” and “plus,” each 20 pixels wide and right next to each other. If you want 90 minutes, you tap “plus” six times and hit “minus” twice by accident. In the top right corner sits a tiny “X” that is supposed to close an info dialog and only responds on the third try. And the bar at the bottom crams six icons together so tightly that your thumb keeps hitting the wrong one.

None of these problems has anything to do with colors, copy or flow. They are about something very physical: the areas people are supposed to hit are too small or too close together. These areas are called touch targets, or tap targets.

This article explains how big touch targets should be, where the well-known numbers 44, 48 and 24 come from, why the visible size is not the same as the area that responds to touch and what is really behind the much-cited “thumb zone.” The parking app serves as a running example throughout. It is made up, but typical.

Why size matters: Fitts’s law

That large, nearby targets are easier to hit than small, distant ones sounds obvious. But psychologist Paul Fitts measured this relationship precisely in 1954. His participants used a stylus to tap back and forth between two metal plates whose width and distance he varied. From this, he concluded that the time needed to hit a target depends on the ratio between distance and target width. Today this is known as Fitts’s law.

Fitts described the difficulty of a movement with an index that grows logarithmically with the ratio of distance to target width: ID = log2(2D / W). D stands for distance and W for the width of the target. In practice: when a target gets smaller, the difficulty goes up, and people either need longer or miss more often.

Touchscreens add a problem that doesn’t exist with a mouse. A finger is much larger than a mouse pointer and covers exactly the spot it is trying to hit. The W3C puts it this way in its guidance on target size: touch is an input mechanism with coarse precision, and a finger generally obstructs the user’s view.

In 2006, Pekka Parhi, Amy Karlson and Benjamin Bederson studied how large a target needs to be for the thumb. Their participants operated a device with one hand, using only their thumb. The result: for single taps, like a button or checkbox, they found 9.2 millimeters to be sufficient, and for sequences of taps, as in text entry, 9.6 millimeters. According to the authors, these sizes work without hurting performance or preference. The numbers are around 20 years old and come from smaller touchscreen devices, but they give a useful order of magnitude: just under a centimeter.

The numbers at a glance

Look for minimum sizes and you’ll run into three sources: Apple, Google and the Web Content Accessibility Guidelines (WCAG). They give different values because they answer different questions.

Apple: 44 × 44 points

Apple’s Human Interface Guidelines (HIG) are clear: as a general rule, a button needs a hit region of at least 44 × 44 points, or 60 × 60 points in visionOS. A point (pt) is a device-independent unit that maps to several physical pixels depending on the screen.

One detail in the accessibility chapter is worth noting. For iOS and iPadOS, Apple lists 44 × 44 points as the default control size and 28 × 28 points as the minimum. So 44 is what Apple recommends, and 28 is the floor for cases where space gets tight.

Google: 48 × 48 dp

For Android and Material Design, Google recommends touch targets of at least 48 × 48 dp, separated by at least 8 dp of space. A dp (density-independent pixel) is also a device-independent unit. According to Google, a 48 × 48 dp target works out to a physical size of about 9 millimeters, regardless of screen size. That puts Google very close to the values Parhi and his team found.

WCAG 2.2: 24 × 24 CSS pixels as the minimum

WCAG 2.2 has been a W3C Recommendation since October 2023. It contains two success criteria on target size:

  • 2.5.8 Target Size (Minimum), Level AA: targets for pointer input are at least 24 × 24 CSS pixels. There are exceptions, which we’ll get to shortly.
  • 2.5.5 Target Size (Enhanced), Level AAA: targets are at least 44 × 44 CSS pixels, also with exceptions.

So 24 pixels is not a design goal but a floor. The W3C itself says the criterion defines a minimum size and, where that can’t be met, a minimum spacing. For important links and controls, it suggests aiming for the stricter criterion 2.5.5.

In the EU, this is more than theory. The European Accessibility Act, which Germany implements through the BFSG (Barrierefreiheitsstärkungsgesetz, the German Accessibility Act), relies on the European standard EN 301 549 for technical requirements. Its previous version, 3.2.1, references WCAG 2.1, which did not yet include 2.5.8. Version 4.1.1 was published on 2 September 2026 and builds on WCAG 2.2 Level AA. It becomes legally relevant once it is cited in the Official Journal of the EU, which is expected by the end of 2026. For websites and apps covered by the law, 2.5.8 then becomes the benchmark. You can read more about the law in the article BFSG in Practice.

What the units mean

Points, dp and CSS pixels are all device-independent units. They are meant to keep a button from shrinking to nothing on a high-resolution display. On a mobile website with a properly set viewport, Google’s web.dev guide says 48 CSS pixels correspond to around 9 millimeters. So you can roughly compare the values.

It isn’t exact, though. The physical size depends on the device, and UX researcher Steven Hoober considers any standard specified in pixels rather than physical dimensions fundamentally unreliable. He also writes that Apple’s and Google’s target sizes seem based more on platform convenience than on human factors. That doesn’t make them wrong. It just means the numbers are sensible rules of thumb, not laws of nature.

For practical purposes, a simple framing is enough:

  • 24 × 24: the floor under WCAG 2.2 AA. Below this, things get hard for many people, and once the new EN 301 549 applies, legally risky as well.
  • 44 × 44 or 48 × 48: what Apple and Google recommend for touch and what WCAG 2.5.5 requires at Level AAA. This is the right target for controls on a phone.

Visible size is not the same as hit area

One misconception is stubborn: a 48 dp target doesn’t have to look like a 48 dp button. WCAG defines a target as the region of the display that will accept a pointer action. What counts is the area that responds, not the area you see.

Google illustrates this with an icon: a 24 × 24 dp icon with padding around it can form a 48 × 48 dp touch target. Material components such as Checkbox and Switch add this padding automatically in Jetpack Compose. For custom elements, Android offers TouchDelegate, which lets a parent element handle touches for a smaller child. Apple puts it very directly for image buttons on macOS: a button’s edges define its clickable area even when they aren’t visible.

The web works the same way. An icon stays visually 24 pixels wide while the surrounding button gets enough padding or a minimum size. Forms get help from HTML itself: correctly associate a label with a checkbox and the whole text becomes tappable. MDN explicitly describes this larger hit area as an advantage for touch users.

There are two limits. First, invisible hit areas must not overlap. WCAG doesn’t count overlapping areas toward the target size, and Google notes that some closely spaced elements can’t be enlarged without their touch areas overlapping. Second, a target still has to be recognizable as a target. A huge invisible area around a barely visible icon doesn’t help much if nobody knows they can tap there.

In the parking app, this means:

  • Before: “Minus” and “plus” as 20-pixel icons with no padding, right next to each other. The “X” in the info dialog: 16 pixels, tucked into the corner.
  • After: Both stepper buttons are 48 × 48 dp and clearly styled as buttons, with the value between them. The “X” stays visually small but has a 48 × 48 dp hit area and moves a little away from the edge. On top of that, there are quick picks for 30, 60 and 120 minutes.

Spacing: the underrated part

Size alone isn’t enough. The Nielsen Norman Group puts it in a simple order: targets first need to be big enough and then spaced well enough. Apple agrees and calls spacing between controls as important as their size. As a rule of thumb, Apple suggests about 12 points of padding around elements with a bezel and about 24 points around the visible edges of elements without one. Google recommends at least 8 dp between touch targets.

WCAG even turns spacing into a way to meet criterion 2.5.8. If a target is smaller than 24 × 24 CSS pixels, imagine a circle with a 24-pixel diameter centered on it. If that circle doesn’t intersect another target or the circle of another undersized target, the criterion is met. So a 16-pixel icon with enough room around it can pass. The W3C still recommends meeting the minimum size regardless of spacing.

Spacing matters most where a mistap is costly. Steven Hoober advises placing dangerous or unrelated actions far away from other items so accidental taps have fewer consequences. “End parking session” does not belong right next to “Extend parking time.”

The thumb zone: what Steven Hoober actually found

Few touch topics get simplified as often as the “thumb zone”: a graphic with green, yellow and red areas showing where the thumb reaches comfortably. It goes back to Steven Hoober’s work, and it is worth looking closely at what he found and what he didn’t.

In 2013, Hoober published an observational study in the magazine UXmatters. Over two months, he collected 1,333 observations of people using their phones in public: on the street, at bus stops, in cafés and on trains. In 780 of them, people were touching the screen. Of those, 49% held the phone in one hand, 36% cradled it in one hand and tapped with the other, and 15% used both hands.

Even then, Hoober stressed the limitations: people change their grip very often, sometimes every few seconds. There was no demographic data, devices weren’t recorded, tablets were excluded, and observations usually covered only the first few seconds of use. He described the thumb reach areas as rough approximations that vary by person, grip and device.

In 2017, Hoober followed up, drawing on further observations, a review of research literature and, among other things, a study with more than 120 million recorded touch events. His key points:

  • People hold their phones in many different ways and shift their grip a lot, often without noticing.
  • He calls the widespread thumb-sweep charts “well-known, but incorrect.” How far the thumb reaches depends on the grip, and people adjust their grip.
  • People prefer to look at and touch the center of the screen.
  • Accuracy depends on position: in the center, targets of around 7 millimeters are enough, while corners need about 12 millimeters. According to Hoober, these values cover 95% of observed taps, not all of them.

From this, he derives a recommendation: primary content in the center, secondary actions along the top and bottom edges, rarely used functions in menus in the corners.

What this does not mean: that there is a fixed zone where all important elements belong, or that elements at the top of the screen are inherently out of reach. The honest reading is more modest. Targets at the edges and in the corners need more room than targets in the center, and you shouldn’t assume people always hold your product the same way.

In the parking app, the most important button, “Buy ticket,” therefore moves to the lower part of the content as a wide button. Not because there is a magic zone there, but because it is large and distinct enough to hit easily with any grip.

Edge cases

Links in running text

A link in the middle of a sentence can’t be 44 pixels tall without tearing the text apart. WCAG therefore explicitly exempts such targets: a target in a sentence, or one whose size is constrained by the line height of the surrounding text, doesn’t have to meet the minimum size. The W3C explains that with text reflow, authors can’t predict where a link will end up.

The exception isn’t an invitation to be sloppy, though. Generous line height, clearly recognizable links and no two short links right next to each other still help. And note: the exception only applies to links within sentences. A row like “Imprint | Privacy | Terms” in the footer is not running text and has to meet the requirements.

Dense toolbars

Editors, map views and image tools often need lots of tools in little space. Three approaches help. First, spacing: smaller icons with enough room around them can meet WCAG 2.5.8 through the spacing rule. Second, selection: rarely used tools move into an overflow menu, which is itself a sufficiently large target. Third, an alternative: WCAG allows smaller targets if the same function is available through another, sufficiently large control on the same page.

Context matters, too. Google notes that targets can be smaller for precise input with a mouse or trackpad. A dense toolbar in a desktop application is a different matter from the same toolbar on a phone.

In the parking app:

  • Before: Six icons in the bottom bar, each 32 pixels wide, with no labels and no spacing.
  • After: Four labeled items (“Park,” “History,” “Vehicles,” “More”), each at least 48 dp tall and evenly spread across the width. Help and settings live under “More.”

Calendars, tables and pickers

Date pickers are a classic case of tiny targets: seven columns on a narrow screen, every number a separate target. It pays to make the whole cell tappable rather than just the digit, and to offer text input as an alternative where needed. The same goes for lists and tables: if a whole row leads to a detail view, the whole row should respond.

Browser and system controls

Native controls whose size is determined by the browser and that you haven’t modified are exempt from 2.5.8 under WCAG. An unmodified checkbox is formally fine. For people, it is still small, and an associated label enlarges the hit area with no effort at all.

How to check touch targets

Touch targets are handled most reliably where components are built. If buttons, icon buttons and list items in your design system come with a minimum size, nobody has to measure every screen from scratch. The article Design Systems for Small Teams shows how to get there with little effort.

Beyond that, a few simple checks help:

  • In the design file: Draw hit areas as their own semi-transparent layer. You’ll see right away where they are too small or overlap.
  • In the browser: Use the developer tools to measure the actual size of links and buttons, including padding.
  • On Android: Google recommends Accessibility Scanner for manual on-device testing. Note that it only recognizes TouchDelegate on Android 10 and later.
  • On real devices: Use the app with one hand, while walking, with your thumb. Count the mistaps.
  • With people: In usability tests, watch for accidental taps, repeated attempts and corrections. Tests with older adults or people with motor impairments are especially revealing.

More tools and methods are covered in the article Accessibility Testing: Tools and Methods for UX Designers.

Limits and pitfalls

Bigger isn’t always better. Targets can get so large that hardly any content fits on screen and people have to scroll more. The goal is targets that are big enough, not as big as possible.

The minimum is not a design decision. Building everything at exactly 24 × 24 pixels because that is “WCAG compliant” puts you well below what Apple, Google and research recommend for touch. The W3C explicitly recommends larger targets for controls that are used frequently, hard to undo or hard to reach.

Numbers don’t replace testing. The values from guidelines and studies are averages. People with tremors, large hands or gloves in winter need more leeway. Only testing with the people who actually use the product shows how much. The article Why Accessibility Is More Than Contrast and Font Size explains why accessibility goes far beyond individual rules like these.

Thumb zones are not building codes. Pushing every control to the bottom because a graphic suggests it ignores how differently people hold their devices. Hoober himself now considers such charts incorrect.

Conclusion

How big buttons on a phone need to be has a surprisingly clear answer. Legally and under WCAG 2.2 AA, the floor is 24 × 24 CSS pixels or enough spacing. For comfortable finger use, aim for 44 × 44 points (Apple) or 48 × 48 dp (Google), which is roughly one centimeter. Research from Fitts to Parhi supports this order of magnitude.

More important than the exact number are three principles: the hit area counts, not the visible size. Spacing matters as much as size. And edges and corners need more room than the center. After the redesign, the parking app from the example has larger stepper buttons, quick picks, an “X” with a proper hit area and a tidy navigation bar. Visually, little has changed. But nobody has to tap three times to buy a parking ticket anymore.

Checklist

  • All touch targets are at least 24 × 24 CSS pixels or have enough spacing (WCAG 2.5.8).
  • Important controls reach 44 × 44 pt or 48 × 48 dp.
  • Small icons have a larger, invisible hit area through padding.
  • Hit areas don’t overlap.
  • There are at least 8 dp between targets, and dangerous actions sit apart.
  • Targets at the edges and in the corners are more generous than those in the center.
  • Labels for checkboxes and radio buttons are associated and tappable.
  • Links outside running text, for example in the footer, meet the minimum size.
  • Dense toolbars are reduced or have an alternative.
  • Minimum sizes are built into the design system.
  • Operation has been tested one-handed on real devices.

Sources

Back to “All articles”

You might also like

Comic Sans: Why the World’s Most Hated Typeface Is Treated Unfairly

Design

Comic Sans is called the most hated typeface in the world, unfairly. Its story shows that the hate is really about how it was misused.

Forms Nobody Abandons: 12 Rules for Better Form UX

Design

Visible labels, well-timed validation, helpful error messages: 12 proven rules for forms, explained step by step using a real-world checkout example.

Design Systems for Small Teams: When They Pay Off and How to Start Small

Design

When a design system pays off for a small team and how to build one in twelve weeks: from a UI inventory and design tokens to your first ten components.