Guide · UX and design

Responsive web design: how to make your site work on every screen

Responsive web design means one website that adapts its layout, images and navigation to the width of the screen, from a small phone to a large monitor. In practice you design the mobile version first, add breakpoints where the content starts to look wrong, and test on real devices before launch. This guide gives you the method, a breakpoint table, a test plan and the failures we are most often asked to fix.

11 min read · Updated 1 October 2026

The managing director opens the new website on her phone on the train the morning after launch. The menu fills half the screen, the price overview runs off the right edge, and the “Send” button on the contact form sits hidden under the cookie banner. On the big screen in the meeting room it all looked perfect. That is the situation responsive web design exists to prevent, and it is still surprisingly common, because many projects are approved on a laptop and tested on mobile at the very end.

The short answer to what responsive web design is: one website, one codebase and one set of content that adapts to the screen. The layout is built from flexible columns, images scale, and at a few widths, called breakpoints, the page changes structure, for example from three columns to one. Google primarily uses the mobile version of your site when it indexes and ranks pages, so mobile is effectively your main edition.

What is responsive web design and what is it made of?

The term is more than 15 years old, and the core idea is unchanged. What has changed is the tooling. Modern CSS can lay out an element based on the space it has available as well as on the width of the whole screen. That makes it possible to build components that behave sensibly wherever they are placed on a page. The five building blocks below are the ones we walk clients through when we explain what they are paying for.

  • Fluid grid. Columns and spacing use relative units, so the layout stretches smoothly and evenly.
  • Flexible images and video. Media scale with their container and are loaded at the size the screen actually needs.
  • Media queries and container queries. Rules that switch layout at given widths of the screen or of the individual component.
  • Scaling typography. Headings grow and shrink with the screen, and body text keeps a readable line length of roughly 60–75 characters.
  • Touch-friendly interaction. Buttons and links are large enough for a thumb, and nothing important hides behind hover effects, which do not exist on phones.

Mobile-first or desktop-first: which approach should you choose?

Mobile-first means you design and code the narrowest version first and then add layout as more space becomes available. Desktop-first is the reverse: you start with the large screen and cut things away. The difference sounds technical, but it changes the decisions that get made in the project.

Desktop-first

  • Design is approved on large screens in the meeting room
  • Mobile gets whatever is left and often ends up as a squeezed version
  • Heavy images and scripts come along to the phone
  • Can make sense for internal tools used almost only on desktop

Mobile-first

  • Forces you to prioritise: what should the user see first?
  • Lighter pages, because extras are added only when there is room
  • Matches how Google indexes your site
  • The desktop version usually ends up calmer and more focused
Two ways to approach the same project.

What we see in practice: the biggest win from mobile-first is prioritisation. When there is only room for one heading, one sentence and one button above the fold on a phone, it becomes obvious what the page is really for. That conversation is worth a lot, and it almost always produces a better desktop page too. We have written more about what belongs at the top in our guide to homepage design.

Which breakpoints should a website have?

There is no official list. The rule of thumb is to place breakpoints where the content starts to look wrong: lines become too long, cards too narrow, or the menu runs out of room. Device sizes change every year, while your content is the thing you know. The table shows the ranges most projects end up with and what typically changes at each.

Typical breakpoints in 2026. The numbers are starting points. The final choice depends on your content and components.

WidthTypical devicesWhat typically changes
320–479 pxPhones in portraitOne column, menu behind a button, stacked cards, full-width buttons
480–767 pxLarge phones, phones in landscapeTwo cards side by side, larger images
768–1023 pxTablets in portraitTwo columns, possibly visible menu, tables can display as tables
1024–1279 pxTablets in landscape, small laptopsFull menu, three columns, sidebar on articles
1280–1535 pxLaptops and standard monitorsFull layout, maximum content width is reached
1536 px and upLarge monitorsContent is centred, only backgrounds and images grow

Container queries: components that know their own space

A product card can sit in a wide list on one page and in a narrow sidebar on another. With classic media queries the card only knows how wide the screen is. With container queries, which all modern browsers support, the card responds to the space it actually has. That means fewer special cases, fewer bugs when editors move blocks around in the CMS, and a design system that lasts.

What has to work especially well on mobile?

Layout is the easy part. The interactive elements decide whether a visitor on a phone becomes a customer. We always review these four areas screen by screen before anything goes out for approval.

Forms and buttons

Apple recommends touch targets of at least 44 × 44 points, and WCAG 2.2 sets 24 × 24 CSS pixels as the minimum. Input fields need the right type, so the phone shows a number pad for phone numbers and the @ key for email. Text in fields should be at least 16 pixels, or iPhones zoom in automatically when the field is tapped. Error messages belong next to the field they refer to, where the user can see them.

Tables, price lists and comparisons

A five-column table does not fit in 360 pixels. There are three good options: let the table scroll horizontally with a clear shadow at the edge, show each row as a card on mobile, or let the user choose which two columns to compare. The right one depends on what the user needs the table for. Price packages usually work best as cards, while technical specifications can often scroll.

Navigation and sticky elements

A menu behind a button is standard on mobile, but the two or three most important actions, such as “Book a time” or “Call”, should be visible without opening it. Be sparing with things that stick to the screen: a sticky header, a chat icon, a cookie banner and a promo bar can together eat a third of a small screen. One fixed bar is plenty.

How does responsive design affect SEO, speed and accessibility?

The three are closely linked. Google assesses your site from its mobile version, Core Web Vitals are largely measured on phones over ordinary connections, and the accessibility requirement called “reflow” is essentially about responsive design: content must be readable at a width equivalent to 320 CSS pixels without horizontal scrolling. The figures below are the thresholds to ask your supplier to hit.

LCP

At most 2.5 seconds until the largest element is shown

INP

At most 200 milliseconds to respond to clicks and taps

CLS

At most 0.1 in layout shift

320 px

Width without horizontal scroll (WCAG reflow)

The classic responsive culprit is images without set dimensions, which make the text jump as they load. The next is a hero image at full desktop size that the phone downloads over 4G. Both are easy to fix when caught early. Read more in our guide to website speed and Core Web Vitals, and check the requirements for your sector in our guide to the Accessibility Act.

How do you test a responsive website?

The browser’s developer tools are a good place to start, but they only simulate screen size. They do not reveal a thumb that misses, a slow processor in a three-year-old Android or Safari behaving differently from Chrome. This is the order we test in.

1

Drag the window slowly

Narrow the browser window gradually from 1600 to 320 px. Problems usually appear between breakpoints.

2

Real devices

At least one iPhone, one older Android and one tablet. Test in portrait and landscape.

3

Zoom and large text

Zoom to 200 and 400 % on desktop and turn on larger text on the phone. Nothing may be cut off.

4

Slow connection

Throttle the network in developer tools and watch what appears first and what jumps.

5

Complete the key tasks

Book, buy or send an enquiry on the phone from start to finish, ideally with a colleague who has never seen the site.

6

Measure after launch

Track Core Web Vitals in Search Console and conversion by device in your analytics.

A test plan that catches most problems before launch.

Step five matters most and is the one most often skipped. Five minutes with a colleague trying to book a time on their own phone reveals more than a whole day in developer tools. If you want to go further, we describe the method in our guide to usability testing.

Which responsive design failures do we see most often?

Failures we are regularly asked to fix, and what solves them.

FailureWhy it happensFix
Horizontal scroll on mobileAn element with a fixed width, such as a table, a video or a long wordMax width on media, hyphenation and tables as cards
Text that jumps while loadingImages and embeds without reserved spaceSet width and height or aspect ratio on all media
Buttons that are hard to hitDesktop sizes reused on mobileAt least 44 px touch area and spacing between links
Key information only on hoverDesigned for a mouseShow the information directly or on tap
Headings that fill the whole screenFixed font size carried over from desktopScaling typography with a minimum and maximum
Cookie banner covers the buttonThe banner was tested on its own, separately from the pageCompact banner at the bottom and testing of the whole flow
Slow mobile pageDesktop images, many scripts, heavy fontsResponsive image sizes, fewer scripts, preloaded fonts

What does a responsive website cost?

In a modern project, responsive design is part of the design and code from day one and should not appear as an extra line in the quote. If “mobile adaptation” is listed as an add-on, ask about it. A simple website typically costs DKK 5,000–15,000 with a freelancer and DKK 15,000–40,000 with an agency, and both should be responsive. The expensive route is making an old fixed-width site responsive afterwards, because the templates have to be rewritten anyway.

A concrete example: an accounting firm with 15 staff has a website from 2016 built on a fixed-width theme. Ten page types, a price overview and a contact form. Making the theme work on mobile means reviewing all ten templates, redesigning the price overview and rebuilding the form. That is essentially the same work as a new standard site, without gaining a faster site or a better CMS. In this case a website redesign is usually the better investment.

How we work with responsive design at Ceptiv

We draw the key screens at both mobile and desktop size in Figma before any code is written, and we build in React and Next.js with components that use container queries where it makes sense. Every component is tested in narrow and wide form, and you can follow and try the site on your own phone along the way in our client panel. Design and development sit in the same team, so nothing is lost in hand-over. We cover that in more depth in from Figma to website.

Our web packages start at DKK 18,000 plus DKK 600 a month for hosting, updates, support, security and backups, and every package is responsive as a matter of course. If you are building a campaign page where mobile ad traffic is everything, read our guide to landing page design as well. And if you want a concrete number for your project, you can get a fixed price within 24 hours.

Questions about responsive web design

Is a separate mobile site (m.domain.com) still a good idea?
Not for a new website. A separate mobile site means two sets of pages, two sets of copy to keep updated and extra work with canonical tags and redirects so Google understands how they relate. It was a workaround from before browsers handled flexible layouts well. If you still run an old m. site, now is a good time to merge it into one responsive site and plan the redirects carefully so you keep your rankings.
What is the difference between responsive and adaptive design?
Responsive design is fluid: the layout stretches continuously with the screen and changes structure at a few breakpoints. Adaptive design serves a fixed layout for each of a handful of screen sizes, and everything in between gets the closest match. Adaptive gives very precise control, but it needs more designs and often looks off on devices nobody planned for. For the vast majority of websites, responsive is the most robust and cheapest option to maintain.
Should we build an app instead of a responsive website?
Only if users return again and again and need something a website struggles with: push notifications, offline access, the camera or a permanent spot on the home screen. For being found, explaining your services and generating enquiries, a responsive website is the right tool. Many start with a responsive web app and build a store app later, once usage is proven. Our guide to web app vs native app walks through that decision step by step.
Can we trust a WordPress theme that says it is “responsive”?
The theme demo usually looks fine on mobile, because it is built with short headings and images in exactly the right formats. Problems start when your own content arrives: long headings, tables, embedded forms and plugins that each bring their own CSS. Ask to see the theme with your real copy and test the key pages on a phone before you decide. It takes an hour and saves many more later.
Do we need different images on mobile and desktop?
Often yes, especially for large hero images. A wide panorama with a person on the right becomes a thin strip on mobile where the person disappears. This is called art direction: you supply a cropped or entirely different image for narrow screens. Technically it is handled with the picture element or by setting a focal point in the CMS. For ordinary images in body text, supplying several sizes of the same image is enough, so phones never download a full desktop-sized file.
Does responsive design apply to newsletters and emails too?
Yes, and it is harder. Email clients support only part of the CSS browsers do, and Outlook on Windows is famously old-fashioned. So emails are usually built as a single column of around 600 pixels, with large buttons and text that is readable without zooming. Use your newsletter tool’s ready-made templates as a starting point, and always send a test to both a phone and a computer before a campaign goes out. Receipts and system emails from your platform need the same testing.

Want us to build it for you?

You get a fixed-price proposal within 24 hours.

Dennis Nielsen

Dennis Nielsen

Head of Operations, Ceptiv

Free consultation

One free hour of advice before you start.

Describe your project and I will contact you as soon as possible, so we can schedule a no-obligation meeting. You leave with practical advice on how to get your project off to a good start.

  • Free
  • 1 hour
  • No obligation