Common Web Page Layouts and When to Use Them

Choose a web page layout based on what readers need to do and how the content relates. A one-column layout suits linear reading and narrow screens. Use two columns when a genuinely useful secondary region, such as article navigation, can sit beside the main content. Three columns need both enough width and a clear reason for two secondary regions. Start with the narrow layout, then add columns where the content has room to breathe.

Most pages share a header, a main region, optional secondary content, and a footer. Give the main task the most space. Keep site-wide navigation in the header and less prominent shared information, such as legal links, in the footer. These regions are common page building blocks described by MDN’s CSS layout introduction.

1. Start with the content and the reader’s task

Before choosing a grid, list the page’s content and decide what the reader came to do. A long-form article asks for sustained, linear reading. A directory of products invites scanning and comparison. A dashboard may need several related information regions visible together. The layout should make those relationships clear and keep the primary task easy to find.

Use these questions to guide the choice:

Is the content meant to be read from beginning to end, or scanned as a set?
Does any secondary content help readers complete the primary task?
Will two regions need to be visible side by side for their meaning to be clear?
How much width does the main content need to stay comfortable and understandable?
Will the layout remain clear when the browser window is narrower than a full desktop display?

A useful rule is to make the primary content visually dominant. Do not add a sidebar or extra column just because there is unused space in a large mockup.

2. Choose one, two, or three columns

Pattern	Use it when	Watch for
One column	The page is a linear read, a focused form, or content for narrow screens.	On wide screens, constrain the text width so lines do not stretch across the entire window.
Two columns	A secondary region adds useful context, such as an article table of contents, related navigation, or supporting widgets.	Keep the main region dominant. The sidebar should not hold information readers need in order to understand the primary content.
Three columns	The page has two distinct secondary regions and enough available width for all three.	Columns can crowd the main content, especially in a browser window that is not maximized. Remove a column when it does not earn its space.

When should I use a one-column layout?

Use one column when readers should follow a straightforward sequence: articles, documentation, application forms, and focused landing pages often fit this pattern. It is also a strong narrow-screen presentation because it preserves a clear reading path without squeezing multiple regions beside one another.

On desktop, a single column does not mean full-width text. Set a readable measure and center the content within the available space. The appropriate width depends on the content, font, and design; check the rendered page rather than choosing a number based only on a device label.

When should I use a two-column layout?

Use two columns when a secondary region supports the primary one. An article may pair its main text with a table of contents or related links. A content listing may pair results with filters. The secondary region should add orientation or useful controls without competing with the main task.

On narrow viewports, stack the regions in a meaningful order. Keep the main content first when it is the page’s primary task, and ensure that moving the sidebar below it does not make essential controls hard to find.

When should I use three columns?

Use three columns only when the page has two useful secondary regions and enough room to display them without compressing the main content. A three-column layout is not automatically more informative. If one region is optional or duplicative, a two-column or one-column arrangement will usually make the content easier to follow.

Check the actual browser window, including sizes between a phone and a maximized desktop. A layout that fits a wide monitor can feel crowded in a resized desktop window.

3. Use cards and media objects for the right content relationships

Cards for groups readers scan

Cards work for related items that readers scan as a set, such as a collection of articles or products. Treat them as a list of items, not merely as decorative boxes. Make the relationship between each card’s title, description, image, and actions clear. Content can affect accessibility decisions, so choose markup and interaction patterns that preserve the meaning and order of each item. See MDN’s card layout recipe.

Media objects for an image paired with description

A media object places an image beside descriptive text, as in a social post. The image and text form one item, so the layout should communicate that connection and stack cleanly when space is limited. See MDN’s media object recipe.

CSS Grid and Flexbox both support common layout patterns. Choose based on the relationship you need to express: Grid is useful for arranging regions in rows and columns, while Flexbox is useful for arranging items along an axis. MDN’s layout cookbook provides recipes for common patterns.

4. Build responsive layouts from narrow to wide

Start with a narrow, single-column presentation. Add columns only when the content and available width support them. Responsive design can adapt to viewport width and other characteristics of the viewing environment; the breakpoint should be where the content stops fitting well, not a device category chosen in advance. See MDN’s guide to media queries.

This runnable example uses CSS Grid named areas. It starts with the article first and the sidebar below it, then puts the sidebar beside the article when the viewport is wide enough for the content. Adjust the breakpoint and widths based on how this page’s actual content behaves.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Responsive article layout</title>
  <style>
    * { box-sizing: border-box; }
    body {
      margin: 0;
      color: #202124;
      font: 1rem/1.6 system-ui, sans-serif;
    }
    .site-header, .site-footer {
      padding: 1rem;
      background: #f2f3f5;
    }
    .layout {
      display: grid;
      grid-template-areas:
        "main"
        "sidebar";
      gap: 2rem;
      margin-inline: auto;
      max-width: 72rem;
      padding: 1rem;
    }
    main { grid-area: main; min-width: 0; }
    aside { grid-area: sidebar; min-width: 0; }
    @media (min-width: 54rem) {
      .layout {
        grid-template-columns: minmax(0, 1fr) 16rem;
        grid-template-areas: "main sidebar";
        gap: 3rem;
      }
    }
  </style>
</head>
<body>
  <header class="site-header">Site header and navigation</header>
  <div class="layout">
    <main>
      <article>
        <h1>A page with a responsive layout</h1>
        <p>The main content comes first in the document and stays the primary region at every width.</p>
      </article>
    </main>
    <aside aria-label="Related navigation">
      <h2>On this page</h2>
      <nav><a href="#example">Example section</a></nav>
    </aside>
  </div>
  <footer class="site-footer">Contact and legal links</footer>
</body>
</html>

The source order keeps the main content before the sidebar on narrow screens and in the document structure. MDN’s Grid example likewise keeps source order aligned with the mobile presentation. Avoid changing the visual order in a way that disconnects it from the meaningful reading order. Grid named areas are documented in MDN’s guide to grid template areas.

5. Check reflow, reading order, and orientation

For reading content, aim for a layout that reflows to a single column at a 320 CSS-pixel viewport and needs only vertical scrolling. Side-by-side scrolling can still be useful when the meaning depends on comparison, such as code differences. See W3C’s guidance on reflow.

Keep the meaningful reading order understandable when columns stack.
Use semantic page regions and clear headings to expose the page structure.
Use breadcrumbs or other orientation cues where they help readers understand where they are.
Place recurring elements consistently so readers can find them across pages.
Check whether controls and links remain understandable when the layout changes.

W3C’s guidance on information and relationships, bypassing repeated blocks, and multiple ways to locate pages supports using structure and orientation cues that help readers navigate.

6. Compare layout options before committing

When evaluating real layouts, compare them against the task and the content rather than visual novelty. Ask:

Does the pattern support the reader’s primary task?
Does the main content retain enough space?
Does each secondary region provide a real benefit?
Does the page adapt to narrower widths without unnecessary horizontal scrolling?
Does the reading order remain understandable?
Is the pattern’s implementation complexity justified by its use?

If a simpler layout answers these questions as well, prefer it. A layout should clarify content relationships, not make readers work around them.

7. Inspect the layout at the widths that matter

Review the page at a narrow viewport, at the point where columns first appear, at a typical desktop window, and at a wider display. Also try a browser window that is not maximized. Look for text that becomes too wide, sidebars that squeeze the main task, cards that no longer scan as a group, and horizontal scrolling that serves no comparison purpose.

A screenshot can help compare the same page at chosen viewport sizes or inspect a particular region. For visual regression work, capture consistent states and viewport dimensions so changes are easier to spot.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. A GET request returns a PNG, JPEG, WebP, or PDF. The DIY browser setup is useful when you need full control; if you want a screenshot without configuring a browser, call the API. The ScreenshotNeo documentation describes the API options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

Troubleshooting layout problems

Symptom	Likely cause	What to change
The article feels hard to read on desktop.	The main text stretches across too much of the viewport.	Constrain and center the reading region; verify the result with the actual type and content.
The sidebar crowds the article.	The two-column layout activates before both regions have enough room.	Move the breakpoint to the width where the content fits comfortably, or keep one column longer.
A three-column page feels cramped in a desktop window.	The design was checked only at a wide, maximized viewport.	Test narrower desktop widths and remove or stack a secondary region earlier.
Readers encounter secondary content before the main task on mobile.	The source or visual order does not match the intended reading order.	Keep the meaningful content order clear in the document and stack regions accordingly.
The page scrolls sideways at narrow widths.	A column, long token, or fixed-width element exceeds the viewport.	Check intrinsic widths and fixed sizing; allow regions to shrink or stack. Preserve horizontal scrolling only where comparison requires it.
Cards look like a list but are confusing to navigate.	The markup or focus behavior does not communicate each item’s relationships.	Review the card structure, headings, links, and keyboard interaction; choose semantics based on the content.

Performance, reliability, and implementation cost

Layout choice affects more than appearance. Additional regions and interactions increase the amount of markup and styling to maintain, so add them only when they support the page’s task. Prefer a pattern the team can keep consistent across related pages. Grid and Flexbox are widely documented CSS layout tools; select the one whose behavior matches the relationship between items.

Responsive behavior depends on the actual content as well as viewport width. A breakpoint that works for one page can fail when titles, navigation, or card descriptions grow. Recheck after meaningful content changes and at intermediate widths. For screenshot-based review, capture the same URL at fixed viewport settings and compare the relevant page states; screenshots show visual output, so also inspect document order and keyboard behavior directly.

FAQ

No. A sidebar can be useful when its content is related and its structure and reading order remain clear. Check the stacked presentation and ensure the main task is not obscured by secondary material.

Should every page use the same layout?

Related pages benefit from consistent placement of recurring elements, but the content’s purpose should determine its specific layout. A reading page and a scannable directory may need different patterns.

Do I need to use CSS Grid for columns?

No. Grid and Flexbox both support common layout patterns. Pick the tool that expresses the relationship you need and behaves clearly at narrow and wide widths.

What should I test besides phone and desktop sizes?

Check intermediate browser widths and a 320 CSS-pixel viewport for reading content. Also inspect reading order, horizontal overflow, and whether secondary content remains useful when stacked.