Responsive Design

A page that works at one width is a page that works on one device. Responsive design means the layout adapts: one column on a phone, two on a tablet, four on a desktop. In Tailwind this is the same variant mechanism as chapter 6, with a screen size as the condition: md:grid-cols-2 is "two columns, from the md width upwards". There is one rule to learn (it is mobile-first) and one newer tool to add (container queries, which respond to the size of a parent rather than the screen).

Mobile-First: The One Rule

Tailwind's breakpoints are five named widths, defined in the theme and compiled to min-width media queries:

A class with no prefix applies at every width. A prefixed class applies at that width and everything wider. So you write the phone layout with plain classes first, and use the prefixes to change it as the screen grows. I put six background colours on one element and resized the viewport:

The boundaries are inclusive: at exactly 640px the sm: colour is already in force, at 639px it is not. And each colour holds until the next prefix takes over. This is the idea that trips people up: sm: does not mean "on small screens". It means "from the small breakpoint (640px) up". If you want something on phones only, the plain class is the phone style, and you cancel it above:

Max-Width, Ranges and Arbitrary Breakpoints

Mobile-first covers most needs, but you can also target "below" a width:

Use max-* and ranges sparingly: they are for the case where a style is needed only in a middle band, such as hiding something between tablet and small-laptop sizes. A one-off width that is not on the scale goes in brackets. Adding your own named breakpoint to the theme (--breakpoint-xs) is chapter 9. The same mechanism also has a few other conditions: landscape: and portrait: (orientation), print: (@media print), and pointer-coarse: and pointer-fine: (@media (pointer: coarse | fine), handy for making touch targets larger on touch screens). Dark mode, reduced motion and contrast are chapter 8.

Designing Upwards from a Phone

The workflow follows from mobile-first. Build the layout at about 360 to 390px wide with plain classes. Widen the window; the moment it looks wrong, add one breakpoint class that fixes that. Three patterns cover most pages, all measured:

A card grid that gains columns:

A navigation bar that shows its links from md and a menu button below it. The links are hidden md:flex (not displayed, then a flex row from 768px) and the button is md:hidden (shown, then hidden from 768px). Measured: at 767px the links had display: none and the button display: block; at 768px the links were flex and the button none. The open-and-close behaviour of the menu needs a few lines of JavaScript or a <details> element; Tailwind handles only the showing and hiding.

Type and spacing that grow: p-4 text-2xl md:p-8 md:text-4xl measured 16px of padding and 24px text up to 767px, then 32px and 36px from 768px.

Images already behave, thanks to Preflight (chapter 1): img { max-width: 100%; height: auto }, so a large image shrinks to fit a small screen. For a fixed shape use aspect-video w-full object-cover (chapters 4 and 5), and to show different images at different sizes combine hidden md:block with md:hidden. Serving smaller files to smaller screens is HTML's job (srcset and <picture>), not Tailwind's.

Container Queries: Responding to the Parent

Breakpoints ask "how wide is the screen?". That is the wrong question for a reusable component. The same product card might sit in a wide main column and in a narrow sidebar on one page, at one screen width. A container query asks "how wide is the box I am in?". Mark the parent with @container and use the @-prefixed variants on its descendants:

@container sets container-type: inline-size, which tells the browser to track the element's width so queries can use it. @md: then applies when the nearest container is at least 28rem (448px) wide. Note that the container sizes are not the screen breakpoints: they come from the container scale, which is smaller:

Here is the difference from breakpoints, measured. The viewport was 1200px wide in every case. A grid with grid-cols-1 @md:grid-cols-2 was placed inside a container, and beside it a grid with grid-cols-1 md:grid-cols-2 (a screen breakpoint):

The container-query version adapted to its 300px box; the screen-breakpoint version squeezed two columns into it. The same component dropped anywhere on the page lays itself out correctly. Three more details, all measured:

• The query measures the container's content width, inside its padding. A container w-[460px] p-4 has 428px of content (460 − 32), which is below 448px, so @md: did not apply (1 column). w-[480px] p-4 has exactly 448px of content, and @md: applied (2 columns).
• Named containers let a nested layout pick which one it listens to: @container/card (container-type: inline-size; container-name: card) and @md/card: (@container card (width >= 28rem)). A 500px named container gave 2 columns.
• It is not the container class from chapter 4. That one is a centred page wrapper with screen-width limits; @container declares a query container. The names are similar and the two are unrelated.

By the rules of CSS containment (not something I measured), a container with container-type: inline-size cannot take its width from its own contents, so give it a width from its parent or from layout, as the examples above do. As a rule of thumb: use screen breakpoints for the page's overall structure (header, columns, navigation) and container queries for components that appear in more than one place.

Testing Responsive Layouts

In Chrome and Edge, press Ctrl+Shift+M in DevTools to open the device toolbar; Firefox has the same shortcut for its Responsive Design Mode. Drag the width handle slowly from 320px up to 1600px and watch each breakpoint fire (the toolbar can show the media-query bands), then try a phone preset to see the viewport meta tag working. Two checks are worth doing on every page: that nothing scrolls sideways at 320px (a common cause is a fixed width wider than the screen, or the 1fr issue from chapter 4), and that the touch targets are comfortable at phone sizes. An emulator is not a phone: test on a real device before you ship something important.

Hands-On Exercises