Responsive Design

Designing a single page so it still looks and works well on a huge range of screen sizes, from phones to large monitors.

What is it?

A page built to look right on a large desktop monitor often looks broken on a phone — text too small to read, content overflowing the screen, layouts that assume far more horizontal space than actually exists. Since the same page can be viewed on a huge range of screen sizes, from a small phone to a wide desktop display, it needs a way to adapt.

Responsive design is the practice of building a page so its layout and styling adjust based on the size (and other characteristics) of the screen viewing it, rather than assuming one fixed size. The main tool for this in CSS is the media query — a rule that says "only apply these styles when the screen matches some condition," most commonly a minimum or maximum width.

A closely related idea is mobile-first design: writing your base styles for the smallest, simplest screen first, then using media queries to add complexity and rearrange things as more screen space becomes available — rather than designing for desktop first and patching things down for smaller screens as an afterthought. Starting small tends to produce simpler, more resilient CSS.

Explain like I'm 10

It's like writing a letter that reformats itself depending on the size of paper it's printed on — one column and large text on a small card, multiple columns and smaller text on a full sheet — without changing a single word of the actual content.

Examples

A basic media query

.container {
  display: flex;
  flex-direction: column;
}

@media (min-width: 768px) {
  .container {
    flex-direction: row;
  }
}

By default (small screens), items stack vertically. Once the screen is at least 768px wide, the media query kicks in and switches the layout to a horizontal row.

A responsive viewport setup

<meta name="viewport" content="width=device-width, initial-scale=1">

Without this tag in the HTML head, mobile browsers often render the page at a wide desktop size and then shrink it to fit, making text tiny. This tag tells the browser to use the device's actual width as the page's width from the start.

How it works

The browser continuously knows the current width (and other characteristics) of its viewport — the visible area of the page. Media queries are evaluated against that viewport, and any CSS rules inside a matching media query are applied on top of (or in place of) the base styles. As the browser window or device orientation changes, the browser re-evaluates these queries and updates the applied styles immediately, without a page reload.

Why does it exist?

Responsive design became essential once people started browsing the web on a huge variety of devices with wildly different screen sizes, rather than mostly one kind of desktop monitor. Building and maintaining entirely separate pages for "mobile" and "desktop" was expensive and error-prone; a single page that adapts itself via CSS is far easier to maintain and keeps content consistent everywhere.

When to use it

Use responsive techniques for essentially any public-facing page today, since you rarely control what device or window size someone will use to view it. Mobile-first is especially valuable when a page's content and priorities genuinely differ by available space, not just its visual size.

When not to use it

An internal tool used exclusively on one known, fixed-size screen (like a kiosk display) may not need full responsive treatment. Even then, it's rarely harmful to have it, so responsive design is close to a default best practice for anything reachable from a general web browser.

Common mistakes

  • Forgetting the viewport meta tag, which causes mobile browsers to render the page at a shrunk-down desktop width.

  • Designing desktop-first and only reluctantly patching things for mobile, leading to bloated CSS with lots of overrides.

  • Testing responsiveness only by resizing a desktop browser window instead of checking on actual or emulated mobile devices too.

Practice exercises

  1. Easy:

    Add a media query that changes a page's background color once the screen is narrower than 500px.

  2. Medium:

    Build a mobile-first navigation bar that stacks links vertically by default and switches to a horizontal row above 768px.

  3. Hard:

    Take an existing desktop-only layout and convert it to mobile-first responsive CSS, listing each media query you added and why.

Interview questions

What is a media query?

A CSS rule that applies a block of styles only when the viewport matches some condition, most commonly a minimum or maximum width.

What does 'mobile-first' mean in responsive design?

Writing base CSS for the smallest screen first, then using media queries to add complexity and rearrange the layout as more screen space becomes available, rather than starting from a desktop layout and shrinking it down.

Why is the viewport meta tag important for responsive design?

Without it, many mobile browsers render the page at a wide, desktop-like width and scale it down, making text and layout appear too small; the tag makes the browser use the device's actual width.

What's the difference between a `min-width` and a `max-width` media query, and which fits a mobile-first approach?

A min-width query applies its styles once the viewport is at least that wide, layering enhancements on top of a base style — this fits mobile-first, since the base (unqueried) styles target the smallest screens and min-width queries add complexity as space increases. A max-width query instead applies once the viewport is at most that wide, which is the pattern used in a desktop-first approach that shrinks things down.

If two media queries both match the current viewport and set different values for the same property, which one wins?

Ordinary CSS cascade rules apply: with equal specificity, whichever rule appears later in the source order wins, regardless of which media query's condition is 'more specific' about screen size — so query order in the stylesheet matters, not just which range is narrower.

Why are relative units like `rem`, `em`, `%`, and `vw`/`vh` generally preferred over fixed `px` in responsive design?

They scale relative to something else — the root font size, a parent's size, or the viewport — so text and spacing adjust automatically as the user's font-size preference or screen size changes, whereas px values stay fixed regardless of context.

What's the difference between `rem` and `em`, and what's a common gotcha with `em`?

rem is always relative to the root (html) element's font size, so it stays consistent no matter where it's used. em is relative to the current element's own font size, which means nested elements using em for font-size can compound — each level multiplying the previous one — leading to unexpectedly large or small text deep in a nested structure.

What is a 'breakpoint' in responsive design, and how should you choose one?

It's the viewport width at which a media query changes the layout. Good practice is to base breakpoints on where your own content actually starts to look cramped or awkward, rather than targeting specific popular device widths, since device sizes vary constantly and content-based breakpoints stay relevant regardless.

What do `max-width: 100%` and `height: auto` do for images in a responsive layout?

max-width: 100% keeps an image from ever rendering wider than its container, shrinking it down on narrow screens instead of overflowing. height: auto then preserves the image's aspect ratio as its width changes, so it doesn't get stretched or squashed.

An image has `width: 100%` but still overflows its container on a narrow screen — what's a likely cause?

The image's parent container itself may not actually be narrow — for example, it could have a fixed min-width, or box-sizing isn't set to border-box and padding is pushing its content box wider than intended — so the image is correctly filling 100% of a container that's already too wide.

What's the practical difference between using `srcset`/`sizes` versus just scaling one large image down with CSS?

srcset lets the browser choose and download a differently-sized image file suited to the actual display size and device pixel ratio, so a phone downloads a genuinely smaller file. CSS-only scaling still downloads the single full-size image regardless of screen size, wasting bandwidth on smaller devices.

What's the difference between 'responsive' (fluid) design and 'adaptive' design?

Responsive design uses fluid, relative-unit layouts and media queries that adjust continuously across a wide range of sizes. Adaptive design instead serves a small number of fixed, discrete layouts targeted at specific known breakpoints, switching between them rather than flowing continuously.

How does `box-sizing: border-box` help make responsive layouts more predictable?

By default, padding and border are added on top of a specified width, so a width: 50% element with padding can end up wider than 50%. border-box makes width/height include padding and border, so percentage-based and fluid widths behave the way they visually appear to.

If content is hidden at a certain breakpoint with `display: none`, does that mean its resources (like an image) were never downloaded?

Not necessarily — unless the resource itself is conditionally loaded (e.g. via a <picture> element with media conditions, or lazy loading), the browser may still fetch an <img> referenced inside a hidden element, since CSS display rules don't stop the HTML parser from requesting resources it finds.

What's the difference between a media query and a container query?

A media query responds to the size of the entire viewport. A container query (@container, with container-type set on an ancestor) responds instead to the size of a specific containing element, letting a component adapt based on the space it's actually given, regardless of overall screen size — useful for components reused in different-width contexts.

Given `.card-wrapper { container-type: inline-size; }` and a container query targeting it, what does the query actually measure?

It measures the inline-size (width, in a standard horizontal writing mode) of .card-wrapper itself, not the viewport — so a .card inside a narrow sidebar and the same .card inside a wide main column can render differently even though the browser window size hasn't changed.

Why can testing responsiveness only by resizing a desktop browser window miss real problems?

It doesn't reveal issues specific to actual mobile conditions — touch target sizes that are fine for a mouse cursor but too small for a finger, real device pixel ratios affecting image sharpness, slower network conditions, or mobile-specific browser chrome/viewport quirks that a resized desktop window doesn't reproduce.

What does the CSS `clamp()` function do, and how is it commonly used in responsive typography?

clamp(min, preferred, max) picks the preferred value but constrains it to never go below min or above max. For type sizing, this is often used like font-size: clamp(1rem, 2vw + 0.5rem, 2rem), letting the size scale fluidly with the viewport while guaranteeing it never becomes unreadably small or excessively large.

A fixed-position header overlaps the top of the page content differently across screen sizes — how would you handle this responsively?

Reserve space for the header's actual height with padding or margin on the content below it (often recalculated per breakpoint if the header's height changes responsively), or use scroll-margin-top on anchor targets so jumping to an anchor doesn't tuck content underneath the fixed header.

Even with relative units, media queries, and container queries in place, why is testing on real or emulated mobile devices still worth doing?

Emulation and relative units address layout sizing, but real devices surface things CSS alone can't simulate reliably — actual touch interaction and target sizes, real network latency, on-screen keyboard behavior, and browser-specific rendering quirks that differ from a desktop dev tools simulation.