Touch targets: how big does a button on a phone have to be?

In short

The touch target is the area a user can tap to activate an element. The W3C defines the target as a region of the display that accepts pointer actions. So you don’t measure the drawn icon but the tappable area around it.

Source	Size	Note
Apple (iOS, iPadOS)	44 × 44 pt	Default size for controls. Minimum 28 × 28 pt.
Android, Material	48 × 48 dp	About 9 mm according to Google. Larger is better.
WCAG 2.2, 2.5.8 (AA)	24 × 24 CSS pixels	With a spacing exception.
WCAG 2.2, 2.5.5 (AAA)	44 × 44 CSS pixels	The W3C recommends this for important controls.

Platform details and the difference between iOS and Android are covered in the mobile app design guide. This page covers the pattern itself. First I separate visible size from tappable area; then it is about spacing and screen edges.

Why small targets are a problem

The smaller the target, the harder it is to hit. Fitts’s law measures this as time. On a touchscreen, the mis-tap comes on top: the finger misses the target and hits the element next to it.

Aurora Harley of NN/g cites a finding from the MIT Touch Lab: a fingertip is usually 1.6 to 2 cm wide. The contact area of the thumb averages 2.5 cm. According to Harley, the real culprits are small targets.

The W3C also lists who criterion 2.5.5 helps. The list includes people with tremors, people who find fine motor movements difficult and anyone using the device with one hand. It also includes users being shaken about on public transport.

Visible size and touch area

An icon can look 20 pixels big and still respond to a tap in a 44-pixel area. The core of the pattern is to think of the two sizes separately. Layout and legibility set the visible size; the finger sets the touch area.

Android’s Compose documentation gives an example: a clickable checkbox reaches at least 48 dp in width and height through padding. Switch, RadioButton and Slider apply this minimum by themselves. If you build your own interactive element, you have to set the size yourself.

Apple’s general rule for buttons points in the same direction. A button’s hit region should be at least 44 × 44 pt. Apple asks for this so that users can hit the button comfortably with a finger as well as with a pointer.

Harley calls elements that are big enough to see but too small or too tight to tap comfortably “view–tap asymmetry”. Seeing is easy; tapping is hard. Because the area is invisible, the icon itself should be a clear signifier.

In the two rows below, the quantity buttons are the same size. The toggle shows you the tappable areas.

Visible size and touch area

Before: area as big as the icon

Ground coffee, 12 oz

1

Visible circle 20 px, touch area 20 × 20 px.

After: same icon, 44 px area

Ground coffee, 12 oz

1

Visible circle 20 px, touch area 44 × 44 px.

The dashed line shows the area the button responds to. In both rows the icons are the same size. In the right row, the area was enlarged to 44 pixels with an invisible layer.

The quantity buttons in the cart are 20 pixels in both rows. Around the right one sits an invisible layer that enlarges the area to 44 pixels. If JavaScript is off, the dashed lines are always visible.

Spacing between targets

Harley’s order is clear: targets must first be big enough and then well spaced. Extra spacing doesn’t rescue a target that is too small anyway.

The sizes differ by source:

• Apple recommends about 12 pt of padding around bezeled elements. For elements without a bezel, leave about 24 pt around the visible edge.
• Google’s Android accessibility help page asks for 8 dp or more between targets.
• WCAG 2.5.8 allows targets under 24 pixels through the spacing exception.

The W3C spacing test works like this: draw an imaginary circle 24 CSS pixels in diameter around the centre of the small target’s bounding box. If the circle doesn’t touch any other target or the circle of another small target, the target passes.

Even so, the W3C considers it good practice to meet the 24-pixel minimum even when the spacing would be enough. I use the spacing exception only as a last resort.

Enlarged areas mustn’t overlap. Android’s Compose documentation recommends giving a small element enough size from the start to avoid overlaps.

Edges and corners

Not every part of the screen is hit equally well. According to Steven Hoober’s article on UXmatters, people prefer to look at and tap the centre of the screen. They are also more accurate there.

That is why Hoober recommends sizes by position. A target in the centre can be as small as 7 mm; a target in the corner should be about 12 mm. According to Hoober, his suggested target sizes contain 95% of the observed taps.

The same article has data on grip too. 75% of users touch the screen with only one thumb. Fewer than 50% hold their phone with one hand.

This is how I apply it: I give the close, back or menu icon in the corner more area than the buttons in the centre. I also don’t put an irreversible action such as Delete right next to a frequently pressed button.

Live example: finger test for touch targets

Take your phone and tap the orange circle. First try 16 pixels with 2 pixels of spacing a few times, then switch to 44 or 48 pixels. On desktop it works with the mouse too, but you feel the difference most clearly with your thumb.

Finger test for touch targets

This test needs JavaScript. When it is on, you see 16 circles in a 4 × 4 grid. One is orange, and that is the one you tap. You set the circle size to 16, 24, 44 or 48 pixels and the spacing to 2 or 8 pixels.

Tap the orange circle; after each hit the target moves. A tap on the neighbouring circle or in the gap counts as a mis-tap. The test measures nothing; it makes the difference tangible. The result depends on your finger, phone and grip. With the keyboard, only the orange circle receives focus.

With small, tightly packed circles it is very easy to hit the neighbour. The table counts each setting separately, so you see different sizes side by side with the same finger.

The exceptions to WCAG 2.5.8

The 24-pixel rule in WCAG 2.2 has five exceptions. Knowing them keeps unnecessary findings out of an audit.

• Spacing: when the small target passes the circle test above.
• Equivalent: when another control on the page performs the same function and meets the rule.
• Inline: when the target is in a sentence or its size is constrained by the line height of the text.
• User agent control: when the browser sets the size and the author hasn’t changed it.
• Essential: when this presentation is essential to the information or legally required.

I read the inline exception narrowly. A single “Details” link under a card isn’t part of a sentence. The rule applies to that link.

Implementation: enlarging the touch area with CSS

There are two ways to enlarge the area without changing the design. The first is an invisible layer on the button. The second gives the button itself a minimum width and height and centres the icon.

/* 1. Invisible layer: icon 20 px, touch area 44 px */
.icon-button {
  position: relative;
  width: 20px;
  height: 20px;
}
.icon-button::after {
  content: "";
  position: absolute;
  inset: -12px; /* 12 + 20 + 12 = 44 */
}

/* 2. The button itself grows, the icon stays centred */
.icon-button--box {
  display: inline-grid;
  place-items: center;
  min-width: 44px;
  min-height: 44px;
}
.icon-button--box svg {
  width: 20px;
  height: 20px;
}

/* 3. Spacing between them on touchscreens */
@media (pointer: coarse) {
  .toolbar { gap: 8px; }
}

In the first approach, the ::after layer is part of the button, so a tap on it lands on the button. If a parent element has overflow: hidden, the layer is clipped and the area shrinks with it. The quantity example above is built this way.

The second approach is safer, because the area really takes up space in the layout and doesn’t stick out over the neighbour. W3C technique C42 uses the same idea: it puts pagination links in containers of at least 24 × 24 pixels.

When checking, measure the tappable area. The size the developer tools show when you select the button doesn’t include the ::after layer.

My note

In audits I always find targets that are too small in the same places. Most often it is plus and minus for the quantity in the cart and the close cross on notification cards. All of them are drawn as an icon in the design and built in code only as big as the icon.

I draw the touch area in the design file as a layer of its own. When the developer sees that layer, they don’t have to guess the size. Recording it as a rule in the design system is easier than discussing it again on every screen.

For the web my floor is 24 pixels and my goal 44. In mobile apps I don’t go below 44 pt and 48 dp.

If you want these sizes checked in your product: the UX audit includes an accessibility review. For a broader review, read the accessibility audit guide.

Checklist

1. Measure the tappable area of every interactive element.
2. On the web, apply the spacing test to everything under 24 × 24 CSS pixels.
3. Aim for 44 pixels for main buttons and frequently used icons.
4. Check that enlarged areas don’t stick out over their neighbours.
5. Give targets in the corners more area than those in the centre.
6. Don’t put an irreversible action next to a frequently pressed button.
7. Go through the flow once completely on a real phone with one thumb.