Responsive Website Design: A Guide to Fitting Every Screen Size

The exact same website looks different to every visitor. One opens it on a 27-inch monitor, another on a phone held in one hand at a bus stop, a third on a tablet turned sideways. The code is identical, but what ends up on screen is completely different — and managing that is exactly what a responsive website is for.

The problem is that most site owners find this out late. The site gets built and signed off on the designer's desktop monitor, it looks great in the presentation, and then the complaints start: the button is cut off on mobile, the table spills off the screen, the menu covers the form. Leads don't drop off because of the content — they drop off because the layout wasn't adapted to the device.

In this guide we'll cover everything you need to know to make your site genuinely work on every screen:

• what a responsive website is and how it differs from a separate mobile version;
• what happens under the hood: the viewport meta tag, media queries and fluid units;
• how to choose breakpoints and how they work in Webflow and WordPress;
• how to handle images, video and typography;
• what's different for multilingual and right-to-left sites: RTL and accessibility;
• a step-by-step plan for adapting an existing site, testing and common mistakes.

What a responsive website is and how it differs from a mobile version

A responsive website is a single site, with one URL and one set of content, whose layout rearranges itself based on the width of the window it's opened in. Three columns on a wide screen become one column on a phone, a horizontal menu collapses into a button, text resizes and spacing tightens. Nothing gets removed — it just arranges itself differently.

This approach replaced two older ones. The first is a separate mobile site, usually on a subdomain like m.example.com: two sites, two content systems, two places to maintain, and every bug fixed twice. The second is a fixed-width site that simply shrinks, so the user gets a scaled-down page and has to pinch-zoom to read it.

Today nearly every new project is built responsive, and there's an SEO reason too: Google indexes sites based on the version a mobile user sees. In other words, the mobile version of your site is the one that gets crawled and ranked — not the desktop version. If half the content is hidden or loads slowly on mobile, that's what Google sees.

There's one more term people confuse it with: adaptive design. An adaptive site prepares several fixed layouts and serves the one that fits the user, whereas a responsive layout is fluid and changes continuously. In practice, most modern sites are hybrids: a few defined breakpoints, with a fluid layout in between.

Why responsiveness directly affects leads

Fitting the screen isn't an aesthetic issue. It affects three things you can measure.

Conversions. A contact form you have to zoom in to fill out, a button that falls below the fold, a field hidden by the keyboard — each one costs you a share of the users who made it that far. It's worth checking your conversion rate in Google Analytics 4 separately for mobile and desktop; the gap between the two is usually the most honest indicator of where you stand.

Organic search. Beyond mobile-first indexing, Google's user experience metrics (Core Web Vitals) are measured mainly under mobile conditions: how fast the largest element on the page loads (LCP), visual stability (CLS) and responsiveness to interaction (INP). A poorly adapted layout hurts all of them — desktop-sized images slow down loading, and elements that jump around after load break stability.

Media costs. When you pay per click on Meta or Google Ads campaigns, most of the traffic comes from mobile devices. A landing page that doesn't work well on a phone burns ad budget, even if the creative is excellent. We cover this principle in more depth in our guide to designing a landing page that sells.

What happens under the hood

Even if you don't write code yourself, it's worth knowing the three mechanisms every screen adaptation relies on. They explain why some things are easy and others are expensive.

The viewport meta tag

It's a single line in the page head, and it's essential. Without it, a mobile browser assumes the page was built for a desktop screen, renders it at a large virtual width and then scales everything down. The result: tiny text, buttons you can't tap, and a user zooming in by hand. The meta tag tells the browser to use the device's actual width, and every other rule only starts working after that.

On platforms like Webflow, Wix or WordPress this tag is there by default. It tends to break on older sites that have been migrated, which is why it's the first thing to check when a site "just isn't responding" on mobile.

Media queries

A media query is a condition you attach a set of styles to: if the window width is below a certain value, apply these rules. Here's the line that triggers mobile styles: a max-width of 767 pixels. You can also set a range on both sides and define styles that apply only between 768 and 991 pixels — in other words, tablet only.

Conditions aren't limited to width. You can also target window height, aspect ratio, device orientation (portrait or landscape), screen pixel density, and even whether the user has a mouse at all or is using a finger. Two conditions that are especially useful in practice are prefers-reduced-motion, which lets you turn off animations for people who've set motion sensitivity in their operating system, and prefers-color-scheme, which detects dark mode.

You can chain conditions with "and", "or" and "not" — for example, styles that apply only on wide screens with a mouse. In practice, most brochure and e-commerce projects do fine with width and orientation alone; the other conditions come into play on specialized projects.

Fluid units and container queries

Media queries alone produce stepped design: one size up to a certain width, then a jump to another size above it. To get a smooth transition, you use relative units — percentages, rem, viewport units like vw — and the clamp function, which sets a minimum value, a preferred value that grows with screen width, and a maximum value. That way a heading scales gradually between phone and wide screen, without two sharp jumps in the middle.

Height units have a well-known gotcha on phones: the browser's address bar disappears and reappears as you scroll, so the old "100% of screen height" used to jump. The newer units — svh, lvh and dvh — solve exactly that, and they're supported in all modern browsers.

The most significant addition in recent years is container queries: instead of asking how wide the screen is, a component asks how wide its parent is. A product card in a wide grid shows the image and description side by side, and the exact same card inside a narrow sidebar switches to a vertical layout — without writing a separate rule for each screen. It's supported in all modern browsers and saves a lot of maintenance in systems where components are reused in different contexts.

Breakpoints: how to choose them well

A breakpoint is the width at which the layout changes structure. The common mistake is choosing them based on a list of popular devices. That list changes every year, and the numbers go stale.

The approach that holds up over time is to choose breakpoints based on content: slowly resize the window and watch where the layout starts to look bad — a line of text that's too long, cards that are too narrow, a cramped menu. That's exactly where you place a breakpoint. You usually end up with three or four, and that's enough.

The second principle is mobile-first: design the narrow version first and only then add layers for wider screens. It forces you to make content decisions early — what really has to be above the fold, and what can go. Incidentally, that's also why layout planning should start at the design stage rather than in development; our guide to working in Figma explains how to set this up in your files.

How it works in Webflow

In Webflow you don't write media queries by hand. There are built-in breakpoints: a base desktop view, 1280, 1440 and 1920 pixels above it, and below it tablet up to 991, mobile landscape up to 767 and mobile portrait up to 478 pixels. The key rule is the direction of inheritance: styles set on the base breakpoint cascade automatically to every smaller one, and a change made on tablet also affects mobile — but not the other way around.

That dictates the workflow: define as much as possible on the base breakpoint, and on each smaller breakpoint fix only what genuinely has to change. Sites built the other way round — with one-off fixes on every screen — turn into a maintenance nightmare within six months. If you work with the Client-First methodology, these rules are already built into the class names. We go into more detail on working with the platform on our Webflow services page.

How it works in WordPress and Elementor

Elementor defaults to two breakpoints: mobile up to 767 pixels and tablet up to 1024. You can add more — mobile extra, tablet extra, laptop and widescreen — but every breakpoint you add is one more version to maintain and test, so only add one when the content really needs it.

The fundamental difference from Webflow is that in a WordPress site the layout comes from three layers: the theme, the page builder and the plugins. A plugin that injects its own CSS can break the layout on just one screen size, so on WordPress sites it's worth checking every breakpoint after every significant update. You'll find more on how we work on our WordPress services page.

Images, video and typography

The layout is only half the job. The other half is what fills it.

Images. The same 2400-pixel-wide file that serves a wide screen is pure waste on a phone: it downloads unnecessary megabytes over a mobile network and directly hurts your loading metric. The solution is to serve several versions of the same image and let the browser choose based on screen width and pixel density. Most modern platforms do this automatically — Webflow, for example, generates resized versions on its own. On top of that, use the WebP format, compress before uploading and enable lazy loading for every image below the fold.

There's another, subtler case: sometimes shrinking an image isn't enough and you need to swap it out. A horizontal hero image with the product off to one side will look like a thin strip on a phone where you can't see anything. In that case, set up a separate vertical crop for the mobile version.

Video. Autoplay background video is one of the heaviest elements on home pages, and on mobile it's usually unnecessary: the user scrolls fast, and the device pays in battery and data. The standard practice is to replace it with a still image below a certain width.

Typography. On a phone, a reasonable body text size starts at around 16 pixels; anything smaller is hard to read, and in some browsers it triggers automatic zoom on form fields. A comfortable line length is roughly 50 to 75 characters, so on wide screens you should cap the width of text blocks instead of stretching them edge to edge. Headings are where clamp shines: instead of three separate size settings, one setting that moves between a minimum and a maximum.

Touch targets. A button that works for a mouse doesn't necessarily work for a finger. The common recommendation is a touch target of at least about 44 pixels in each direction, with spacing between adjacent tappable elements. That's especially true for menus, social media icons and "remove item" buttons in a shopping cart.

Multilingual sites, RTL and accessibility: what needs extra care

A multilingual site — especially one that includes right-to-left languages such as Arabic or Hebrew — adds a layer that doesn't exist in a single-language project, and it tends to break on small screens in particular.

Text direction and switching languages

Right-to-left direction affects far more than text alignment: the position of an icon relative to its button, the direction of carousel arrows, which side the hamburger menu opens from, the column order in a table and the side a filter drawer slides in from. To avoid writing every rule twice, it's better to use CSS logical properties — ones that talk about "start" and "end" instead of "left" and "right". Then switching language flips the layout by itself.

A classic trap is mixed content: phone numbers, email addresses, Latin brand names and prices inside a right-to-left sentence. Because of the bidirectional text algorithm, punctuation at the end of a mixed sentence sometimes jumps to the wrong side. It seems trivial until it happens in the main headline of your home page on mobile.

Another practical point: translations vary in length. German or Russian copy is usually longer than the English original, while some languages come out noticeably shorter. If your site is multilingual, the exact same layout can look sparse in one version and cramped in another — it's worth checking each language separately at every breakpoint.

Accessibility under WCAG

The international accessibility guidelines, WCAG — which also underpin regulations such as the European Accessibility Act — include several requirements that directly affect layout. The most prominent is text resizing: users must be able to enlarge text significantly without content being clipped or disappearing. A site built with fixed pixel heights fails right there — the text grows, the container doesn't, and the last sentence vanishes.

Other layout-related requirements: visible keyboard focus when navigating with Tab, sufficient contrast between text and background in every version (including dark mode, if you have one), and a logical reading order — because the order of elements in the code is what a screen reader reads out, even if you've visually rearranged them on mobile.

A step-by-step plan for adapting an existing site

If you have a site that doesn't work well on certain screens, this is the order that saves most of the pain.

• Step one — measure before you fix. Open the device breakdown in Google Analytics 4 and compare conversion rate, engagement time and bounce rate between mobile and desktop. This tells you whether you need a targeted fix or a major project.
• Step two — list your critical pages. Usually that's the home page, your main service page, product page, contact page and checkout. Don't try to fix the whole site at once.
• Step three — check the basics. A viewport meta tag, unwanted horizontal scrolling, and fixed-pixel-width elements wider than a phone screen — these three explain a large share of issues.
• Step four — go through the breakpoints. At each one, check the menu, main headline, forms, tables and cards.
• Step five — deal with media. Heavy images, background video and slow-loading fonts — this is where you gain the most speed in the least time.
• Step six — test forms on a real phone. The right keyboard type for each field, where error messages appear, and a submit button that isn't hidden behind the keyboard.
• Step seven — measure again after two weeks. The same metrics as in step one, so you know whether the fix worked.

It's also worth stating the flip side: sometimes adapting isn't worth it. If the site is built on an old, unsupported template, layers of fixes will cost more than a rebuild — and then it's better to redesign. If you're facing that dilemma, the answer usually comes from a half-day audit, not a guess.

How to test, and which mistakes come up most often

Testing tools

Device mode in Chrome DevTools is the everyday tool: it lets you drag the window width continuously and see exactly where the layout breaks — a better test than picking a device model from the list. Performance and user experience metrics are checked in Google's PageSpeed Insights, which shows separate results for mobile and desktop. For testing real browsers and devices, use cloud services like BrowserStack.

Even so, no tool replaces opening the site on a real phone, one-handed, outdoors, in daylight. Half the problems you find that way never show up in any emulator.

Eight common mistakes

• Horizontal scrolling. The usual culprits are a single element that's too wide, an image with no max-width or a negative margin. On a phone, it makes the whole page "shift" sideways.
• Content hidden on mobile. Hiding entire blocks to "clean up" mobile hurts both the user and your rankings, because that's the version that gets crawled.
• Wide tables. A six-column pricing table won't shrink by magic. Either turn it into a list of cards or allow horizontal scrolling inside the table only.
• Fixed heights. A block with a fixed pixel height gets clipped as soon as the text gets longer — when translated into another language or when text is enlarged.
• A broken menu. A hamburger menu that opens underneath other content, or doesn't close after a tap, is an especially common bug on WordPress sites with several plugins.
• Call to action below the fold. Phone screens are short; a button that's immediately visible on desktop may take two scrolls to reach.
• Heavy media. Background video and uncompressed image carousels are the most common reason for a slow page on mobile.
• Testing in only one browser. Safari on iPhone behaves differently from Chrome on Android, especially with heights, fonts and the video player.

Once all of that is in order, it's worth going back to the content side too — especially if you want your site to show up in answers from AI-powered search engines. We wrote about that separately in our guide to optimizing for AI search.

How RJL Studio makes a site truly responsive

We treat screen adaptation as part of the build, not a stage that comes at the end. On a new project, the layout is planned upfront for every breakpoint, and the build in Webflow or WordPress follows a structured class system — so future changes don't require fixing every screen separately.

On an existing site we start with a diagnosis: going through the critical pages at every breakpoint, testing mobile performance, checking RTL and accessibility, and producing a list of findings ranked by business impact versus effort. That list leads to one of two paths — a targeted fix for whatever is blocking conversions, or a redesign if the foundation can no longer hold. We'll tell you honestly which one you're on, even when the answer is that you don't need us for a big project.

Beyond development, we handle UX and UI design, performance and post-launch SEO, so screen adaptation doesn't stay a one-off fix.

Want to know how your site actually behaves on every screen? Talk to us — we'll go through your key pages and come back with findings and an action plan.

Frequently asked questions

How many breakpoints does a typical business website need?

For most brochure and e-commerce sites, three or four are enough: mobile, tablet, desktop and sometimes widescreen. It's better to choose them based on where your content starts to look bad than on a list of device models — devices change, your content stays. Every extra breakpoint is one more version to test with every update.

Is a responsive website enough, or do I also need an app?

For most small and mid-sized businesses, a responsive site fully covers the need: it appears in search results, requires no installation and is updated in one place. An app justifies itself when there's frequent repeat use, a need for push notifications or access to device hardware. A middle ground is a site that installs to the home screen like an app (PWA).

My site is built on an old template. Should I fix it or rebuild?

It depends on two questions: is the platform still supported and updated, and how many pages actually need work. If it's a handful of pages and the template is maintained, a targeted fix will be cheaper and faster. If the template no longer gets updates, or every fix breaks something else, a rebuild is usually cheaper in the long run — and solves performance and accessibility along the way.

What's the difference between responsive and adaptive design?

In responsive design the layout is fluid and changes continuously with the window width; in adaptive design several fixed layouts are prepared in advance and the system serves the right one. In practice, most modern sites combine the two: defined breakpoints with a fluid layout in between. Users can't tell the difference — it's in how the site is maintained.

How can I quickly check whether my site is mobile-friendly?

Open your site on a phone and complete your most important action from start to finish — filling out a form, placing an order or making a call. Then run the page through PageSpeed Insights and check the mobile results. Those two things, together with comparing mobile and desktop conversion rates in Google Analytics, give you an accurate picture in under an hour.