Responsive web design for developers: practical techniques

Key Takeaways

Responsive web design succeeds when mobile-first CSS, fluid images, and layered layout tools (Flexbox, Grid, container queries) work together rather than as isolated fixes.

Point Details Start with the viewport tag Without width=device-width, mobile browsers simulate desktop widths and break every media query. Build mobile-first Write base styles for small screens, then add min-width queries as content needs more space. Match layout tool to the job Use Flexbox for one-dimensional rows, Grid for two-dimensional page and card layouts. Let the browser pick images Use srcset and sizes instead of one oversized file, and reserve space with aspect-ratio to cut layout shift. Cap fluid type ratios Keep clamp() maximum values to around 2.5 times the minimum to protect zoom accessibility. Consult a specialist for legacy migrations Project-pixel offers fixed-price rebuilds for businesses moving old, non-responsive sites onto a modern mobile-first foundation.

What is responsive web design, and where did it come from?

The term comes from Ethan Marcotte's 2010 article for A List Apart, which named three techniques that still form the backbone of the discipline: fluid grids, flexible images, and media queries. Marcotte's argument wasn't really about CSS. He framed devices as facets of one experience rather than separate targets requiring separate builds, a philosophy that still cuts through a lot of modern over-engineering.

That origin gives responsive design three goals worth keeping visible on a sticky note above your monitor:

Those three pillars, fluid grids, flexible images, and media queries, are also exactly what MDN's Learn web development series still teaches as the foundation, sixteen years after Marcotte's original piece.

• 01Usability across devices - the same content and functionality work whether someone's thumb or a mouse is doing the navigating.
• 02A single maintainable codebase - one set of templates, one CMS, one deployment pipeline, not three parallel mobile and desktop builds drifting out of sync.
• 03Performance awareness - a responsive layout that ships desktop-sized images to a phone on 4G has failed the brief, even if it looks fine in DevTools.

Core techniques: fluid grids, media queries, and the viewport tag

Start with the meta tag every responsive page needs:

```html

```

Then a minimal mobile-first media query:

```css .card-grid { display: grid; gap: 1rem; grid-template-columns: 1fr; }

@media (min-width: 48rem) { .card-grid { grid-template-columns: repeat(3, 1fr); } } ```

Fluid grids use relative units, percentages, fr, rem, rather than fixed pixel widths, so containers resize proportionally instead of snapping or overflowing at odd widths.

A short checklist for writing media queries that won't fight you in six months:

Pro Tip: *Group media queries by component rather than bunching them all at the bottom of a global stylesheet. It's slightly more repetitive, but when you delete a component, its responsive rules go with it instead of rotting in a forgotten global file.*

A sensible build order looks like this:

• 01Use min-width, not max-width, as your default direction. It matches mobile-first thinking.
• 02Pick breakpoints where your *content* starts looking cramped, never where a specific phone's screen width happens to end.
• 03Keep breakpoint values in a shared set of custom properties or Sass variables so they don't drift across files.
• 04Write unstyled, semantic HTML first.
• 05Apply mobile base styles with no media queries at all.
• 06Layer min-width queries as the layout genuinely needs more space.
• 07Test at odd intermediate widths, not just common device sizes.

Flexbox, CSS Grid, or something else entirely?

Pick the tool based on the dimension you're actually controlling, not habit. Flexbox handles one-dimensional flows (a row of nav links, a toolbar, a button group). Grid handles two-dimensional layouts (page structure, card layouts, anything with rows and columns that need to line up).

A simple Flexbox nav bar:

``css .nav { display: flex; justify-content: space-between; align-items: center; flex-wrap: wrap; } ``

A CSS Grid card layout that reflows without a single media query:

``css .cards { display: grid; gap: 1.5rem; grid-template-columns: repeat(auto-fit, minmax(16rem, 1fr)); } ``

That auto-fit/minmax pairing is what Scrimba's layered 2026 approach calls intrinsic Grid: layouts that respond to available space without you writing explicit breakpoints at all.

Layout need Better tool Why Navigation bars, toolbars Flexbox One-dimensional alignment and wrapping behaviour Card grids, dashboards CSS Grid Two-dimensional control, template areas Breakpoint-free reflow Intrinsic Grid Adapts to container width automatically Full page scaffolding CSS Grid Named template areas keep header, sidebar and footer coherent

If you'd rather not hand-roll every grid from scratch, Bootstrap still ships a solid responsive grid and component set, useful for prototypes or projects on a tight timeline, though it adds CSS weight you'll want to audit later. Designers usually block out these layouts in Figma first, using its own auto-layout and constraint tools to simulate breakpoints before a developer touches code.

Getting responsive images and video right

Serving one enormous image to every device wastes bandwidth on mobile and can still look soft on a high-density display. srcset with width descriptors lets the browser choose:

```html

```

For art direction, where you want a different crop on mobile, use ``:

```html

```

A few things matter as much as the markup itself:

Pro Tip: *Let the browser do the picking. Developers who hand-code one "responsive" image size for every breakpoint usually end up shipping the largest file to everyone, which defeats the entire point of srcset.*

• 01Set aspect-ratio on image containers and reserve space up front. MDN recommends this specifically to stop cumulative layout shift as images load in.
• 02Use loading="lazy" for anything below the fold; reach for an Intersection Observer fallback only if you need finer control than the native attribute gives you.

Fluid typography and spacing without the ugly jumps

Mixing unit types deliberately, rather than picking one and using it everywhere, is what keeps type both fluid and accessible. rem respects a user's browser font-size setting; vw scales with viewport width but ignores zoom preferences entirely if used alone.

clamp() solves that tension by giving you a minimum, a fluid middle value, and a maximum:

``css h1 { font-size: clamp(1.75rem, 1.2rem + 2vw, 3rem); } ``

Scrimba's guidance on this is specific: keep a rem component in the calculation so zoom still works, and hold the maximum to no more than roughly 2.5 times the minimum to avoid failing WCAG zoom requirements.

For spacing, apply the same fluid logic to margins and padding rather than jumping between fixed values at each breakpoint, and keep body text around 60 to 75 characters per line regardless of screen width. Wide desktop columns of unbroken text are one of the most common readability failures on otherwise well-built responsive sites.

How should you choose breakpoints in a mobile-first build?

Content should choose your breakpoints, not a list of popular device widths that'll be outdated within eighteen months. Start with unstyled mobile layouts, then add complexity only once the design visibly needs more room:

```css /* mobile base styles first */ .layout { display: block; }

@media (min-width: 48rem) { .layout { display: grid; grid-template-columns: 1fr 3fr; } } ```

Quick do's and don'ts:

Adjust these four numbers to your actual content rather than treating them as gospel. A dense data table might need its first real breakpoint far earlier than 48rem; a single-column blog might not need one until 64rem.

• 01Do pick a breakpoint the moment text lines get too long or a grid feels cramped, wherever that happens to land.
• 02Do treat these as starting points, not fixed law: 30rem, 48rem, 64rem, 90rem.
• 03Don't name breakpoints after devices ("iPhone breakpoint"). Screen sizes fragment constantly, and that naming convention ages badly within a year.
• 04Don't write your base CSS for desktop and try to compress it down with max-width queries. It's more code, and it fights the direction most traffic actually arrives from, given that most UK web traffic is now mobile.

What performance and accessibility checks actually matter?

Responsive layout choices show up directly in your Core Web Vitals scores, so treat performance and accessibility as one checklist, not two separate concerns.

Performance:

Accessibility:

Two metrics respond most directly to responsive decisions: Cumulative Layout Shift (CLS), driven largely by unreserved image and ad space, and Largest Contentful Paint (LCP), driven by oversized hero media. Interaction to Next Paint (INP) matters too, particularly on touch interfaces with heavy JavaScript.

• 01Compress and serve appropriately sized images (see the srcset section above).
• 02Inline critical CSS for above-the-fold content; defer the rest.
• 03Cut third-party scripts ruthlessly, each one is a render-blocking risk on a slow mobile connection.
• 04Run Lighthouse regularly, not just before launch.
• 05Check colour contrast ratios at every breakpoint, not just desktop.
• 06Keep touch targets at a minimum of roughly 44 by 44 pixels.
• 07Verify keyboard focus order matches visual order once your layout reflows.
• 08Use semantic markup and real alt text, not decorative filler.
• 09For public-sector projects, Gov are a legal baseline, not a suggestion.

A practical workflow for testing responsive layouts

Skipping structured testing is how a layout that looks perfect on your 27 inch monitor ships broken on a mid-range Android phone. Work through this sequence:

Recommended tools worth keeping in your workflow permanently: Chrome DevTools, Lighthouse, BrowserStack, an accessibility linter such as axe, and a habit of taking responsive screenshots at each breakpoint for design review.

When something breaks, isolate the component with a container query test case, add temporary coloured outlines to see what's overflowing, and check whether a missing aspect-ratio is causing shift rather than assuming it's a CSS specificity issue.

• 01Start in Chrome DevTools device emulation, but don't trust it as your only check.
• 02Test on at least one real phone and one real tablet, emulation misses touch quirks and real network conditions.
• 03Run Lighthouse for performance and accessibility scoring.
• 04Cross-browser test with BrowserStack or similar to catch Safari and older Edge inconsistencies.

Three patterns you'll build on almost every project

Accessible header with a hamburger menu on mobile:

```html

Menu

```

Toggle hidden and aria-expanded with JavaScript; never hide navigation from screen readers entirely.

Card grid with intrinsic Grid (shown earlier in the Flexbox/Grid section) works well here too, no changes needed beyond content.

Fluid article layout:

``css article { max-width: 42rem; margin-inline: auto; font-size: clamp(1rem, 0.9rem + 0.4vw, 1.15rem); } ``

All three degrade gracefully in older browsers that lack full Grid support, they simply fall back to block layout rather than breaking outright. If your team designs in Figma, export spacing tokens and type scales directly rather than eyeballing them from a static mock, it keeps the clamp() values above genuinely matched to design intent.

• 01Home

Progressive enhancement versus a separate mobile experience

Default to progressive enhancement: build a solid, accessible baseline, then layer on richer interaction for browsers and devices that support it. Reserve a fully separate mobile experience for genuine edge cases.

Run through this before considering a separate build:

Weigh it honestly:

Marcotte's original argument still holds here: treat devices as facets of one experience, and reserve separate builds for cases where user goals are demonstrably different, not just where the screen is smaller.

• 01Do mobile and desktop users actually want different outcomes, or just a different layout?
• 02Can your existing responsive templates absorb the difference with conditional components instead of a parallel codebase?
• 03What's the real maintenance cost of running two systems indefinitely?
• 04A separate mobile app or site doubles testing overhead and risks content drifting out of sync.
• 05SEO parity suffers when mobile and desktop content structures diverge, search engines index the mobile version by default.
• 06Development complexity compounds with every feature you have to build twice.

Making an old, non-responsive site play nicely with new responsive code

Retrofitting responsiveness onto a legacy site is rarely a clean rewrite, and pretending otherwise leads to blown budgets. The realistic approach is incremental: wrap old, fixed-width components in a responsive shell rather than rewriting the entire template in one pass.

Start by auditing which pages actually get mobile traffic, prioritise those first. A legacy pricing table with inline pixel widths can often be contained inside a new responsive wrapper with overflow-x: auto as a stopgap, buying time before a full rebuild.

Watch for these recurring legacy problems:

For sites past a certain age, a full rebuild on a modern, mobile-first foundation is usually cheaper over three years than continuing to patch. If you're weighing that decision, Project-pixel's redesign and rebuild service is built specifically around migrating legacy sites without losing existing SEO equity or content.

• 01Inline style="width:960px" attributes that override anything your new CSS tries to do, these need removing, not overriding.
• 02Old JavaScript that reads window.innerWidth and branches logic accordingly. It'll conflict with CSS-driven responsive behaviour and should be phased out in favour of CSS media or container queries.
• 03Table-based layouts from pre-2012 builds, these rarely reflow and usually need a genuine rebuild rather than a patch.
• 04Legacy CMS templates that generate fixed-width markup server-side, no amount of client-side CSS fixes a layout the server is actively fighting.

Why mobile-first fits how Project-pixel builds

We build mobile-first by default because that's how most service-business customers actually arrive, searching on a phone, often mid-task. It also forces the discipline of prioritising content before decoration, which suits fixed-price, fixed-deadline delivery. Consult Project-pixel specifically for legacy-site migrations, ecommerce complexity, or accessibility remediation where a general-purpose rebuild isn't enough.

Ready to hand the implementation to a studio that lives in this code daily?

Project-pixel is the alternative to piecing together your own responsive build from tutorials and framework docs: a fixed-price package that bundles strategy, design, copywriting, essential SEO, and a mobile-optimised build into one deadline-driven process, rather than an open-ended hourly engagement.

Every project follows the same seven-stage process, so you know what's happening and when, without chasing an agency for updates. If your business operates in a sector with specific responsive demands, booking flows for a dental practice, image-heavy galleries for a wedding venue, dense listings for trades, Project-pixel's industry-specific web design work starts from patterns already proven in that space rather than a generic template. Get in touch for a fixed-price quote and a delivery date you can actually plan around.

Sources

For specification-level detail beyond this guide, these five sources cover different angles:

• 01Responsive Web Design - A Complete Guide 2026 | Scrimba
• 02Responsive Web Design - A List Apart
• 03Gov

FAQ

What is responsive web designing?

It's a development approach where a single set of HTML and CSS adapts its layout, images, and typography to whatever screen size or device is viewing it, rather than serving separate mobile and desktop versions.

Is responsive web design still a thing?

Yes, and it's more layered than it was a decade ago: mobile-first media queries now work alongside container queries, clamp(), and intrinsic Grid to handle both page-level and component-level responsiveness.

How much do responsive web designers make?

Earnings vary widely by region, seniority, and whether you're freelance or in-house, so there's no single reliable figure to quote here. Studios like Project-pixel instead price responsive builds as fixed-fee packages rather than by developer day rate, which gives clients cost certainty upfront.

What is a good example of a responsive website?

A well-built responsive site reflows a card grid from one column on mobile to three or four on desktop, swaps a full navigation bar for a hamburger menu below a set breakpoint, and serves appropriately sized images at each width via srcset rather than one fixed file. Project-pixel builds every client site to this standard as the default, not an upgrade option.

Recommended

• 01Modern web design in 2026: the global trends actually wor…
• 02Website Redesign Services UK | Bespoke Rebuilds
• 03Web Design Glossary - 45+ Terms Explained | Project Pixel
• 04Custom App Development - Project Pixel