How to Build a Responsive Site That Passes Screen Size Tests

Your site looks great on your laptop. Then you check it on your phone—horizontal scroll, tiny text, CTAs buried below the fold. The layout didn’t “almost” pass; it failed at the viewport that half your users have. The gap isn’t knowing that screen size matters; it’s how you prove your site actually passes at the widths that matter.

This post is a step-by-step audit: pick target viewports using real device data (e.g. our Compare Devices tool to see exact specs for a 390px iPhone vs a 1440px laptop), test at those widths with browser DevTools and real devices, then fix gaps with CSS media queries. You’ll get a clear process and complete code examples—no rehash of best practices, just the testing and implementation workflow.

What “Passes” Means (And Why It’s Not “Looks OK on My Device”)

“Passes” here means: at each target viewport width, your layout doesn’t break, key content is usable, and critical actions (nav, CTAs, forms) work. That implies:

• No horizontal scroll unless you intend it (e.g. a carousel).
• Text readable without zooming—font size and line length scale with viewport.
• Touch targets large enough on small screens; click targets still sensible on large ones.
• Above-the-fold content and primary CTAs visible without excessive scrolling on mobile.

Goals like readability and conversion (how screen size impacts UX) set the bar. Here we focus on defining targets, testing, and fixing so “passes” is something you can check off.

Screen Size Test Checklist (Use This First)

Copy or bookmark this checklist—run it at every target viewport (e.g. 390px, 768px, 1440px) before you ship and whenever you add a new page or component:

• No horizontal scroll (unless intentional, e.g. carousel).
• Nav visible and usable (hamburger on mobile, full bar on desktop).
• Primary CTA above the fold or one scroll away.
• Forms usable (inputs not cut off, submit button tappable).
• Images scale (no overflow; max-width: 100% or srcset/sizes).
• Text readable without zoom (min font size or clamp()).
• Touch targets (mobile): at least 44×44px for buttons and links.
• Performance: responsive image sources and lazy loading for below-the-fold content where possible.

Document the viewports you test and this list (e.g. “We test at 390, 768, 1440; checklist: …”). That becomes your screen size test for future changes.

Step 1: Pick Your Target Viewports (And Get Exact Numbers)

Don’t test every device. Pick a small set that spans the ranges your users actually use: a narrow mobile, a tablet-ish width, and a desktop. Typical choices:

• Mobile: 390px or 393px—iPhone 15/16 report 393px logical viewport width in CSS pixels; 390px is a common rounded test width. Pick one and use it consistently for breakpoints and DevTools.
• Tablet: 768px (iPad portrait) or 820px (iPad Air).
• Desktop: 1440px (common laptop) or 1920px (full HD monitor).

Where do those numbers come from? Real device viewport widths in CSS pixels—not physical resolution. Use a side-by-side device comparison (e.g. our Compare Devices page) to pick two or three devices and see exact viewport and resolution; use the viewport width as your breakpoint. That way your media queries match how users actually see your site.

Step 2: Run a Quick Visual Audit at Each Breakpoint

Once you have targets (e.g. 390px, 768px, 1440px), test your site at those widths:

1. Browser DevTools (see next section): Resize the viewport to 390px, 768px, 1440px. Scroll the full page. Note: broken layout, cut-off text, overlapping elements, CTAs below the fold.
2. Real device: If you can, open the site on a phone and a laptop. Compare with DevTools at 390px and 1440px—often you’ll spot touch vs mouse issues.
3. Checklist: For each width, tick: no horizontal scroll, nav usable, primary CTA visible, forms usable, images scale.

Treat this as a pass/fail list per viewport. If something fails, you fix it in the next step with CSS (and occasionally markup).

Using Browser DevTools for Responsive Testing

Most developers rely on built-in browser tools for responsive testing—no extra software needed.

• Chrome / Edge: Open DevTools (F12 or Cmd+Option+I), click the device toolbar icon (or Cmd+Shift+M) to toggle responsive mode. Choose a preset (e.g. iPhone 14 Pro, Pixel 7) or set custom dimensions (e.g. 390 × 844, 1440 × 900). Resize and reload to catch layout breaks.
• Firefox: Same idea—responsive design mode (Cmd+Option+M). Pick a device or enter width × height. Use the rulers to confirm your breakpoints.
• Safari: Develop → Enter Responsive Design Mode; set width/height and test.

Always test at your exact breakpoint widths (e.g. 390px, 768px, 1440px) and one step below (389px, 767px, 1439px) to catch edge cases. Throttle CPU or network in DevTools if you want to simulate slower devices—helps surface lazy-loading or layout-shift issues.

Step 3: Implement or Adjust Breakpoints With CSS Media Queries

Your audit will reveal where the layout fails. Fix those points with media queries keyed to the same widths you tested. Use three patterns:

• min-width (mobile-first): Base styles for mobile; add layout and spacing for tablet and desktop at 768px, 1440px, etc. Best for most responsive layouts.
• max-width: Cap content width on large screens (e.g. readable line length) or hide/show components below a certain width (e.g. hide sidebar under 768px).
• orientation: Adjust layout for tablet portrait vs landscape when the same width has very different height (e.g. orientation: portrait vs landscape).

Below: complete examples for each.

min-width (mobile-first)

/* Base: mobile (e.g. up to 767px) */
.container {
  padding: 0 1rem;
  max-width: 100%;
}

/* Tablet and up: 768px+ */
@media (min-width: 768px) {
  .container {
    padding: 0 1.5rem;
    max-width: 720px;
    margin: 0 auto;
  }
}

/* Desktop: 1440px+ */
@media (min-width: 1440px) {
  .container {
    max-width: 1200px;
    padding: 0 2rem;
  }
}

max-width (cap on large screens, or hide/show by width)

Use when you want to limit line length or container width on wide monitors, or show/hide components below a width:

.article {
  max-width: 65ch; /* readable line length */
}

@media (max-width: 767px) {
  .sidebar { display: none; }
}

orientation (tablet portrait vs landscape)

Useful when the same breakpoint (e.g. 768px) has very different usable height in portrait vs landscape:

@media (min-width: 768px) and (orientation: portrait) {
  .hero { min-height: 50vh; }
}

@media (min-width: 768px) and (orientation: landscape) {
  .hero { min-height: 70vh; }
}

Keep breakpoints in sync: Use the exact viewport widths from your device comparison (e.g. 390px, 768px, 1440px) so “test at X px” and “apply styles at X px” match. For typography, use clamp() so text scales between breakpoints without extra media queries:

body {
  font-size: clamp(1rem, 0.9rem + 0.25vw, 1.125rem);
}

Step 4: Test Again and Document Your “Pass” Criteria

After adding or tweaking media queries, re-run the same audit at 390px, 768px, and 1440px (or your set). Confirm:

• No unintended horizontal scroll.
• Nav and main CTAs work and are visible.
• Text is readable; images and containers scale.

Document the viewports and checks somewhere (e.g. “We test at 390, 768, 1440; checklist: …”). That becomes your screen size test for future changes—so you don’t regress when you add a new section or component.

Why Use Real Device Specs for Breakpoints?

Guessing “mobile is about 400px” is fuzzy. A viewport comparison with real device data shows you exact viewport widths in CSS pixels (viewport vs screen width). When you line up an iPhone 15 with a 13" MacBook or a 1440p laptop (e.g. on our Compare Devices page), you see the exact numbers—393px vs 1440px or 1280px. Use those as your breakpoint values so your CSS matches how the browser actually lays out the page on those devices. No more “why does it break at 385px?”—you’re testing at the widths your users have.

Common Audit Failures (And What to Fix)

Real failure patterns and fixes:

• Horizontal scroll at 390px: A 1200px-wide hero image or a fixed-width container (e.g. width: 1100px) on a 390px viewport forces horizontal scroll. Fix: max-width: 100% on images, box-sizing: border-box, and avoid fixed pixel widths on outer containers.
• Tiny text on mobile: Base styles only set font-size for desktop; at 390px body text drops to 12px and is unreadable. Fix: set a minimum font-size in the base style or use clamp(); avoid font-size that only scales up on desktop.
• CTA or nav hidden below the fold on mobile: Fixed 48px nav + 60px hero + 80px CTA = 188px before the CTA; on a 667px-tall viewport the CTA is visible, but on a 568px iPhone SE the primary action is buried. Fix: reduce top padding/margins, or make the header/nav sticky so the CTA stays reachable.
• Layout “jumps” between 767px and 768px: Your breakpoint might sit in a cramped zone. Slightly shift the breakpoint (e.g. 768px → 769px) or add a small range (e.g. @media (min-width: 768px) and (max-width: 769px)) to smooth the transition if needed—usually one breakpoint is enough.

Performance: Images and Lazy Loading

Responsive layouts aren’t just about width—they affect performance. Large images sized for desktop waste bandwidth on mobile and slow down LCP. Use responsive images: srcset and sizes (or a component that outputs them) so the browser picks the right asset for viewport and DPR. Add lazy loading (loading="lazy" or Intersection Observer) for below-the-fold images so initial load stays fast. Test with DevTools network throttling at your target widths to catch oversized assets.

Accessibility: Touch Targets, Contrast, and Screen Readers

Screen size tests should include accessibility at the same viewports:

• Touch target size: On mobile, buttons and tappable links should be at least 44×44px (WCAG 2.5.5). Test at 390px: small “x” or inline links often fail. Fix with padding or min-height/min-width.
• Contrast at different sizes: Text that passes contrast on desktop can fail on mobile in bright light or when font-size is reduced. Check contrast at 390px and 768px; ensure body and UI text meet 4.5:1 (or 3:1 for large text).
• Screen reader testing: Layout and focus order can change by viewport. Run VoiceOver (iOS/Mac) or TalkBack (Android) at your target widths—same checklist (nav, CTA, forms). Fix focus order and skip links so keyboard/screen reader users don’t hit dead ends on small screens.

Add these to your Screen Size Test Checklist near the top so accessibility is part of your definition of “passes.”

Troubleshooting: When the Audit Reveals Multiple or Conflicting Issues

If the audit shows several problems at once—horizontal scroll, CTA below the fold, tiny text—tackle them in order so fixes don’t conflict:

1. Fix horizontal scroll first. It blocks everything; a single fixed-width element can cause it. Add max-width: 100%, box-sizing: border-box, and remove fixed pixel widths on containers. Re-test at 390px before moving on.
2. Then CTA and nav visibility. Sticky header, reduced top padding, or moving the CTA above the fold. Re-test at the shortest height you care about (e.g. 568px).
3. Then typography and images. Font size, clamp(), and responsive images. Re-test at all widths.

If a change at one breakpoint breaks another (e.g. fixing mobile pushes desktop layout), fix one viewport at a time: get 390px passing, then 768px, then 1440px. Use version control or a branch so you can revert a media-query change that causes regressions. Document the order that worked so your team can repeat it.

Quick Reference

Use the Screen Size Test Checklist near the top of this post at every target width (390px, 768px, 1440px) before you ship and when you add new pages or components. That’s your repeatable screen size test.

Tying It Back to UX (Without Repeating It)

Screen size and UX set the goals: readable, navigable, conversion-friendly across devices. This post gives you the process: pick viewports from real device data (e.g. our Compare Devices page), audit at those widths with DevTools and real devices, fix with media queries (and responsive images where needed), then re-test and document. Do that, and you’re not just “doing responsive”—you’re building a responsive site that passes defined screen size tests.

For exact viewport and resolution numbers, use our Compare Devices page to line up an iPhone and a laptop; for a live readout of your current screen, use our screen size tool. Once your targets and checklist are in place, every new page or component can be checked against the same criteria—so your site stays responsive as it grows.