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
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.
| Width | Typical devices | What typically changes |
|---|---|---|
| 320–479 px | Phones in portrait | One column, menu behind a button, stacked cards, full-width buttons |
| 480–767 px | Large phones, phones in landscape | Two cards side by side, larger images |
| 768–1023 px | Tablets in portrait | Two columns, possibly visible menu, tables can display as tables |
| 1024–1279 px | Tablets in landscape, small laptops | Full menu, three columns, sidebar on articles |
| 1280–1535 px | Laptops and standard monitors | Full layout, maximum content width is reached |
| 1536 px and up | Large monitors | Content 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.
Drag the window slowly
Narrow the browser window gradually from 1600 to 320 px. Problems usually appear between breakpoints.
Real devices
At least one iPhone, one older Android and one tablet. Test in portrait and landscape.
Zoom and large text
Zoom to 200 and 400 % on desktop and turn on larger text on the phone. Nothing may be cut off.
Slow connection
Throttle the network in developer tools and watch what appears first and what jumps.
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.
Measure after launch
Track Core Web Vitals in Search Console and conversion by device in your analytics.
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.
| Failure | Why it happens | Fix |
|---|---|---|
| Horizontal scroll on mobile | An element with a fixed width, such as a table, a video or a long word | Max width on media, hyphenation and tables as cards |
| Text that jumps while loading | Images and embeds without reserved space | Set width and height or aspect ratio on all media |
| Buttons that are hard to hit | Desktop sizes reused on mobile | At least 44 px touch area and spacing between links |
| Key information only on hover | Designed for a mouse | Show the information directly or on tap |
| Headings that fill the whole screen | Fixed font size carried over from desktop | Scaling typography with a minimum and maximum |
| Cookie banner covers the button | The banner was tested on its own, separately from the page | Compact banner at the bottom and testing of the whole flow |
| Slow mobile page | Desktop images, many scripts, heavy fonts | Responsive 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?
What is the difference between responsive and adaptive design?
Should we build an app instead of a responsive website?
Can we trust a WordPress theme that says it is “responsive”?
Do we need different images on mobile and desktop?
Does responsive design apply to newsletters and emails too?
Want us to build it for you?
You get a fixed-price proposal within 24 hours.
