In May 2026, mobile accounted for 50.29% of global web traffic, desktop for 48.24%, and tablet for 1.48%. This means someone might open your website on a narrow mobile viewport, a tablet in portrait mode, or a desktop browser with much more space.
If you don’t plan your layout for these width changes, users can face broken navigation, clipped content, hard-to-use forms, hidden CTAs, and checkout or sign-up flows that are harder to complete.
This is where CSS media queries and breakpoints come in. A media query tells the browser when to apply specific styles based on conditions such as viewport width, height, orientation, or resolution. A breakpoint is the viewport width where the layout changes because the current design starts to break, crowd, wrap badly, or waste space.
In this guide, I’ll explain how to choose breakpoints, write media queries for mobile, tablet, and desktop, avoid overlapping CSS rules, and test the screen widths where responsive bugs usually appear.
Media Query vs Breakpoint
Media queries and breakpoints are often used together, but they are not the same thing.
A breakpoint is the viewport width where the layout needs to change. A media query is the CSS rule that applies styles when that breakpoint condition is met.
For example:
@media (min-width: 768px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
}
}Output –
The grid stays at 1 column below 768px and switches to 2 columns at 768px and above
In this example, 768px is the breakpoint. The full @media block is the media query. When the viewport is at least 768px wide, the browser applies the CSS inside the block.
| Term | What it means | Example |
|---|---|---|
| Media query | The CSS condition that controls when styles apply | @media (min-width: 768px) |
| Breakpoint | The width where the layout changes | 768px |
| CSS rule inside media query | The style applied when the condition is true | grid-template-columns: repeat(2, 1fr) |
A good breakpoint is not chosen only because a device exists at that width. It should be chosen because the layout needs it. For example, if a card grid becomes crowded below 768px, that is a good reason to switch from two columns to one column. If the navigation starts wrapping at 1024px, that is a good reason to adjust spacing, collapse the menu, or change the layout.
This distinction matters because many responsive issues come from treating breakpoints as fixed device labels. A width like 768px does not always mean “tablet.” It only means the viewport has reached that width. The same width can appear on tablets, resized desktop browsers, foldable devices, or browser windows with side panels open.
So, instead of thinking:
/* Tablet styles */
@media (min-width: 768px) {
...
}Think:
/* Styles for layouts that have enough space for two columns */
@media (min-width: 768px) {
...
}This keeps the CSS tied to the layout need, not to assumptions about a specific device.
Viewport Width vs Device Width
Most responsive CSS should be written for the viewport width, not the physical device width.
The viewport is the visible area available to the webpage inside the browser. On mobile, that usually means the width of the browser window after the browser has applied scaling rules. On desktop, it means the current browser window width, which can change when the user resizes the window, opens a side panel, or uses split-screen mode.
Device width is different. It refers to the physical screen width of the device. That may sound useful, but it is usually too rigid for responsive layout decisions. Modern devices vary by pixel density, browser UI behavior, zoom settings, orientation, and split-screen support. A layout issue is usually caused by the space available to the page, not by the device model.
For responsive design, this is usually the better approach:
@media (max-width: 767px) {
.navigation {
display: none;
}
}This checks the viewport width. If the visible browser area is 767px or smaller, the mobile style applies.
Avoid writing layout CSS like this unless there is a specific reason:
@media (min-device-width: 320px) and (max-device-width: 480px) {
.navigation {
display: none;
}
}This targets device width. It can miss real cases because the layout problem is not always tied to the physical device. A resized desktop browser, a foldable device, a tablet in split-screen mode, or a mobile browser with a different viewport can still need the same responsive styles.
| Factor | Viewport width | Device width | What matters in practice |
|---|---|---|---|
| What it measures | The visible layout area available to the webpage | The screen width of the physical device | Responsive CSS should react to the space the page actually has, not just the device model |
| Common media feature | width, min-width, max-width | device-width, min-device-width, max-device-width | Use viewport-based features for most responsive layouts |
| Best use case | Changing layout, spacing, grid columns, navigation, typography, and CTA placement | Rare device-specific cases where physical screen width is truly relevant | Most websites do not need device-width for layout decisions |
| Behavior on resized desktop browsers | Responds when the browser window is resized | Does not represent the resized browser window | Viewport width catches desktop split-screen and resized-window issues |
| Behavior on tablets and foldables | Responds to the available browser area, including portrait, landscape, and split-screen modes | Can stay tied to the physical screen even when usable area changes | Viewport width is safer for devices where usable space changes often |
| Impact of pixel density | Uses CSS pixels, so layout stays consistent across high-density and low-density screens | Can be confused with physical resolution if used incorrectly | Do not choose breakpoints based on hardware resolution |
| Testing approach | Test widths around breakpoints, such as 767px, 768px, and 769px | Test specific device models only when needed | Breakpoint-edge testing finds more layout bugs than testing one popular device |
| Recommended for responsive layouts | Yes | Usually no | Use min-width and max-width unless there is a specific device-capability reason |
A good rule is simple: use width, min-width, and max-width for responsive layouts. Use device-specific media features only when the styling truly depends on device capability, not when the layout only needs more or less space.
<meta name="viewport" content="width=device-width, initial-scale=1.0">
This helps mobile browsers use the device width as the layout viewport, so viewport-based media queries behave as expected.
Mobile-first vs Desktop-first Media Queries
Media queries can be written in two main ways: mobile-first or desktop-first. The difference is not only syntax. It affects how the CSS grows, how overrides are handled, and how easy the layout is to maintain as more screen sizes are added.
In a mobile-first approach, the base CSS is written for smaller screens. Styles for tablets and desktops are added later using min-width.
/* Base styles for mobile */
.product-grid {
display: grid;
grid-template-columns: 1fr;
gap: 16px;
}
/* Tablet and above */
@media (min-width: 768px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
}
}
/* Desktop and above */
@media (min-width: 1024px) {
.product-grid {
grid-template-columns: repeat(4, 1fr);
}
}Output: This mobile-first layout starts with 1 column, expands to 2 columns at 768px, and changes to 4 columns at 1024px and above.
This works well because the layout starts with the most constrained screen. You first solve the hardest space problem, then add more columns, spacing, and layout options as the viewport becomes wider.
In a desktop-first approach, the base CSS is written for larger screens. Styles for tablets and mobiles are added using max-width.
/* Base styles for desktop */
.product-grid {
display: grid;
grid-template-columns: repeat(4, 1fr);
gap: 24px;
}
/* Tablet and below */
@media (max-width: 1023px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
}
}
/* Mobile */
@media (max-width: 767px) {
.product-grid {
grid-template-columns: 1fr;
}
}Output –
In this desktop-first setup, a max-width override correctly falls back to 1 column on smaller screens.
This can work when an existing desktop site is being made responsive. It is also common in older codebases where the desktop layout was built first and mobile support was added later.
| Factor | Mobile-first | Desktop-first | Practical impact |
|---|---|---|---|
| Base CSS | Written for small screens | Written for large screens | Mobile-first starts with fewer layout assumptions |
| Media query type | Usually min-width | Usually max-width | The direction of overrides changes |
| CSS growth | Adds styles as space increases | Removes or overrides styles as space decreases | Mobile-first often leads to cleaner overrides |
| Best fit | New responsive builds, product pages, landing pages, dashboards with simple mobile views | Existing desktop-heavy sites, legacy layouts, complex desktop apps | Choose based on the codebase and primary layout problem |
| Risk | Desktop styles may be underplanned if not designed properly | Mobile CSS can become a patchwork of overrides | The weaker side needs deliberate testing |
| Testing focus | Check that larger layouts improve without breaking the base mobile layout | Check that smaller layouts do not inherit desktop-only assumptions | Both need breakpoint-edge testing |
Common Breakpoints for Mobile, Tablet, and Desktop
Breakpoints are useful only when they match how the layout changes. A breakpoint should not be added just because a device category exists. It should be added when content starts to feel crowded, navigation wraps, forms become hard to use, grids lose balance, or spacing becomes too wide.
For most responsive websites, teams start with a small set of common breakpoint ranges and then adjust them based on the actual design. This keeps the CSS easier to maintain and reduces the chance of conflicting rules.
| Layout range | Viewport width | Common media query |
|---|---|---|
| Mobile | Up to 767px | @media (max-width: 767px) |
| Tablet | 768px to 1023px | @media (min-width: 768px) and (max-width: 1023px) |
| Desktop | 1024px and above | @media (min-width: 1024px) |
| Large desktop | 1440px and above | @media (min-width: 1440px) |
In the next sections, this guide uses the same setup:
- Mobile: up to 767px
- Tablet: 768px to 1023px
- Desktop: 1024px and above
This keeps the examples consistent and easier to test.
Media Query for Mobile
In the breakpoint setup used in this guide, mobile styles apply up to 767px. If you are using a mobile-first approach, mobile is usually the base CSS and does not need its own media query. If you are working in a desktop-first codebase, you can use @media (max-width: 767px) for mobile-specific overrides.
Mobile layouts should focus on readability, touch interaction, visible CTAs, simple navigation, and forms that are easy to complete.
For most new responsive pages, write the default CSS for mobile first:
/* Base styles for mobile */
.page {
padding: 16px;
}
.header {
display: flex;
justify-content: space-between;
align-items: center;
}
.desktop-nav {
display: none;
}
.menu-button {
display: inline-flex;
}
.hero {
display: grid;
gap: 20px;
}
.hero-title {
font-size: 2rem;
line-height: 1.2;
}
.hero-cta {
width: 100%;
}
.form-group {
display: grid;
gap: 8px;
}
.form-input {
width: 100%;
}Output: This output confirms the mobile base layout defaults are applied consistently without breakpoint activation.
In this example, the mobile layout hides the desktop navigation, shows a menu button, keeps the hero section in one column, makes the CTA full width, and keeps form inputs easy to use.
If the project is desktop-first, use a mobile media query like this:
/* Mobile styles in a desktop-first codebase */
@media (max-width: 767px) {
.page {
padding: 16px;
}
.desktop-nav {
display: none;
}
.menu-button {
display: inline-flex;
}
.hero {
grid-template-columns: 1fr;
}
.hero-cta {
width: 100%;
}
}Output – The `max-width: 767px` override is active only on mobile widths and turns off from 768px onward.
Mobile media queries should solve actual usability problems, such as:
- Navigation taking too much space or wrapping across lines
- CTA buttons becoming hard to tap
- Cards feeling squeezed in narrow viewports
- Forms becoming difficult to read or complete
- Text wrapping badly across headings, labels, or buttons
- Images cropping important product, profile, or banner details
Avoid fixed widths like this:
.card {
width: 360px;
}
This can cause horizontal scrolling on smaller viewports. Use flexible sizing instead:
.card {
width: 100%;
max-width: 420px;
}Also avoid hiding important content only because the screen is small. If a section is important for conversion, account access, checkout, product comparison, or form completion, it should remain available on mobile. The layout can change, but the user should not lose access to critical actions.
Media Query for Tablet
In this setup, tablet styles apply from 768px to 1023px. This range is useful when the layout needs a middle state between the single-column mobile layout and the wider desktop layout.
Tablet layouts should not be treated as smaller desktop layouts. Tablets have more space than phones, but they still need touch-friendly spacing, readable content, and layouts that work in both portrait and landscape mode.
A tablet media query can be written like this:
@media (min-width: 768px) and (max-width: 1023px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
}
.filter-panel {
display: grid;
grid-template-columns: 1fr 1fr;
gap: 16px;
}
.hero-title {
font-size: 2.5rem;
}
}Output: Tablet-only styles are applied correctly in the 768–1023px range and remain inactive outside it.
In this example, the tablet layout uses two product columns instead of one. The filter panel also moves into two columns because the viewport has more horizontal space. The heading gets larger, but not as large as a desktop heading.
If the project follows a mobile-first approach, tablet styles can also be written as the first wider breakpoint:
/* Base mobile layout */
.product-grid {
display: grid;
grid-template-columns: 1fr;
gap: 16px;
}
/* Tablet and above */
@media (min-width: 768px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
gap: 24px;
}
}This works when the two-column tablet layout can continue into larger screens until another breakpoint changes it.
/* Desktop and above */
@media (min-width: 1024px) {
.product-grid {
grid-template-columns: repeat(4, 1fr);
}
}Tablet media queries are useful when the layout needs a separate middle state. Common tablet adjustments include:
- Moving from one column to two columns when the mobile layout feels stretched
- Keeping navigation compact when full desktop navigation does not fit cleanly
- Using collapsible filters or narrower sidebars when the main content needs more room
- Grouping related form fields into two columns when it improves scanning
- Adjusting image aspect ratio or object positioning in landscape mode
- Keeping enough spacing between buttons and links for touch input
Media Query for Desktop
In this setup, desktop styles start at 1024px. This is where many layouts have enough width for expanded navigation, sidebars, wider grids, and controlled page containers.
Desktop media queries should not make everything bigger by default. The goal is to use the extra space without making the page harder to scan.
A desktop media query can be written like this:
/* Desktop and above */
@media (min-width: 1024px) {
.page-shell {
max-width: 1120px;
margin: 0 auto;
padding: 32px;
}
.desktop-nav {
display: flex;
gap: 24px;
}
.menu-button {
display: none;
}
.content-layout {
display: grid;
grid-template-columns: 280px 1fr;
gap: 32px;
}
.product-grid {
grid-template-columns: repeat(4, 1fr);
}
}Output: At 1280px, the desktop media query is active, so the product grid changes to 4 columns.
In this example, the desktop layout limits the page width with max-width, centers the page with margin: 0 auto, shows full navigation, and adds a sidebar next to the main content. The product grid also moves to four columns because the viewport has enough space for each card to remain readable.
The max-width on .page-shell is important. Without it, content can stretch too far on large monitors. Long lines of text become harder to read, cards may look too wide, and important actions can feel disconnected from the rest of the layout.
For larger desktop screens, add another breakpoint only when the design needs it:
@media (min-width: 1440px) {
.page-shell {
max-width: 1280px;
}
.product-grid {
gap: 32px;
}
}Output: At 1500px, the large-desktop rule is active, so the page container can expand to 1280px and the product grid gap increases to 32px.
This breakpoint does not change the whole layout. It only adjusts the container and spacing for wider screens.
Desktop media queries are useful when the layout needs more structure, not just more size. Common desktop adjustments include:
- Showing full navigation instead of a compact menu button
- Adding max-width so content does not stretch too far on large screens
- Moving filters, summaries, or secondary content into a sidebar
- Increasing grid columns only when each card still has enough room
- Adjusting container width, grid gaps, and section spacing for wider screens
- Avoiding wide sidebars too early around 1024px to 1200px
How to Write Media Queries Without Overlap
Overlapping media queries happen when two or more rules apply to the same viewport width and change the same component in different ways. The browser will still apply the CSS based on the cascade, but the final result may not be what the developer expected.
For example, this looks harmless at first:
@media (max-width: 768px) {
.product-grid {
grid-template-columns: 1fr;
}
}
@media (min-width: 768px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
}
}The problem is 768px. At exactly 768px, both media queries are true. The browser then applies whichever matching rule wins in the cascade. If the second rule comes later, the grid becomes two columns. If the order changes later during refactoring, the layout may change without anyone noticing.
A cleaner version avoids the shared boundary:
@media (max-width: 767px) {
.product-grid {
grid-template-columns: 1fr;
}
}
@media (min-width: 768px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
}
}Now the rule is clear. Mobile styles apply up to 767px. Tablet and larger styles start at 768px.
For a full mobile, tablet, and desktop setup, the ranges can be written like this:
/* Mobile */
@media (max-width: 767px) {
.product-grid {
grid-template-columns: 1fr;
}
}
/* Tablet */
@media (min-width: 768px) and (max-width: 1023px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
}
}
/* Desktop */
@media (min-width: 1024px) {
.product-grid {
grid-template-columns: repeat(4, 1fr);
}
}Output –
Non-overlapping breakpoint ranges correctly separate mobile, tablet, and desktop behavior without conflicts.
This avoids overlap because each viewport width belongs to one clear range:
| Range | Media query | Layout applied |
|---|---|---|
| Up to 767px | @media (max-width: 767px) | Mobile layout |
| 768px to 1023px | @media (min-width: 768px) and (max-width: 1023px) | Tablet layout |
| 1024px and above | @media (min-width: 1024px) | Desktop layout |
If the project follows a mobile-first approach, the CSS can be even simpler because the mobile layout is the default:
/* Base mobile layout */
.product-grid {
grid-template-columns: 1fr;
}
/* Tablet and above */
@media (min-width: 768px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
}
}
/* Desktop and above */
@media (min-width: 1024px) {
.product-grid {
grid-template-columns: repeat(4, 1fr);
}
}Output: Layered mobile-first rules apply progressively, with larger breakpoints adding styles on top of the base layer.
In this pattern, overlap is not a problem because the rules are intentionally layered. At 1024px, both the 768px and 1024px media queries match, but the later desktop rule overrides the tablet rule. This is expected because the CSS is written from small to large.
Overlap becomes a problem when the same component is controlled by mixed directions without a clear cascade:
.card {
padding: 24px;
}
@media (max-width: 900px) {
.card {
padding: 20px;
}
}
@media (min-width: 768px) {
.card {
padding: 32px;
}
}Between 768px and 900px, both media queries match. The final padding depends on which rule comes later. This makes the code harder to debug because the breakpoint logic is not clear.
A safer version uses one direction:
.card {
padding: 16px;
}
@media (min-width: 768px) {
.card {
padding: 24px;
}
}
@media (min-width: 1024px) {
.card {
padding: 32px;
}
}Modern CSS also supports range syntax, which can make breakpoint boundaries easier to read:
@media (width < 768px) {
.product-grid {
grid-template-columns: 1fr;
}
}
@media (768px <= width < 1024px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
}
}
@media (width >= 1024px) {
.product-grid {
grid-template-columns: repeat(4, 1fr);
}
}This syntax makes the boundaries explicit. Mobile applies below 768px, tablet applies from 768px up to but not including 1024px, and desktop applies from 1024px upward.
For most teams, either syntax is fine. The important part is to avoid unclear breakpoint logic. Choose one approach, keep the ranges consistent, and test the exact edges.
For example, if the layout changes at 768px and 1024px, test these widths:
| Breakpoint | Test below | Test at | Test above |
|---|---|---|---|
| 768px | 767px | 768px | 769px |
| 1024px | 1023px | 1024px | 1025px |
This catches the bugs that usually appear when one layout ends and another begins. It also confirms that no width is accidentally using the wrong layout because of overlapping or missing media query conditions.
Complete Example: Responsive Card Grid using Media Queries
A full example makes media queries easier to understand because it shows how the same component changes across mobile, tablet, and desktop viewports.
In this example, the layout starts with one column for mobile, changes to two columns on tablet, and moves to four columns on desktop. The breakpoints are based on available layout space, not on specific device models.
HTML
<section class="products" aria-labelledby="products-title">
<div class="products-header">
<h2 id="products-title">Featured Products</h2>
<p>Compare popular products and choose the one that fits your workflow.</p>
</div>
<div class="product-grid">
<article class="product-card">
<img src="product-1.jpg" alt="Dashboard view of Product 1">
<h3>Product 1</h3>
<p>Best suited for small teams that need simple reporting.</p>
<a href="#" class="product-cta">View details</a>
</article>
<article class="product-card">
<img src="product-2.jpg" alt="Dashboard view of Product 2">
<h3>Product 2</h3>
<p>Useful for teams that need stronger collaboration controls.</p>
<a href="#" class="product-cta">View details</a>
</article>
<article class="product-card">
<img src="product-3.jpg" alt="Dashboard view of Product 3">
<h3>Product 3</h3>
<p>Built for projects that need more customization options.</p>
<a href="#" class="product-cta">View details</a>
</article>
<article class="product-card">
<img src="product-4.jpg" alt="Dashboard view of Product 4">
<h3>Product 4</h3>
<p>Designed for larger teams with advanced workflow needs.</p>
<a href="#" class="product-cta">View details</a>
</article>
</div>
</section>
CSS
/* Base mobile layout */
.products {
padding: 16px;
}
.products-header {
max-width: 640px;
margin-bottom: 24px;
}
.products-header h2 {
margin: 0 0 8px;
font-size: 1.75rem;
line-height: 1.2;
}
.products-header p {
margin: 0;
line-height: 1.6;
}
.product-grid {
display: grid;
grid-template-columns: 1fr;
gap: 16px;
}
.product-card {
display: grid;
gap: 12px;
padding: 16px;
border: 1px solid #ddd;
border-radius: 12px;
}
.product-card img {
width: 100%;
height: auto;
border-radius: 8px;
}
.product-card h3 {
margin: 0;
font-size: 1.125rem;
}
.product-card p {
margin: 0;
line-height: 1.5;
}
.product-cta {
display: inline-flex;
justify-content: center;
align-items: center;
min-height: 44px;
padding: 10px 16px;
text-decoration: none;
}
/* Tablet and above */
@media (min-width: 768px) {
.products {
padding: 24px;
}
.product-grid {
grid-template-columns: repeat(2, 1fr);
gap: 24px;
}
.products-header h2 {
font-size: 2rem;
}
}
/* Desktop and above */
@media (min-width: 1024px) {
.products {
max-width: 1120px;
margin: 0 auto;
padding: 32px;
}
.product-grid {
grid-template-columns: repeat(4, 1fr);
}
.product-cta {
justify-content: flex-start;
}
}How this example works
The base CSS is written for mobile first. This means the page works on small screens before any media query is applied. The product grid uses one column, the cards take the full available width, and the CTA has a minimum height that works better for touch interaction.
At 768px, the media query changes the grid to two columns. This is suitable when the viewport has enough space for two cards to sit side by side without making the text cramped.
At 1024px, the grid changes to four columns and the section gets a max-width. The max-width keeps the layout controlled on the desktop so the cards do not stretch across the entire screen.
How to Test Media Queries Across Devices
Testing media queries is not about checking one mobile screen and one desktop screen. The main goal is to confirm that the layout changes correctly at each breakpoint and still works on real devices.
Step 1: List the breakpoints used in the CSS
Start by checking the actual breakpoints in the stylesheet. For example, this CSS has two main layout breakpoints:
@media (min-width: 768px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
}
}
@media (min-width: 1024px) {
.product-grid {
grid-template-columns: repeat(4, 1fr);
}
}This means the layout should change at 768px and 1024px.
Step 2: Test one pixel below, at, and above each breakpoint
For every breakpoint, test three widths:
- One pixel below the breakpoint
- The exact breakpoint
- One pixel above the breakpoint
For the example above, test:
- 767px, 768px, and 769px
- 1023px, 1024px, and 1025px
At 767px, the product grid should still be in one column. At 768px, it should change to two columns. At 1024px, it should change to four columns.
This step catches the most common media query issues, including overlapping rules, missing ranges, and styles being applied one pixel too early or too late.
Step 3: Resize the viewport manually
After testing the exact breakpoint edges, slowly resize the browser from a small width to a large width. Do not rely only on preset device sizes.
Manual resizing helps find awkward widths between breakpoints. For example, the grid may work at 768px and 1024px, but the navigation may wrap at 910px, or a CTA may start overlapping at 860px.
When resizing, watch for:
- Horizontal scroll
- Navigation wrapping
- Cards becoming too narrow
- Text clipping
- CTA buttons moving too far down
- Images cropping important content
- Forms becoming hard to read or use
Step 4: Check common viewport widths
Next, test common viewport widths across mobile, tablet, and desktop. For example:
- 360px
- 390px
- 430px
- 768px
- 1024px
- 1280px
- 1440px
These widths are not a replacement for breakpoint-edge testing. They are useful because they cover common screen ranges where users are likely to open the page.
Step 5: Test portrait and landscape views
Mobile and tablet layouts should be checked in both portrait and landscape orientation.
A layout that works in portrait can still fail in landscape. For example, the viewport height may become smaller, the hero section may take too much space, a sticky header may cover content, or a form may become harder to complete.
This is especially important for:
- Navigation menus
- Hero sections
- Product image galleries
- Forms
- Checkout pages
- Dashboards
- Modals and popups
Step 6: Test important flows on real devices
Chrome DevTools is useful for the first pass because it lets you enter custom viewport widths and inspect which media queries are active. But it should not be the final test.
DevTools simulates the viewport inside a desktop browser. It does not fully reproduce real mobile browser behavior, touch input, address bar behavior, device pixel ratio, mobile rendering differences, or performance constraints.
After DevTools testing, check important flows on real mobile and tablet browsers. Prioritize pages where responsive issues can affect user actions, such as:
- Sign-up
- Login
- Checkout
- Pricing
- Product listing
- Product detail
- Forms
- Dashboards
- Navigation-heavy pages
Step 7: Test with real content and edge cases
Do not test only with short placeholder text. Responsive layouts often pass with clean demo content and fail with real content.
For example, a card title like this may fit easily:
Product 1
But a real title may wrap badly or break the card layout:
Enterprise Automation Dashboard with Advanced Reporting
Also test:
- Long headings
- Long button labels
- Form error messages
- Empty states
- Loading states
- Discount banners
- Translated text
- Long product names
- Long navigation labels
Step 8: Confirm the final responsive behavior
Before signing off, confirm that the layout passes the main responsive checks:
- The correct layout appears below, at, and above every breakpoint.
- Navigation works on mobile, tablet, and desktop.
- CTAs remain visible and easy to use.
- Forms remain readable and tappable.
- Text does not clip, overlap, or create horizontal scroll.
- Images scale without hiding important content.
- Portrait and landscape views both work.
- Key flows work on real devices, not only in desktop simulation.
Responsive testing is complete only when the layout works across breakpoint edges, real content, real devices, and the user flows that matter most.
Common Media Query Mistakes
Media query issues usually come from unclear breakpoint logic, rigid layout CSS, or testing only a few screen sizes. The syntax may be correct, but the layout can still fail if the breakpoint does not match the actual design problem.
Common mistakes to avoid include:
- Using device width for layout CSS: Avoid device-width, min-device-width, and max-device-width for normal responsive layouts. These target the physical device width, while layout issues usually depend on available viewport space.
- Adding breakpoints for every popular device: Do not create separate rules for every phone width such as 375px, 390px, 414px, and 430px. This makes CSS harder to maintain and still misses layout issues caused by real content, browser settings, or resized windows.
- Creating overlapping breakpoint ranges: Avoid ranges where two rules apply at the same width unless the cascade is intentional. For example, using max-width: 768px and min-width: 768px means both rules match at exactly 768px.
- Fixing every issue with another media query: Not every responsive issue needs a new breakpoint. Many problems can be solved with flexible widths, controlled maximum widths, fluid grids, wrapping layouts, and scalable typography.
- Hiding important content on mobile: It is fine to hide decorative or duplicate content, but avoid hiding CTAs, checkout summaries, filters, helper text, or information users need to complete a task.
- Treating tablet as one fixed width: Tablet layouts can vary widely across portrait, landscape, split-screen, and foldable views. Test the available viewport space instead of assuming one tablet breakpoint covers all cases.
- Testing only preset device sizes: Device presets are useful, but they do not catch every layout issue. Resize the viewport manually and test one pixel below, at, and above each breakpoint.
Media Queries vs Container Queries
Media queries and container queries are both used for responsive design, but they respond to different things.
A media query responds to the viewport. It is useful when the page layout needs to change based on the browser width, height, orientation, or resolution.
A container query responds to the size of a parent container. It is useful when a reusable component needs to change based on the space available inside its own section.
| Factor | Media queries | Container queries |
|---|---|---|
| Responds to | Viewport size or device/browser conditions | Size of the component’s parent container |
| Best for | Page layout, navigation, main grids, section spacing | Cards, panels, widgets, filters, reusable components |
| Common use case | Change from mobile layout to tablet or desktop layout | Change a card layout when its container becomes wide enough |
| Main benefit | Good for controlling the overall page structure | Good for components used in different layout areas |
| Example problem | The full product grid needs two columns at 768px | A product card needs to stay stacked in a sidebar but become horizontal in a wider panel |
Use media queries when the whole page layout needs to respond to the viewport:
@media (min-width: 768px) {
.product-grid {
grid-template-columns: repeat(2, 1fr);
}
}Use container queries when a component needs to respond to the space inside its parent:
.card-wrapper {
container-type: inline-size;
}
@container (min-width: 500px) {
.product-card {
display: grid;
grid-template-columns: 160px 1fr;
gap: 16px;
}
}In this example, the card changes only when .card-wrapper is at least 500px wide. It does not depend on the full browser width.
A good rule is simple: use media queries for page-level changes and container queries for component-level changes. In a responsive design system, both can work together. Media queries can control the main layout, while container queries can help cards, panels, filters, and widgets adapt inside that layout.
Best Practices for Writing Media Queries
Media queries are easier to maintain when they are tied to layout behavior, not device names. Before adding a media query, check what problem it solves: readability, spacing, navigation, form usability, grid layout, or CTA visibility.
Follow these best practices when writing media queries:
- Start with the smallest useful layout: For most new responsive pages, write the base CSS for mobile first. This keeps the default layout simple and avoids undoing desktop styles later.
- Add breakpoints only when the layout needs them: Do not add a breakpoint just because a device category exists. Add one when navigation wraps, cards become too narrow, forms become hard to use, CTAs lose visibility, or spacing becomes too tight or too wide.
- Keep breakpoint logic consistent: Use one direction for each component. If a component is written mobile-first, keep using min-width for that component. Avoid mixing min-width and max-width unless there is a clear reason.
- Use flexible CSS before adding more media queries: Many responsive issues can be solved with flexible layout techniques such as fluid grids, percentage-based widths, flexible containers, controlled maximum widths, and fluid typography. Add a media query only when the layout still needs a clear change at a specific width.
- Avoid device-specific CSS: Do not write rules for one exact phone, tablet, or laptop width unless there is a rare, proven need. The layout should respond to available viewport space, not to a specific device model.
- Test breakpoint edges: If a layout changes at 768px, test 767px, 768px, and 769px. If it changes at 1024px, test 1023px, 1024px, and 1025px. This catches boundary issues early.
Conclusion
Media queries and breakpoints help keep a website readable, usable, and stable across mobile, tablet, and desktop viewports. The key is to treat breakpoints as layout decisions, not device labels.
Use viewport-based queries such as min-width and max-width, and avoid device-width for normal responsive CSS. Keep breakpoint ranges clear, follow one consistent direction, and use flexible CSS before adding more media queries.
Testing should cover one pixel below, at, and above every breakpoint. It should also include real content, real devices, portrait and landscape views, and key flows such as sign-up, checkout, forms, navigation, and dashboards.
