Designing for tablet screens: two columns, touch and the awkward middle width
Tablets fall between the phone and laptop layouts, and they're where responsive sites most often look stretched or cramped. Let content decide where columns split rather than device names, keep reading text to a comfortable measure, and assume touch: anything that only appears on hover, such as a dropdown menu or a tooltip, needs a tap equivalent.
Why the middle width is awkward
Most sites are designed at two sizes: a phone around 375 pixels wide and a laptop around 1280. Everything between is left to the CSS to sort out. A tablet in portrait sits around 768 to 834 CSS pixels, and in landscape around 1024 to 1366, so it lands right in the zone nobody drew. The phone layout stretched to tablet width gives lines of text too long to read and images blown up past their sharpness. The desktop layout squeezed down gives three columns of cards so narrow that headings wrap word by word.
Tablets also mix input types. Most people tap, some use a keyboard and trackpad, and a few use a stylus. A layout can't assume either a phone's thumb or a laptop's cursor.
Breakpoints from content, not devices
A single "tablet breakpoint" at 768px was a reasonable shortcut when there were a handful of popular tablets. Today the widths are spread out, and foldable phones open into tablet-sized screens. A better method is to widen the browser slowly and add a breakpoint where the content starts to look wrong: when a line of body text runs past 75 characters, when a card grid's columns get narrower than their content needs, or when a split layout's text column drops below about 45 characters. Responsive design breakpoints goes deeper.
| Content | Portrait tablet | Landscape tablet |
|---|---|---|
| Hero with photo beside text | Stack text above the photo | Side by side, if the text column keeps 45 characters |
| Grid of cards or products | Two columns | Three columns |
| Article body | One column at 60 to 70ch, centred | Same, with optional sidebar |
| Dashboard with sidebar | Collapse the sidebar into a menu | Keep a narrow sidebar |
| Pricing plans | Stack, or two then one | Three across if each stays readable |
| Forms | One column, wider fields | One column; don't spread it across the screen |
Touch changes hover-reliant designs
On a touch screen there is no hover. Tablets often fake it by treating the first tap as a hover and the second as a click, which makes dropdown menus feel broken and hides tooltips completely. CSS can tell you what the main input can do: the hover media feature reports whether it can hover conveniently, and MDN's pointer reference explains coarse for fingers and fine for a mouse or trackpad. Use them to adjust, not to hide essentials.
- Menus open on tap or click, not hover alone, and close with a second tap or the Escape key.
- No information only in tooltips. Put it in the label, or behind a tappable info button.
- Hover effects as a bonus. A card can change on hover where
@media (hover: hover)matches, but the link inside must work without it. See hover effects for websites. - Larger targets under coarse pointers. Inline links in dense lists and small icon buttons need room for a finger; see touch target size.
- Content that appears on hover or focus must stay put. WCAG's Content on Hover or Focus asks that it can be dismissed, hovered over and stays visible until the visitor moves away.
Common tablet failures
- Full-width text running edge to edge in landscape because only the container, not the text, has a maximum width.
- Phone navigation, a single menu button, kept on a 1024px screen with room for every link.
- A full-height hero that fills a landscape tablet so completely that nothing below it is visible.
- Photos cropped for phone portrait and laptop landscape that cut heads off at the in-between ratio.
- Split-screen keyboards and multitasking views that make a tablet behave like a phone; the layout should still work at those widths.
How to test without a drawer of devices
- Drag the browser window slowly from 600px to 1400px and watch for the moment anything breaks, overflows or looks stretched.
- Use the browser's device toolbar for portrait and landscape at a few tablet sizes.
- On a real tablet, tap through the navigation and every menu, and try a hardware keyboard if you have one.
- Zoom to 200% on a laptop: the layout you'll see is close to a tablet's, which is a useful second check.
Tablets and Anticode
Anticode's seven design systems are responsive rather than built for fixed devices: pages from the design engine reflow their grids and split layouts as the screen narrows, and body text is set at 16.5 to 19.5px depending on the system. Hover in those systems is never the only way to reach anything, because links and buttons work the same on tap.
For app builds, the self-review, when it's available, opens a new build in a headless browser at phone and laptop widths, takes screenshots and clicks through it, and the Critic fixes what it finds. Tablet widths aren't part of that review, so they're worth a manual look, especially for dashboards and tools with sidebars.
Questions people ask
Should tablets get the mobile or desktop layout?
Neither by default. Portrait tablets often suit a two-column version between the two, and landscape tablets usually take the desktop layout if text stays at a readable width.
What breakpoint should I use for tablets?
Set breakpoints where your content breaks, not at device widths. Widen the browser slowly and add one where columns get too narrow or lines too long.
How do I handle hover menus on an iPad?
Make them open on tap or click and close on a second tap or Escape. Never put information only in a hover state.