# Header Sizes: How Big Should a Website Header Be?

> Header dimensions with numbers instead of gut feeling: device and resolution data for Germany vs. worldwide, CSS pixels vs. 4K, breakpoints, size tables, accessibility limits and conversion evidence.

Source: https://www.jpkc.com/db/en/blog/header-groessen/

It is the question I am asked most often in consulting — and the topic on which I have to reject the most drafts: **how big may a header be?** How tall, how wide, what belongs in it, what belongs below it?

The trigger for this article is a pattern I keep running into. A draft arrives that looks magnificent on the designer's 32-inch monitor — and to make it work at all you would have to invent a breakpoint beyond Bootstrap's `xxl`. An "XXXL" that exists in no established framework. My suspicion was always: this cannot be good, because the vast majority of visitors do not own screens like that.

This article tests that suspicion — with data. And the data is more damning than I expected.

It then covers everything that hangs off header size: responsive behaviour, accessibility, SEO, conversion, load performance, the actual devices your audience uses, the difference between resolution and usable space, mobile first — and what happens when you skip it. At the end there are tables with concrete numbers, and the derivation for every single one of them.

## Up front: what this article does *not* say

Rules of thumb circulate on this topic that are quoted everywhere and survive no source check. Three of them I clear away immediately, because they would otherwise poison the rest:

- **"A header may take up at most 10 % of the viewport height"** — this rule is routinely attributed to the Nielsen Norman Group. It is not in their work. I checked the relevant article: NN/g gives *no* percentage limit, it gives a functional one. WCAG likewise knows no maximum header height. Where I give numbers in this article, I derive them transparently — and I do not attribute them to people who never said them.
- **"Carousels only convert at 1 %"** — the famous number comes from *one* measurement of *one* website in 2013. The same source reports 1.7 to 2.3 % for three other sites, and 8.8 % for one. Anyone quoting only the 1 % is quoting against their own source.
- **"Navigations need at most 7±2 items"** — Jakob Nielsen himself calls this a "common misconception."

What *is* in this article is either sourced and linked, or explicitly marked as my own derivation. Where the data is thin, I say so.

## Part 1: Numbers first — who actually visits your site?

Before any recommendation makes sense, we need to establish who is actually sitting in front of the screen. And here Germany separates from the international average more sharply than you might think.

### Germany is a desktop country

| Platform | Germany | Worldwide |
| --- | --- | --- |
| **Desktop** | **54.7 %** | 47.12 % |
| Mobile | 43.56 % | **51.51 %** |
| Tablet | 1.74 % | 1.36 % |

Source: [StatCounter GlobalStats, platform comparison Germany](https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/germany) and [worldwide](https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/worldwide), June 2026.

That is the first important finding: **worldwide mobile leads, in Germany desktop leads** — by a good eleven percentage points. If you build for the German market, you cannot treat desktop as an edge case the way the international "mobile has won" rhetoric suggests.

But careful, and this matters: that is **not** an argument against mobile first. Why not, I explain in Part 7 — it is a common and expensive fallacy.

Tablets, at 1.7 %, are practically irrelevant. They do not need their own design. They need a layout that does not fall apart somewhere between roughly 768 and 1030 px.

### There is no standard resolution

Here are the ten most common screen sizes across all device types:

| # | Germany | Share | Worldwide | Share |
| --- | --- | --- | --- | --- |
| 1 | 1920×1080 | 13.28 % | 1920×1080 | 9.43 % |
| 2 | 375×812 | 10.07 % | 414×896 | 6.38 % |
| 3 | 414×896 | 7.18 % | 360×800 | 5.71 % |
| 4 | 384×832 | 4.25 % | 375×812 | 4.35 % |
| 5 | 1536×864 | 3.75 % | 384×832 | 3.72 % |
| 6 | 390×844 | 3.53 % | 390×844 | 3.31 % |
| 7 | 800×600 | 3.12 % | 1536×864 | 3.22 % |
| 8 | 2560×1440 | 3.02 % | 1280×720 | 2.85 % |
| 9 | 360×780 | 2.82 % | 1366×768 | 2.65 % |
| 10 | 393×873 | 2.41 % | 800×600 | 2.55 % |
| — | **Sum of this top 10** | **53.4 %** | **Sum of this top 10** | **44.2 %** |

Source: [StatCounter Screen Resolution Stats, Germany](https://gs.statcounter.com/screen-resolution-stats/all/germany) and [worldwide](https://gs.statcounter.com/screen-resolution-stats/all/worldwide), June 2026.

The most important row is the last one. **The ten most common sizes together cover only 53 % of German traffic — worldwide only 44 %.** Nearly half of all visitors arrive with a size that does not even make the top ten. And even the leader, 1920×1080, only reaches 13 %.

So there simply is no resolution to design for. Anyone "optimising for 1920×1080" is optimising for one eighth of their visitors. *That* is the real justification for responsive design — not "so it also works on phones", but because the target space is a continuum and not a point.

### The mobile corridor: 360 to 440 pixels

On mobile the picture is different — here there really is something like a standard:

| # | Germany | Share | Worldwide | Share |
| --- | --- | --- | --- | --- |
| 1 | 414×896 | 16.27 % | 414×896 | 12.12 % |
| 2 | 375×812 | 13.60 % | 360×800 | 9.19 % |
| 3 | 390×844 | 8.01 % | 390×844 | 6.33 % |
| 4 | 393×873 | 5.32 % | 375×812 | 5.89 % |
| 5 | 384×832 | 5.24 % | 393×873 | 4.49 % |
| 6 | 360×780 | 4.69 % | 384×832 | 3.94 % |
| 7 | 360×800 | 3.98 % | 360×780 | 3.01 % |
| 8 | 412×915 | 3.59 % | 412×915 | 2.96 % |

Source: StatCounter, mobile, Germany/worldwide, June 2026.

**The entire relevant mobile width sits between 360 and 440 CSS pixels** (rounded up at the top: the current iPhone Pro Max delivers 440, see Part 2). This is the most reliable number in the whole article. If your header works at 360 px and does not fall apart at 440 px, you have covered practically the entire mobile audience.

The difference between Germany and the world is purely a device difference: Germany is more iPhone-heavy (375/390/414 dominate), worldwide the Android standard 360×800 carries more weight. For your layout that changes nothing — both sit in the same corridor.

### And now the core question: how wide is the desktop really?

This was the trigger for the whole article. Here are the desktop sizes StatCounter reports for Germany:

| Resolution | Desktop DE | Desktop worldwide |
| --- | --- | --- |
| 1920×1080 | 24.44 % | 20.31 % |
| 1536×864 | 6.91 % | 6.96 % |
| 2560×1440 (WQHD/1440p) | **5.57 %** | 2.60 % |
| 1280×720 | 3.38 % | 6.12 % |
| 1366×768 | 2.41 % | 5.71 % |
| 1600×900 | 2.23 % | — |
| 1920×1200 | 1.52 % | — |
| 3440×1440 (ultrawide) | **0.94 %** | not in the top 20 |
| 2048×1152 | 0.69 % | — |
| 3840×2160 (4K/UHD) | **not in the top 20** | not in the top 20 |

Source: StatCounter Screen Resolution Stats, desktop, Germany/worldwide, June 2026. **Abridged:** the original list also contains two implausible outliers (375×812 at 7.53 % and 800×600 at 5.69 %) which I have left out here — why, is explained in the methodology box at the end of this chapter. That is also why the columns do not add up to 100 %.

**And now the crucial note, without which this table gets misread:** these are **CSS pixels**, not panel resolutions. StatCounter collects the values in the browser, and there the operating system's scaling is already baked in. Why that is, and how you can see it in the table, is shown in Part 2 — the 1536×864 row is the proof.

Concretely: the "3840×2160" row does **not** count 4K owners. It counts only those 4K owners running at 100 % scaling. All the others are hiding in the 1920×1080 and 2560×1440 rows. The honest statement is therefore not "this many people have 4K", but:

> **This is how much room actually arrives in your CSS.** Staggered: more than **1920** CSS pixels of width is reported by only about **7 %** of German desktop visitors (2560×1440, 3440×1440 and 2048×1152 combined). More than **2560** is reported by **under 1 %**.

That is the number that counts — and it is more devastating than any hardware statistic. Because it cannot be waved away with "but 4K sells so well." It is entirely irrelevant how many 4K panels ship. **What arrives in the browser is almost never more than 1920.**

*(Small print, because I did the arithmetic myself: StatCounter publishes only the top 20 plus a catch-all category. The 7 % is therefore a lower bound — more wide resolutions may hide in the catch-all. That does not change the order of magnitude, and it cannot reverse it.)*

### Why designers and developers systematically get this wrong

Now for the explanation of why such drafts come about in the first place. Look at the hardware the Steam survey finds on gaming PCs:

| Resolution | Steam (gaming PCs, June 2026) |
| --- | --- |
| 1920×1080 | 51.12 % |
| 2560×1440 | **21.44 %** |
| 2560×1600 | 5.64 % |
| 3840×2160 (4K) | **4.95 %** |
| 3440×1440 (ultrawide) | 3.09 % |

Source: [Steam Hardware & Software Survey](https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam), June 2026.

In the Steam population **a good 35 % have a monitor beyond Full HD** — 1440p alone accounts for over a fifth. Steam measures hardware enthusiasts with gaming rigs, and **that is exactly the population web designers and frontend developers live in.** We have the good monitors. Our clients, and our clients' customers, do not.

**An important methodological caveat I will not hide:** these Steam numbers are **not** directly comparable with the StatCounter numbers above. On Windows, Steam reports the **physical panel resolution**; StatCounter reports the **CSS resolution after scaling**. You can see it in the Steam list itself: it knows no 1536×864 (the scaled Full HD laptop), but it does list 1512×982 and 1470×956 — the logical macOS default modes. Anyone computing "factor X more" between the two tables is comparing two different quantities. So I will not do that.

What the comparison *does* show is the mechanism behind the XXXL breakpoint: a design is created on the designer's own machine and reviewed there. It unwittingly optimises for the hardware world its creator inhabits. No malice, no incompetence — a **sample size of one**.

And the punchline that ties it all together: even *that* designer, on *that* monitor, does not have 3840 pixels in their CSS. They have 2560 if they scale — or 1512 if they use a MacBook Pro.

### The methodology box: what these numbers *cannot* do

I would be a poor advisor if I handed you numbers without their limits. StatCounter is the best publicly available source, but it has real weaknesses ([StatCounter FAQ](https://gs.statcounter.com/faq)):

- **It counts page views, not people.** Verbatim: "To accurately measure usage, we have to base our stats on page views (and not unique visitors)." A heavy surfer is counted many times.
- **It is not a representative panel but a convenience sample** — namely the websites that run StatCounter's tracking code. StatCounter says so itself: "We do not impose artificial weightings on our stats — this is a conscious and deliberate decision."
- **Figures remain revisable for 45 days.**
- **The desktop category is visibly contaminated.** The German desktop list contains 375×812 (a pure iPhone size) at 7.53 %, and 800×600 at 5.69 %. Both are implausible for actual desktop machines. Whether that is device misclassification, DevTools emulation or bot traffic, StatCounter does not say — that is my guess, not a finding. The practical consequence: the true desktop shares of the large resolutions are probably *somewhat higher* than the table shows. It does not change the order of magnitude that 4K is a fringe case.

**But the most important caveat comes now** — and it leads straight into Part 2:

These figures are **screen sizes, not viewport sizes**. What the browser actually has available to paint is smaller again, after subtracting browser chrome, scrollbar and a window that is rarely maximised. And public data on real viewport sizes barely exists: the [Chrome UX Report has no viewport dimension](https://developer.chrome.com/docs/crux/methodology/dimensions), it only distinguishes phone/tablet/desktop. Anyone who finds a list of "the most common viewport sizes" online is almost always reading StatCounter data that someone mislabelled.

## Part 2: The resolution lie — why 4K is not 4K

Now to the heart of the matter — and to the point the opening suspicion already brushed against: **a high-resolution screen does not have more room. It has finer pixels.**

### CSS pixels are not hardware pixels

The `px` in CSS is not a hardware unit. It is bound to a **reference pixel**, which the W3C defines as: "the visual angle of one pixel on a device with a device pixel density of 96dpi and a distance from the reader of an arm's length" ([CSS Values 4, reference pixel](https://www.w3.org/TR/css-values-4/#reference-pixel)).

Read that again: the CSS pixel is defined via a **visual angle**. It is a unit of perception, not of hardware. At a nominal arm's length of 28 inches it corresponds to roughly 0.26 mm.

The link to hardware is called `devicePixelRatio` — per [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/devicePixelRatio), "the ratio of the resolution in physical pixels to the resolution in CSS pixels". In other words: how many real screen pixels the browser spends on one CSS pixel. In CSS the same quantity is addressable as `resolution` in `dppx`, where `1dppx = 96dpi`.

From which follows the equation this whole article revolves around:

```text
CSS viewport width  =  physical panel width  ÷  scaling factor
                       (then also: minus browser chrome, minus scrollbar,
                        minus everything the user zooms away)
```

**More hardware pixels do not create additional CSS pixels. They create denser CSS pixels.** A Retina display is not bigger — it is sharper.

### The table that explains everything

Here is what is really left of that impressive resolution:

| Device | Physical resolution | Scaling | **CSS width** |
| --- | --- | --- | --- |
| MacBook Pro 14" (M series) | 3024×1964 | 2× | **1512** |
| MacBook Air 13" (M2–M4) | 2560×1664 | default mode (see below) | **1470** |
| 4K monitor at 125 % | 3840×2160 | 1.25× | **3072** |
| 4K monitor at 150 % | 3840×2160 | 1.5× | **2560** |
| 4K monitor at 200 % | 3840×2160 | 2× | **1920** |
| 24" WQHD at 125 % | 2560×1440 | 1.25× | **2048** |
| Full HD laptop at 125 % | 1920×1080 | 1.25× | **1536** |
| 13.3" WQHD laptop at 200 % | 2560×1440 | 2× | **1280** |
| iPhone 17 Pro Max | 1320×2868 | 3× | **440** |
| iPhone 16 Plus / 15 Pro Max | 1290×2796 | 3× | **430** |
| iPhone 17 / 16 Pro | 1206×2622 | 3× | **402** |
| iPhone 16 / 15 | 1179×2556 | 3× | **393** |
| iPhone 14 / 13 / 12 | 1170×2532 | 3× | **390** |
| iPhone 11 / XR | — | 2× | **414** |
| iPhone SE (2nd/3rd gen) | — | 2× | **375** |
| iPad Pro 13" (M4/M5) | 2064×2752 | 2× | **1032** |
| iPad Air 11" | 1640×2360 | 2× | **820** |
| Samsung Galaxy S25 | — | 3× | **360** |

Sources and caveats, kept apart:

- The **native resolutions** of the MacBooks come from Apple's tech specs ([MacBook Pro](https://www.apple.com/macbook-pro/specs/), [MacBook Air](https://www.apple.com/macbook-air/specs/)). **The default modes are not stated there.** Apple documents the scaled modes nowhere publicly — the values 1512×982 and 1470×956 are observable (they even appear as their own entries in the Steam hardware survey), but they are **not confirmed by Apple**. I flag this because elsewhere in this article I demand the same of others.
- The **iOS point sizes** come from [iOS Resolution Reference](https://iosref.com/res) and [Use Your Loaf](https://useyourloaf.com/blog/iphone-17-screen-sizes/) — two independent references that agree, but which are likewise not Apple primary sources.
- The **4K, WQHD and Full HD rows are pure division** (3840 ÷ 1.5 = 2560) and should be read as such — they prove nothing, they merely do the arithmetic.

A few observations that carry weight:

**A MacBook Pro 14" with 3024 physical pixels of width delivers 1512 CSS pixels.** That is less than a cheap Full HD monitor at 100 % scaling. The designer building a layout on a MacBook is effectively working at 1512 px — they just do not notice, because everything looks razor sharp.

**A 4K monitor delivers 1920, 2560 or 3072 CSS pixels depending on scaling.** At the 150 % setting typical for 27 inches it is 2560 — the same CSS width as a plain WQHD monitor at 100 %. The four million extra pixels go entirely into sharpness, not into area.

**The MacBook Air row is the special case where the equation breaks** — and it is too instructive to leave out: 2560 ÷ 2 would be 1280, but the actual figure is 1470. The reason is supersampling. In its default mode macOS renders a framebuffer of 2940×1912 (that is 1470 × 2) and then **downscales it onto the 2560×1664 panel**. `devicePixelRatio` dutifully reports 2 — but that 2 no longer refers to the panel. It costs sharpness, GPU performance and battery, and most users do not even know it is happening.

From this follows the consequence that defuses the entire 4K argument: **it does not matter how many 4K panels exist.** What arrives in your CSS is never 3840. It is 1920, 2560, or — for the few who run 125 % — 3072. "How many people have 4K?" is the wrong question. The right one is: "**How many have more than 1920 CSS pixels?**" And the statistics from Part 1 answer that: about 7 % of desktop visitors.

### The proof is hiding in the data itself

Look again at the resolution table from Part 1. In fifth place in Germany sits **1536×864** at 3.75 %.

There is no display with a native resolution of 1536×864. It was never built. But:

```text
1920 ÷ 1.25 = 1536
1080 ÷ 1.25 =  864
```

**1536×864 is an ordinary Full HD laptop at 125 % scaling.** `screen.width` returns CSS pixels in the browser — the scaling is already accounted for. And that is exactly the value that lands in statistics like these.

Which means: **in the statistics you are already looking at scaling at work.** The vast majority of that 3.75 % are machines whose sticker promises "Full HD" and which arrive in your CSS at 1536 px. (The attribution is not perfectly clean: a *browser zoom* of 125 % on an unscaled Full HD screen also produces 1536×864, and ChromeOS ships some devices that way out of the box. The cause varies — the result for your CSS is the same.)

And the same logic applies upward: some of the 2560×1440 entries are not WQHD monitors at all, but **4K monitors at 150 %**. That cannot be untangled either — but it does not matter. What counts is the room that arrives in the browser. And for both, that is 2560.

### Fractional scaling: when the factor is not a whole number

So far I have calculated with clean factors. In practice they often are not — and that has side effects.

**Windows** offers 100 %, 125 %, 150 %, 175 %, 200 % and beyond in its display settings. Which one is flagged "recommended" depends on panel size and resolution — for 15-inch class notebooks with Full HD it is typically 125 %. (There is no current normative Microsoft table for this: the [only public document mapping panel size to scaling](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/dpi-related-apis-and-registry-settings) dates from the Windows 8.1 era, does not yet know 175 %, and is per Microsoft's own words "by no means exhaustive". I cite it as evidence that the steps *exist*, not as a current recommendation.)

In practice this means `devicePixelRatio` values of **1.25, 1.5 and 1.75** are entirely normal in everyday Windows life. Per MDN, `devicePixelRatio` is explicitly a `double` — so not an integer. If you want to know what your own machine reports, type `devicePixelRatio` into the console.

**Linux/Wayland** solved the problem at the protocol level: `wp-fractional-scale-v1` transmits the desired scaling factor as a fraction with a fixed denominator of 120 — so the value 150 means 150/120 = 1.25× ([Wayland protocol](https://wayland.app/protocols/fractional-scale-v1)). In GNOME, fractional scaling upstream is still flagged experimental.

**ChromeOS** even names the setting honestly: it is called "Display size" and shows the value under **"Looks like"**. Google describes the case itself: a device with a 1920×1080 panel "**may** show 1536x864 in the ChromeOS settings tool" — depending on the panel's pixel density ([chromeos.dev](https://chromeos.dev/en/games/optimizing-games-display)). Exactly our 125 %, and this time the effective size is right there in the menu.

What happens technically explains why awkward factors are noticeable: Blink and WebKit do not compute layout in whole CSS pixels but in `LayoutUnit` units of **1/64 of a CSS pixel** ([WebKit LayoutUnit](https://trac.webkit.org/wiki/LayoutUnit)). Everything has to be rasterised onto physical pixels in the end. At a factor of 1.25 or 1.5 a 1px divider inevitably lands on half a device pixel — and gets smeared across two pixel rows by anti-aliasing. That is why fine borders, table rules and header underlines look grey and uneven on scaled displays.

**Practical rule:** do not rely on 1px lines as a load-bearing design element in the header. If a divider matters, give it contrast rather than precision — on a meaningful share of devices it will not sit cleanly.

## Part 3: From screen to viewport — what is really left

We are not done shrinking. Between screen resolution and the space your header actually gets, several deductions intervene:

```text
┌─────────────────────────────────────────────────────────────┐
│ SCREEN  e.g. 1920 × 1080 physical                           │
│  ├─ minus OS scaling (125 %)            →  1536 × 864 CSS   │
│  │                                                          │
│  │  ┌────────────────────────────────────────────────────┐  │
│  │  │ BROWSER WINDOW  (rarely maximised)                 │  │
│  │  │  ┌──────────────────────────────────────────────┐  │  │
│  │  │  │ ▸ Tab strip, address bar, bookmarks          │  │  │
│  │  │  ├──────────────────────────────────────────────┤  │  │
│  │  │  │ VIEWPORT  ← your CSS lives here       ░│     │  │  │
│  │  │  │ ┌──────────────────────────────────┐  ░│     │  │  │
│  │  │  │ │ HEADER                           │  ░│Scr. │  │  │
│  │  │  │ ├──────────────────────────────────┤  ░│bar  │  │  │
│  │  │  │ │ HERO / first content             │  ░│     │  │  │
│  │  │  │ │                                  │  ░│     │  │  │
│  │  │  ╞══════════════════════════════════════════════╡  │  │
│  │  │  │        ↑ THE FOLD ↑                          │  │  │
│  │  │  │   57 % of viewing time happens above it      │  │  │
│  │  │  │                                              │  │  │
│  │  │  └──────────────────────────────────────────────┘  │  │
│  │  └────────────────────────────────────────────────────┘  │
│  └─ minus taskbar                                           │
└─────────────────────────────────────────────────────────────┘
```

### On the desktop: screen ≠ window

Here the data is honestly poor, and I would rather say so than paper over it. The only publicly available measurement comes from [CSS-Tricks](https://css-tricks.com/screen-resolution-notequalto-browser-window/) — and it is **from 2011**. The author himself declares the sample unrepresentative ("a bunch of designer nerds, probably").

The *quantitative* values from back then are useless today. The *qualitative* finding is not:

- Only **0.85 %** browsed at exactly full screen.
- **61 %** were within 200 px of full-screen width.
- The average browser window was **1366×784** against an average screen resolution of 1526×967.

Translated: most people browse *near* full screen, but almost nobody *exactly* full screen. And vertically, browser UI and taskbar eat a three-digit pixel amount — on an 864-CSS-px laptop you realistically end up with around **700 px of viewport height**. That is the space in which your header and your hero compete.

I could not find a reliable source for a concrete pixel height of the Chrome toolbar — so I will not claim one. Measure it yourself instead:

```js
// Run this in the console on any page to see the real numbers
console.table({
	'Screen (CSS px)': `${screen.width} × ${screen.height}`,
	'Window (outer)': `${outerWidth} × ${outerHeight}`,
	'Viewport (inner)': `${innerWidth} × ${innerHeight}`,
	'devicePixelRatio': devicePixelRatio,
	'Physical panel': `${screen.width * devicePixelRatio} × ${screen.height * devicePixelRatio}`,
});
```

Run this on your own machine. For most developers, the gap between the first and the third line is the moment the penny drops.

### On the phone: the broken `100vh`

Mobile adds a problem of its own. `100vh` is **wrong** on mobile devices — systematically so. The address bar slides in and out as you scroll, the viewport height changes with it, and `vh` refers to the state with the bars *retracted*. So a hero with `height: 100vh` overflows the visible area on load.

The fix has been available for years and is unreservedly usable today ([web.dev: The large, small, and dynamic viewport units](https://web.dev/blog/viewport-units)):

| Unit | Meaning |
| --- | --- |
| `lvh` | **L**arge — all browser bars *retracted* (the optimistic case, equals `vh`) |
| `svh` | **S**mall — all browser bars *extended* (the pessimistic, guaranteed-visible case) |
| `dvh` | **D**ynamic — follows the actual state, so it changes while scrolling |

Browser support: Chrome from 108, Firefox from 101, Safari from 15.4 — around 92 % global coverage per [caniuse](https://caniuse.com/viewport-unit-variants). The last engine shipped in November 2022. A `vh` fallback is cosmetic in 2026.

**My recommendation for header and hero:** use `svh`. That is the value that is *guaranteed* visible. If your hero is built with `min-height: 60svh`, it is fully present in *every* toolbar state. `dvh` sounds tempting but has a catch web.dev states explicitly: "The values for the dynamic viewport do not update at 60fps. In all browsers updating is throttled" — a hero tied to `dvh` jitters while you scroll.

## Part 4: Breakpoints — the corridor that actually exists

Now to the opening question: what actually *is* the standard, and what does it mean to leave it?

### Bootstrap 5

Current is Bootstrap 5.3.8. Bootstrap 6 has been in development since 2025 but is not released and has no announced date — so in practice the 5.x values still apply.

| Breakpoint | Abbr. | From viewport | **Container width** |
| --- | --- | --- | --- |
| Extra small | *(none)* | 0 | 100 % |
| Small | `sm` | 576 px | 540 px |
| Medium | `md` | 768 px | 720 px |
| Large | `lg` | 992 px | 960 px |
| Extra large | `xl` | 1200 px | 1140 px |
| Extra extra large | `xxl` | **1400 px** | **1320 px** |

Source: [Bootstrap Breakpoints](https://getbootstrap.com/docs/5.3/layout/breakpoints/) and [Containers](https://getbootstrap.com/docs/5.3/layout/containers/).

The right-hand column is almost always overlooked and it is the actual point: **the widest standard content container in Bootstrap is 1320 px.** Not 1400, not 1920. Beyond 1400 px of viewport width the content *stops growing* — it stays at 1320 px and centres itself. The extra space becomes margin.

That is not an oversight. That is the solution.

### Tailwind CSS v4

Current is Tailwind 4.3.2.

| Abbr. | Value | Equals |
| --- | --- | --- |
| `sm` | 40rem | 640 px |
| `md` | 48rem | 768 px |
| `lg` | 64rem | 1024 px |
| `xl` | 80rem | 1280 px |
| `2xl` | **96rem** | **1536 px** |

Source: [Tailwind CSS: Responsive design](https://tailwindcss.com/docs/responsive-design).

Two things matter here. First: **Tailwind v4 defines breakpoints in `rem`, not in `px`.** That is not a cosmetic difference. `rem` scales with the browser's root font size — someone who set it to 20 px (because their eyesight is poor) reaches `md` only at 960 instead of 768 CSS px of viewport. For accessibility that is a genuine win; for pixel-precise design sign-off it is a trap.

Second, and this is the answer to the opening question: **there is no `3xl`.** Not in Tailwind, not in Bootstrap. The Tailwind docs show `3xl` only as an *example* of how to **add** a breakpoint — if you want one, you have to define it yourself:

```css
@theme {
	--breakpoint-3xl: 120rem; /* 1920px — you are on your own here */
}
```

A nasty confusion in passing: Tailwind *does* have a `--container-3xl` and even a `--container-7xl`. But those are **container-query and `max-w-*` sizes**, not viewport breakpoints. The shared naming causes misquotes on a regular basis — including in design reviews.

### Both systems side by side

Because one set of docs works in pixels and the other in `rem`, the two tables above cannot be compared directly — and that is exactly where misunderstandings in sign-off meetings come from. So here is everything in **CSS pixels**, on one scale:

| CSS px | Bootstrap 5 | Tailwind v4 | Typical device |
| --- | --- | --- | --- |
| 576 | `sm` | — | (falls between stools) |
| 640 | — | `sm` | large phone, landscape |
| **768** | **`md`** | **`md`** | tablet portrait — the only breakpoint both share |
| 992 | `lg` | — | small tablet, landscape |
| 1024 | — | `lg` | tablet landscape |
| 1200 | `xl` | — | small laptop |
| 1280 | — | `xl` | laptop |
| **1400** | **`xxl`** *(end)* | — | desktop |
| **1536** | — | **`2xl`** *(end)* | Full HD laptop at 125 % |
| 1920+ | — | — | **No man's land. There is nothing here.** |

Two things jump out. First: **the two systems almost never line up** — they meet only at 768 px. Anyone rebuilding a Bootstrap design in Tailwind (or vice versa) and "carrying over" the breakpoints is silently building a different layout.

Second: **above 1536 px the world ends.** Both market leaders — together the overwhelming share of CSS frameworks in production — say: that's it. No `xxxl`, no `3xl`, nothing. A design that wants to keep going out there is not progressive. It is alone.

### What an XXXL breakpoint actually means

This lets us put a number on the suspicion from the introduction. What decides everything is **where exactly** the threshold sits below which the design stops working. The ladder, computed against the German desktop figures from Part 1:

```text
A design that needs AT LEAST … CSS pixels of width
still reaches roughly … of German desktop visitors:

  1280 px  (Tailwind xl)     ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  almost all real desktops
  1536 px  (Tailwind 2xl)    ▓▓▓▓▓▓▓▓               ~42 %   ← mostly 1920×1080
  1920 px                    ▓▓▓▓▓▓▓                ~33 %
  above 1920 px              ▓                      ~7 %    ← XXXL starts here
  above 2560 px              ▏                      < 1 %

And those are DESKTOP visitors only. Across all visitors
(desktop = 54.7 % in Germany) every one of these numbers roughly halves:
"above 1920 px" then reaches about 4 % of your total audience.
```

**The drop from 33 % to 7 % is the real news in this ladder.** Between "at least 1920" and "more than 1920" there is a wall: virtually all wide desktop traffic is *exactly* 1920 px wide and not one pixel more. 1920 is not a waypoint on the road upward — **1920 is the terminus.** Anyone planning beyond it is planning for the empty space behind it.

That is the honest answer, and it is more nuanced than I would like: a design that comes together at 1536 px still reaches a good two fifths of desktop users — that is bad, but not absurd. **A design that needs true XXXL widths beyond 1920 px, however, reaches about 4 % of your visitors.** And below that it either breaks or squanders its effect.

On top come the deductions that appear in no statistic:

```text
Who will NOT see the design — even when the statistics count them in:
   ├─ every mobile user                        43.6 % (DE)
   ├─ every tablet                              1.7 %
   ├─ every MacBook Pro 14"   → 1512 CSS px    ← below Tailwind's 2xl!
   ├─ every MacBook Air 13"   → 1470 CSS px    ← below Tailwind's 2xl!
   ├─ every Full HD laptop at 125 %  → 1536 CSS px, exactly on the edge
   ├─ everyone whose browser window is not maximised
   └─ everyone who zooms — and zoom is a right, not an edge case
```

The bitter punchline: **not even the designer sees their own design if they work on a MacBook Pro.** 1512 CSS pixels sit *below* Tailwind's `2xl`.

So the intuition was right — but for a different reason than assumed. It is not merely that too few people own large monitors. It is that **even the people with large monitors do not have large CSS viewports.** Scaling eats them.

### The right answer: `max-width`, not `3xl`

A layout that "comes together" above a certain width is a layout that was thought about wrongly. The question is never "from what width does it look good?" but "**how far may it grow, and what happens after that?**"

The frameworks' answer is unambiguous: content grows up to a maximum and then stops. Bootstrap caps at 1320 px, Tailwind's largest content utility `max-w-7xl` at 80rem = 1280 px. Both say the same thing: **beyond about 1300 px, space becomes margin, not content.**

There is a factual reason for this that has nothing to do with statistics: a **body text** line beyond 75 characters becomes hard to read, because at the line break the eye can no longer reliably find the next line. That applies to reading text — the *layout* width may sit somewhat above it, as long as body text inside is capped again. And a header stretched across 2560 px has navigation items the eye has to travel between.

The modern toolkit for the rest:

```css
.site-header {
	/* Full-bleed background, bounded content — the standard pattern */
	--content-max: 80rem; /* 1280px at default root font size */
}

.site-header__inner {
	max-width: var(--content-max);
	margin-inline: auto;
	/* Fluid padding instead of a cascade of breakpoints.
	   Note: the PADDING is fluid, the HEIGHT is not — a header has a
	   job (fit the touch targets), not a share of the viewport. */
	padding-inline: clamp(1rem, 4vw, 3rem);
	min-height: 4rem;
}
```

`clamp()` has been widely available since July 2020 and replaces an entire cascade of media queries in exactly these cases ([MDN: clamp()](https://developer.mozilla.org/en-US/docs/Web/CSS/clamp)).

For components *inside* the header — a navigation that wraps depending on available room — **container queries** are the right tool: they query the space in the parent, not the viewport. Available in all engines since February 2023, around 92.6 % coverage ([MDN: @container](https://developer.mozilla.org/en-US/docs/Web/CSS/@container)).

The framing that matters here comes from Una Kravets at Google ([web.dev: The new responsive](https://web.dev/articles/new-responsive)): container queries do **not replace** media queries, they complement them. Media queries handle the **macro layout** (page level), container queries the **micro layout** (component level). Playing one against the other means understanding neither.

### The CMS reality

In practice you rarely meet this on a greenfield — you meet it inside a CMS. Briefly:

- **Contao** still ships an in-house grid (float-based, built on 960.gs, around since Contao 3), but it is legacy and no longer recommended — in practice the widths come from the theme. More important is the structural quirk: the header is a **module slot**. What goes into it is an editorial and configuration decision, not a design decision. **That is exactly why Contao headers derail so often**: there is nobody to say "no" when one more module gets added.
- **WordPress** has been the Wild West since full-site editing. Block themes define their widths in `theme.json` via `layout.contentSize` and `layout.wideSize` — that is where you enforce the cap. When a client demands a "full-width header", `wideSize` is the lever, not a new breakpoint. Classic themes bring their own soup, often Bootstrap or a homegrown grid.
- **TYPO3** separates backend layout and frontend rendering (Fluid templates) cleanly. The widths live in the site package. The typical TYPO3 failure is a different one: the header gets made configurable as a "backend layout", and then editors fill it to the brim.

The pattern is the same in all three systems: **the technology permits more than the design can bear.** A CMS header does not need technical limits, it needs editorial ones. More on that shortly.

## Part 5: The header, dissected

Let us talk about what actually belongs in there.

### Anatomy on the desktop

```text
┌────────────────────────────────────────────────────────────────────┐
│ ◇ Meta bar (optional, 28–36px)   Language · Login · Phone          │  ← optional
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  [LOGO]        Services   Work   About   Blog          [ CTA  ]    │  ← mandatory
│  ↑ home link   ↑ 3–7 items, VISIBLE, no burger         ↑ just one  │     56–96px
│                                                                    │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│                     H1: The one statement                          │  ← HERO
│           Teaser: one or two sentences supporting it               │     40–70svh
│                                                                    │
│                        [ Primary action ]                          │
│                                                                    │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┤
│  ▓▓▓ A visible sliver of the next content block ▓▓▓                │  ← REQUIRED!
└────────────────────────────────────────────────────────────────────┘
   ↑ The fold. What sits above it gets 57 % of the attention.
```

That last sliver is not decoration. It is the reason a hero should fill the full viewport height **only with a very good reason** — the evidence is in Part 10.

### Anatomy on the phone

```text
┌──────────────────────────┐  360–440 CSS px, that is all there is
│ [LOGO]         [☰]  [→]  │  ← 48–64px. Logo + burger + max. 1 action.
├──────────────────────────┤
│                          │
│  H1: The one statement   │  ← Hero, max. 60svh
│  Teaser, short.          │
│                          │
│    [ Primary action ]    │  ← min. 44×44px hit area
│                          │
├ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─┤
│ ▓▓▓ next content ▓▓▓     │
└──────────────────────────┘
```

At 360 px of width the header is not a design canvas. It is a compromise between three things, of which only two will fit.

### What may go in — and what may not

| Element | Status | Position | Recommendation |
| --- | --- | --- | --- |
| **Logo / wordmark** | mandatory | left, linked to home | 32–48 px tall. Set `width`/`height` in the HTML (CLS!). On mobile, consider the mark instead of the wordmark. |
| **Main navigation** | mandatory | right or centre, **visible** | Desktop: 3–7 items, spelled out. **No burger on desktop** — see Part 10, the numbers are unambiguous. |
| **Skip link** | mandatory (WCAG 2.4.1, Level A) | first focusable element | May be visually hidden, must become visible on focus. |
| **Primary CTA** | recommended | far right, visually distinct | **Exactly one.** Two equal-ranking CTAs are zero CTAs. |
| **`<h1>`** | mandatory (SEO + WCAG 2.4.6) | in the hero | One per page, descriptive. Not a marketing claim without content ("We think tomorrow" is not an H1). |
| **Teaser text** | recommended | below the H1 | 1–2 sentences, max ~160 characters. It supports the H1, it does not repeat it. |
| **Hero image** | optional | background or beside | On 73 % (mobile) resp. 83 % (desktop) of all websites an image is the LCP element — usually this one. Treat it accordingly (Part 9). |
| **Search field** | context-dependent | right | Only if the site genuinely has search volume. Otherwise an icon that opens a palette. |
| **Language switcher** | mandatory on multilingual sites | meta bar or right | Visible, not just `hreflang`. |
| **Meta bar** | optional | very top, 28–36 px | Phone, login, language. Only if these things are *really* needed on every page. |
| **Breadcrumb** | recommended from depth 3 | **below** the header, not inside it | It belongs to the content, not to the head. |
| **Slider / carousel** | **advise against** | — | See Part 10. If it must exist: max 5 frames, no auto-rotate without a pause control (WCAG 2.2.2, Level A). |
| **Cookie banner** | legal, not editorial | overlay | It does *not* belong in the header flow. If it shifts the header, it is a CLS source. |

The row that triggers the most argument is the slider. The numbers on it come in Part 10 — and they are more nuanced than either camp claims.

## Part 6: The size tables

Now the concrete numbers. **Important for reading them:** WCAG knows no maximum header height, and the Nielsen Norman Group gives none. The values below are therefore **my recommendations** — but they are not invented. Every number has a derivation, and it is stated alongside.

### First the yardsticks: reference viewports

To make the tables below imaginable at all, we need fixed reference sizes. I set them once here, and every percentage and comparison value in the rest of the article is computed against them:

```text
                       Screen          minus              visible height
                       (CSS px)        browser UI &       = 100 svh
                                       taskbar            = down to the fold
──────────────────────────────────────────────────────────────────────────
MOBILE                 390 × 844       address/tab bar    ≈ 700 px
  (iPhone class)

DESKTOP, laptop       1536 ×  864      chrome + taskbar   ≈ 700 px
  (Full HD @ 125 %)

DESKTOP, large        1920 × 1080      chrome + taskbar   ≈ 900 px

──────────────────────────────────────────────────────────────────────────
WORKING VALUE FOR DESKTOP, used below:                    ≈ 800 px
  (midway between laptop and large monitor)
```

**The surprise is in the first two rows:** a typical Windows laptop has **no more vertical room than a smartphone**. Both land at roughly 700 pixels of visible height. The laptop is merely wider — not taller. Anyone who believes there is "plenty of room below the fold on desktop" is wrong by exactly zero pixels.

These are approximations, not measurements — real height varies by browser, bookmarks bar and window state by a few dozen pixels. As a mental aid they are enough: **1 svh ≈ 7 px on the phone, ≈ 8 px on the desktop.**

### Why the tables use two different units

This is not sloppiness, it is deliberate — and the reason is worth a minute:

- **The header is measured in `px`**, because its height is determined by *absolute* things: a finger tap needs 44 px, no matter how tall the screen is. A header that grows on large screens grows for no reason at all.
- **The hero is measured in `svh`**, because its height is determined by a *relative* thing: the fold. It should fill a certain proportion of the visible area — and that area is a different height on every device.

Short version: **the header has a job, the hero has a share.** That is why they are measured differently. The tables below give you both anyway.

### Header height

| Context | Recommendation | Upper limit | Share of visible area | Derivation |
| --- | --- | --- | --- | --- |
| **Mobile, static** | 56–64 px | 72 px | 8–9 % of 700 px | 44 px hit area (Apple) + 2×8 px padding. A logo plus a burger needs no more. |
| **Mobile, sticky** | 48–56 px | 64 px | 7–8 % of 700 px | It sticks on *every* screenful. Every pixel is taken from the content permanently. At 48 px, though, there is no vertical padding left for the 44 px burger — 56 px is the more comfortable choice. |
| **Desktop, static** | 72–96 px | 120 px | 9–12 % of 800 px | 44 px click target + generous padding. Beyond that it becomes decoration. |
| **Desktop, sticky (scrolled)** | 56–72 px | 96 px | 7–9 % of 800 px | Derivation below — this is the critical number. |
| **Meta bar (if present)** | 28–36 px | 40 px | 3.5–4.5 % of 800 px | Must carry legible type (≥14 px) plus air, nothing more. |

For a sense of scale: **64 px is about two lines of body text.** 120 px — my upper limit for a static desktop header — is roughly **four lines**. And 160 px, which turns up in the wild constantly, is over **five lines of text nobody wants to read**, on every page, right at the top.

**The derivation of the 96px limit for sticky headers** — and I lay it out so you can check it:

The anchor is **WCAG 1.4.10 Reflow** (Level AA). Per W3C the criterion derives explicitly from **400 % zoom on a 1280 px viewport**. Zoom enlarges CSS pixels — so the available height shrinks accordingly. A sticky header keeps its CSS height throughout and therefore occupies an **ever larger relative share**:

```text
Starting point: desktop viewport ≈ 800 CSS px tall

Header height    at 100 % zoom     at 200 % zoom     at 400 % zoom
                 (800px visible)   (400px visible)   (200px visible)
────────────────────────────────────────────────────────────────────
  64 px               8 %              16 %              32 %
  96 px              12 %              24 %              48 %
 120 px              15 %              30 %              60 %   ← alarm
 160 px              20 %              40 %              80 %   ← unusable
```

At 120 px and 400 % zoom the actual content is left with 80 of 200 pixels. That is not a website any more, that is a peephole.

**To be clear: the 96 px is my derivation, not a standard.** WCAG contains no header height — not in 1.4.10, not anywhere. What WCAG contains is the *requirement* that content still be readable at 400 % zoom. The 96 px is the value at which I consider that requirement still satisfiable with a sticky header. Check the arithmetic, and if you arrive at 80 or 110 we still agree.

And the real fix is not "smaller header" anyway, it is "**not sticky at all when height is scarce**" — see Part 8.

The Nielsen Norman Group frames the limit **functionally** rather than as a percentage, and that is the smarter formulation. (Whether they do that deliberately I do not know — they do not say. They simply give no percentage, and anyone who attributes one to them has not read them.) Their guidance in [Sticky Headers: 5 Ways to Make Them Better](https://www.nngroup.com/articles/sticky-headers/): as tall as 1 cm hit areas and roughly 16 pt type strictly require — and "minimize any additional vertical height beyond those sizes". Not a pixel more than necessary.

*(Converted into the unit you actually build in: **1 cm ≈ 38 CSS px**, **16 pt ≈ 21 CSS px** — not 16! Why the rulebooks compute in four different units, and how to convert between them, is in its own table just below.)*

### Hero height

The decisive calculation here is not the hero itself but **what is left below it**. Because the header sits above it too. The last column is therefore the most important in the whole table:

| Context | Recommendation | ≈ in pixels | Left below the fold *(after the header)* |
| --- | --- | --- | --- |
| **Mobile** | `min-height: 50–60svh` | ~350–420 px *(of 700)* | 224–294 px — **a clearly visible content sliver** |
| **Desktop** | `min-height: 40–60svh` | ~320–480 px *(of 800)* | 240–400 px — **plenty of scroll invitation** |
| **Absolute upper limit** | 70 svh | ~490 px mobile / ~560 px desktop | ~150–160 px — tight, but still visible |
| **Full screen (`100svh`)** | **only with reason** | 700 px mobile / 800 px desktop | **0 px — nothing. That is precisely the problem.** |

*(Computed with a **static** header: 56 px mobile, 80 px desktop — the least favourable case, because a static header may be taller than a sticky one. The "left below" column applies to the **lower** end of each hero range; pull the hero taller and you get correspondingly less. The reference implementation in Part 12 uses a **sticky** header at 56/72 px and therefore has a little more air.)*

The last row is the whole point. A `100svh` hero leaves **literally nothing** below the fold — the header even pushes it beyond, so the hero itself gets cropped at the bottom. The user sees a page that looks as though it ends here.

And in the recommended range of 50–60 svh? There you keep roughly **220 to 300 pixels** — enough for a heading and two or three lines of the next section. Enough for the eye to register: *this continues.* That is not an aesthetic question, that is the scroll invitation.

**Why `svh` and not `vh`:** `svh` computes with the browser bars *extended*, so it is the **guaranteed visible** case. `vh` (= `lvh`) is the optimistic case and is never accurate on a phone at load time — a `100vh` hero overflows the bottom of the screen there. Mnemonic: **`svh` is what you definitely have. `lvh` is what you would like to have.**

**Why not `100svh`:** the Nielsen Norman Group calls the problem a ["false floor"](https://www.nngroup.com/articles/page-fold-manifesto/) — a layout that looks as though the page ends here. The user does not scroll because nothing suggests there is more. A screen-filling hero with no visible content sliver beneath it is the textbook form of this mistake.

If a full-screen hero really must happen (campaign page, portfolio), then **always with scroll affordance**: a cropped element, an arrow, a snippet of text. Anything that says "it continues here."

### Header width and the content container

So far this has all been about height. Width is the second, independent lever — and the one the XXXL problem hangs on:

| Measure | Recommendation | Upper limit | ≈ characters per line | Derivation |
| --- | --- | --- | --- | --- |
| **Content container** *(layout width)* | 1280–1320 px | **1440 px** | (layout, not body text) | Bootstrap caps at 1320, Tailwind `max-w-7xl` at 1280 — that is the documented corridor of both market leaders. The 1440 is my tolerance limit, not a framework rule. |
| **Header background** | full width | — | — | The *background* may happily run edge to edge. Only the **content** gets capped. |
| **Text column in the hero** | 45–75 characters | — | 45–75 | Typographic fundamentals. Stretch the H1 across 1400 px and you send the eye on a journey. |

**The difference between the first two rows is the entire solution to the XXXL problem.** A header may and should look full-bleed — its background runs from edge to edge. But its *content* — logo, navigation, CTA — sits in a container that stops growing at around 1300 px. Everything beyond becomes margin.

That is why nobody needs an XXXL breakpoint: **you do not build a layout for 2560 px. You build a layout for 1300 px and let the rest be margin.**

### Hit areas and type sizes in the header

Here lurks the greatest source of confusion in the whole topic: **the authoritative rulebooks compute in four different units.** WCAG in CSS pixels, Apple in points (pt), Google in density-independent pixels (dp), the Nielsen Norman Group even in centimetres. Put the numbers 24, 44, 48 and 16 side by side and you are comparing apples with oranges.

So first the conversion key — **everything in CSS pixels**, the only unit you actually build in:

| The source says | Unit | **≈ in CSS pixels** | Meaning |
| --- | --- | --- | --- |
| WCAG 2.5.8 (AA) | 24 CSS px | **24 px** | Hard floor. Below it: a violation. |
| WCAG 2.5.5 (AAA) | 44 CSS px | **44 px** | Recommended target. |
| Apple | 44 **pt** ¹ | **44 px** | Apple point: 1 pt = 1 CSS px. Matches WCAG AAA. |
| Material / Android | 48 **dp** | **48 px** | 1 dp = 1 CSS px. About 9 mm physically. |
| Material, spacing | 8 **dp** | **8 px** | Visual spacing — **not** the WCAG exception, see below. |
| NN/g, sticky header | 1 **cm** | **≈ 38 px** | Physical measure, converted at 96 dpi. |
| NN/g, type size | 16 **pt** ¹ | **≈ 21 px** | Typographic point: 1 pt = 1.333 CSS px. **Not 16 px!** |

¹ **The trap is in "pt".** The abbreviation does **not** mean the same thing in those two rows: Apple's "point" is a layout unit and equals 1 CSS pixel. The typographic point used for type sizes is a third larger (1 pt = 1⅓ px). Both conversions above are correct — but anyone treating "44 pt" and "16 pt" as the same unit will miscalculate, guaranteed.

The good news: **for hit areas, pt, dp and CSS px are practically identical** — Apple's 44 pt and Material's 48 dp are simply 44 and 48 CSS pixels. Only centimetres and the typographic point step out of line.

And now the actual table, entirely in CSS pixels:

| Element | Minimum | Recommendation | Derivation |
| --- | --- | --- | --- |
| Any click/tap target | **24 × 24 px** | 44 × 44 px | WCAG 2.5.8 (AA) is the floor; 2.5.5 (AAA) and Apple say 44. |
| Icon buttons (burger, search) | 24 × 24 px | **44–48 px** | Apple 44, Material 48 — take 48 and you satisfy both. |
| Spacing between small targets | — | ≥ 8 px | Material recommendation. **Careful:** does not replace the WCAG spacing exception — see below. |
| Navigation type | 14 px | **16–18 px** | Experience value. NN/g cites ~21 px (16 pt) for sticky headers. |
| H1 in the hero | — | `clamp(1.75rem, 4vw, 3.5rem)` = **28–56 px** | Fluid but capped — reasoning below. |
| Teaser | 16 px | 18–20 px | Body text size, no smaller. |

**The WCAG numbers, cleanly separated**, because they get muddled constantly:

- **24×24 CSS px** — that is [SC 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html), **Level AA, new in WCAG 2.2**. The spacing exception is more precise than it is usually reported: smaller targets are allowed if a circle of **24 px diameter**, **centred on the bounding box** of each target, intersects neither another target nor the circle of another undersized target. In practice that means roughly **24 px centre to centre** — the 8 dp from Material Design does *not* automatically satisfy it.
- **44×44 CSS px** — [SC 2.5.5 Target Size (Enhanced)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html), **Level AAA**. A common error: this criterion is *not* new in 2.2 — it arrived in WCAG 2.1 and was merely renamed.
- **44 pt** — [Apple, UI Design Dos and Don'ts](https://developer.apple.com/design/tips/): "Create controls that measure at least 44 points x 44 points."
- **48 dp** — [Android Accessibility Help](https://support.google.com/accessibility/android/answer/7101858): "at least 48x48dp, separated by 8dp of space" — physically about 9 mm.

For a header with icon buttons, **44–48 px is the practical target and 24 px the hard floor** you must not go below. Take 44–48 and the spacing exception stops mattering — it only applies to undersized targets in the first place.

### A warning about `vw` type sizes

The tempting line `font-size: 4vw` for the hero headline is an accessibility risk. There is an official W3C failure for it: **F94, "Failure of Success Criterion 1.4.4 due to incorrect use of viewport units to resize text"**.

Adrian Roselli puts the problem precisely ([Responsive Type and Zoom](https://adrianroselli.com/2019/12/responsive-type-and-zoom.html)): "When people zoom a page, it is typically because they want the text to be bigger. When we anchor the text to the viewport size, even with a (fractional) multiplier, we can take away their ability to do that."

Pure `vw` does not scale with the user's zoom — so you take away exactly the ability they were trying to exercise. The fix is `clamp()` with a **`rem`-based minimum and maximum**:

```css
h1 {
	/* Min and max in rem → still scales with user zoom.
	   The vw part only handles the fluid middle range.
	   Max is exactly 2× min — see the MDN rule below. */
	font-size: clamp(1.75rem, 4vw, 3.5rem);
}
```

MDN's rule of thumb: **the maximum must be at least twice the minimum** — otherwise the 200 % scalability required by 1.4.4 is arithmetically unreachable. That is why it says `3.5rem` above and not `3.25rem`: 2 × 1.75 = 3.5. Skimp here and you build the violation in yourself.

## Part 7: Mobile first — and what happens if you skip it

Now to the question the German desktop figures appear to reopen.

### What mobile first technically means

Mobile first is not a design philosophy, it is a **CSS cascade decision**. It means: the base styles apply to the smallest viewport, and media queries *extend* them upward with `min-width`.

```css
/* MOBILE FIRST — the base case is the small screen */
.nav {
	display: none; /* hidden behind the burger */
}

@media (min-width: 48rem) {
	.nav {
		display: flex; /* progressively enhanced upward */
	}
}
```

```css
/* DESKTOP FIRST — the base case is the big screen */
.nav {
	display: flex;
}

@media (max-width: 47.99rem) {
	.nav {
		display: none; /* stripped back downward */
	}
}
```

Both market leaders are mobile first: Bootstrap uses `min-width` as its default and states explicitly in the docs that `xs` needs no media query at all (downward queries do exist there — `media-breakpoint-down` — but as the exception, not the foundation). Tailwind generates `@media (width >= …)` throughout for `sm:`…`2xl:`.

So working desktop first means working **against** your framework.

### The comparison

| | **Mobile first** (`min-width`) | **Desktop first** (`max-width`) |
| --- | --- | --- |
| **Basic stance** | What is indispensable? | What can go? |
| **Result** | Additive — features get added | Subtractive — features get cut |
| **Typical consequence** | A lean header that grows upward | An overloaded header that breaks downward |
| **Performance** | Small device loads small rules first | Small device loads the full desktop cascade and overrides it |
| **CSS specificity** | stays flat | grows — overrides of overrides |
| **Framework support** | Bootstrap, Tailwind, Bulma natively | against the grain |
| **Typical failure class** | Desktop looks empty, space unused | Mobile is broken and "will be fixed later" |
| **When is it right?** | Almost always | Internal tools, admin backends, dashboards with guaranteed desktop hardware |
| **The real reason it fails** | — | The header was conceived for 1920 px. It does not fit 360 px — so things get cut until it "sort of works" |

The decisive difference is not technical, it is **disciplinary**. Mobile first forces you to decide, at 360 px, what actually matters. Desktop first lets you defer that decision — and deferred decisions never get made, they get made in the end by the deadline.

**The overloaded header is almost always a symptom of desktop first.** Not because `max-width` is worse CSS, but because nobody was forced to say "no".

### Do the German desktop numbers overturn this?

The obvious question: if 54.7 % in Germany use desktop — shouldn't you work desktop first?

**No.** And the fallacy is worth dissecting, because it is so seductive.

1. **43.6 % mobile is not an edge case.** Even with desktop ahead: nearly half your visitors arrive with 360–440 px. "Majority" is not "everyone".
2. **Mobile first does not mean "mobile matters more".** It means: "the base case is the narrowest one." Mobile-first CSS can have a magnificent desktop header — it just comes *after* the simple one.
3. **The narrow case is mandatory anyway.** WCAG 1.4.10 requires usability at **320 CSS px** — narrower than any real phone. You have to solve the narrow case whether you like it or not. So you may as well start there.
4. **The desktop share is not a law of nature.** It partly reflects who shows up in the first place. A site with a poor mobile experience measures little mobile traffic — and wrongly concludes mobile is unimportant. That is a self-fulfilling prophecy, and I have seen it in analytics reviews often enough.

What the German numbers *actually* mean: **the desktop header must not be treated as an afterthought.** The internationally common "mobile is everything, desktop is mobile with more margin" is too little for the German market. Both cases deserve real design. But the *order* in which you build them stays: small first.

The most honest formulation is **content first** anyway. Mobile first is merely the method that forces you into it.

## Part 8: Accessibility — the limits that are not negotiable

Everything so far has been recommendation. What follows is partly law — and because this gets muddled routinely, here is the legal situation precisely:

**What is binding today (as of July 2026) in Germany:** the BITV 2.0 (public bodies) and the BFSG (in force since 28 June 2025) both hang off the harmonised standard **EN 301 549**. The version cited in the EU Official Journal is **v3.2.1**, and that refers to **WCAG 2.1 Level AA**. A version referencing WCAG 2.2 is in preparation but not yet in force.

**Concretely that means:** the two criteria most important for headers in this chapter — **2.4.11 Focus Not Obscured** and **2.5.8 Target Size (Minimum)** — are **WCAG 2.2 additions and therefore not currently legally binding**. In all likelihood they will become so. I treat them here as what they are: **foreseeably applicable law, and good practice already today.** Everything else in this chapter (1.4.10, 1.4.4, 2.4.1, 2.2.2) is already in WCAG 2.1 and applies now.

And one more limitation, because it gets told too broadly: **the BFSG does not blanket-apply to "the private sector".** It covers specific enumerated products and services in consumer business — e-commerce, banking services, telecommunications, e-books, passenger transport. A purely informational company website with no contract initiation does not fall under it, and micro-enterprises are exempt for services. Whether the BFSG applies to you is a legal question — not one a blog article answers.

The rest of this chapter is relevant to **everyone** regardless. Because whether or not a law compels you: a header that eats half the screen at 400 % zoom is simply broken.

### 1.4.10 Reflow: the 320-pixel limit

[SC 1.4.10 Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html) (Level AA) requires, verbatim, that content be presentable "without loss of information or functionality, and without requiring scrolling in two dimensions" at a width of **320 CSS pixels**.

The derivation is in the Understanding document itself: "320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom."

*(A note on the bookkeeping: WCAG works from a reference viewport of 1280 × 1024 px — at 400 % zoom that leaves 320 × 256 px. In Part 6 I computed with the more realistic 800 px of height, because real browsers subtract chrome and taskbar. The WCAG number is the normative one, mine is the more pessimistic. Pass mine and you pass theirs too.)*

**This is the point almost everyone misses:** 1.4.10 is not a phone criterion. It is a **zoom criterion**. The person it exists for is sitting at a 1280 px desktop and has zoomed to 400 % because otherwise they cannot read anything.

```text
Desktop, 1280 × 1024 CSS px, 400 % zoom
────────────────────────────────────────
Effective viewport:  320 × 256 CSS px

┌────────────────┐  ← 320px. That is all.
│  [LOGO]   [☰]  │  ← Header, 56px = 22 % (!)
├────────────────┤
│                │
│  The content.  │  ← 200px left
│  All of it.    │
│                │
└────────────────┘
```

Now put a 120 px sticky header in there. That leaves 136 pixels of content.

### 2.4.11 Focus Not Obscured: sticky headers are an AA issue

This is the change many have not caught up with. [SC 2.4.11 Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html) is **new in WCAG 2.2 and Level AA**:

> "When a user interface component receives keyboard focus, the component is not **entirely** hidden due to author-created content."

And the Understanding document names the culprits **explicitly**: "Typical types of content that can overlap focused items are **sticky footers, sticky headers**, and non-modal dialogs."

Read the word "entirely" carefully, because it decides the severity: if a focused element disappears **completely** under your sticky header, that is an **AA violation**. If it is only **partially** covered you still satisfy 2.4.11 — then only [SC 2.4.12 (Enhanced)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-enhanced.html), Level AAA, which permits no obscuring at all, applies.

In practice that is an academic distinction: a tab focus half-wedged under the header is just as unusable for the user. Happily, the standard fix is one line:

```css
html {
	/* Reserve the sticky header's height when scrolling to anchors or focus */
	scroll-padding-top: 4.5rem; /* must match the sticky header height */
}
```

That line is a maintenance trap, though: change the header height and focus visibility breaks silently. So keep the height as **one single custom property** and derive both from it:

```css
:root {
	--header-h: 4.5rem; /* 72px — the ONE place this number lives */
}

.site-header {
	position: sticky;
	top: 0;
	block-size: var(--header-h);
}

html {
	scroll-padding-top: var(--header-h);
}
```

### C34: unstick the header when there is no room

For the height problem there is an **official W3C technique**, and it is refreshingly pragmatic: [C34: Using media queries to un-fixing sticky headers / footers](https://www.w3.org/WAI/WCAG22/Techniques/css/C34), listed as an advisory technique for 1.4.10.

W3C writes there that sticky regions "may block a big portion of the screen" in landscape or under zoom — and: "Disabling, or un-fixing sticky regions, is an effective way to allow for enough available space."

The official proposal ties stickiness to the **available height**, not to width:

```css
/* Only stick when there is vertical room to spare */
@media (min-height: 480px) {
	.site-header {
		position: sticky;
		top: 0;
	}
}
```

**A word of warning about the original:** the W3C technique uses `min-device-width`/`max-device-width` in the second half of its example. Those features are **deprecated** in Media Queries Level 4 — and they query the *screen*, not the *viewport*. So they fail precisely where 1.4.10 needs them most: for the zooming desktop user, whose screen stays large while their viewport shrinks. Use `height` queries consistently instead — they measure exactly what is at stake. The reference implementation in the closing chapter does it that way.

That is a more elegant answer to "how tall may a sticky header be?" than any percentage: **as tall as it must be — and when there is no room, it simply is not sticky.**

### Skip link: mandatory, and increasingly so

[SC 2.4.1 Bypass Blocks](https://www.w3.org/WAI/WCAG22/Understanding/bypass-blocks.html) (Level A) requires a mechanism to skip repeated blocks. The logic is beautifully simple: **the bigger and more nested your header, the more essential the skip link.** A keyboard user forced to tab through fourteen navigation items on every subpage is being actively punished by your header.

```html
<a class="skip-link" href="#main">Skip to content</a>
```

```css
.skip-link {
	position: absolute;
	inset-inline-start: 1rem;
	inset-block-start: -100%;
	z-index: 100;
	padding: 0.75rem 1.25rem;
	background: var(--color-surface);
	transition: inset-block-start 150ms ease;
}

.skip-link:focus-visible {
	inset-block-start: 1rem;
}

@media (prefers-reduced-motion: reduce) {
	.skip-link {
		transition: none;
	}
}
```

### Sliders and motion

If a slider absolutely must live in the header, two hard rules apply.

**[SC 2.2.2 Pause, Stop, Hide](https://www.w3.org/WAI/WCAG22/Understanding/pause-stop-hide.html) (Level A)** — and here is the nuance that is nearly always reported wrongly: the criterion has **two parts**. The famous five-second threshold applies only to the first (moving, blinking, scrolling content). The second part covers **auto-updating** content — and **there is no five-second free pass for that**.

An auto-advancing slider falls under *both* parts: as motion (the slide transition) and as an auto-update (the content change). Consequence: **an auto-rotating carousel always needs a pause mechanism. Always. Level A.**

**`prefers-reduced-motion`** has been available in all browsers since January 2020. MDN names its audience explicitly: people with **vestibular disorders**, for whom "animations involving scaling or panning large objects" can trigger symptoms. A screen-filling, automatically panning hero slider is exactly that case — not a little bit of it, but the textbook example.

```css
@media (prefers-reduced-motion: reduce) {
	.hero-slider {
		/* Do not just slow it down — stop it */
		animation: none;
		transition: none;
	}
}
```

Not "make it slower". Turn it off.

## Part 9: Performance — what the header costs

The header is the first thing that loads. It is therefore the prime suspect whenever [Core Web Vitals](https://www.jpkc.com/db/en/blog/core-web-vitals/) come back red.

### Your hero image *is* your LCP

That is not a guess, that is measured. Per the [Web Almanac 2024, performance chapter](https://almanac.httparchive.org/en/2024/performance):

- **73.3 %** of all mobile pages have an **image** as their LCP element.
- On desktop it is **83.3 %**.

If you have a hero image, it is very likely the element against which Google measures your load time. The target: **LCP ≤ 2.5 seconds** at the 75th percentile.

Two numbers from the same source show how badly this is handled in the field:

- **9.5 %** of all mobile websites set `loading="lazy"` on **their own LCP image**. That is the most expensive one-word mistake on the web. [web.dev](https://web.dev/articles/optimize-lcp) is unambiguous: "Never lazy-load your LCP image."
- Only **15 %** set `fetchpriority="high"` on it (some progress: in 2022 it was 0.03 %).

The recipe is mundane:

```html
<img
	src="/assets/img/hero-1280.webp"
	srcset="
		/assets/img/hero-640.webp   640w,
		/assets/img/hero-1280.webp 1280w,
		/assets/img/hero-1920.webp 1920w,
		/assets/img/hero-2560.webp 2560w
	"
	sizes="(min-width: 80rem) 1280px, 100vw"
	width="1280"
	height="720"
	alt="A meaningful description of the image content"
	fetchpriority="high"
	decoding="async"
>
```

No `loading="lazy"`. `fetchpriority="high"`. `width` and `height` set (against CLS). And: **`w` descriptors with `sizes`, not `x` descriptors.** The difference matters — `x` describes the pixel density *of the image*, `w` its width. For a hero image whose displayed width varies with the viewport, `w` is the right tool ([web.dev: Descriptive syntax](https://web.dev/learn/images/descriptive/)).

**Note the `sizes` attribute.** It deliberately does *not* say `100vw`. The image sits in a container capped at 80rem (1280 px) — exactly as in the reference implementation in Part 12. Write `100vw` here anyway and you tell the browser the image is viewport-wide, so on a 2560 px monitor it dutifully fetches the largest variant for a 1280 px slot. That is the same mistake in a different coat: **`sizes` must describe how wide the image is actually rendered** — otherwise the whole `srcset` effort is wasted. For a genuine full-bleed hero spanning the entire width, `100vw` *is* correct — and then larger variants belong in the `srcset` too.

### The myth everyone trips over

And now the point that turns most performance discussions on their head. Google itself writes in [Common misconceptions about how to optimize LCP](https://web.dev/blog/common-misconceptions-lcp):

> "**Image download time is almost never the bottleneck.**"

Concretely, and I will quote the qualifiers too: for **the majority of origins** with poor LCP, **less than 10 %** of their **p75 LCP time** goes on actually downloading the image. And: the typical site with poor LCP waits **almost four times as long to start the download** as it then spends downloading.

Which means the reflexive advice "compress the hero image harder" is **usually the wrong building site**. The real problem is called *resource load delay* — the browser finds the image too late. And it finds it too late when:

- it is a CSS `background-image` (the preload scanner cannot see it),
- it is loaded via JavaScript (sliders! carousel libraries!),
- it waits behind a render-blocking stylesheet,
- it carries `loading="lazy"`.

**That is another, frequently overlooked argument against JS sliders in the header:** a carousel that loads its images only after hydration pushes the LCP back by construction. Not because of file size — because of start time.

### CLS: the sources of jump in a header

[CLS](https://www.jpkc.com/db/en/blog/core-web-vitals/) should sit at ≤ 0.1. The header-typical culprits are a short but merciless list:

| Cause | Symptom | Fix |
| --- | --- | --- |
| Logo without `width`/`height` | Header pops open on load | Set the dimensions in the HTML, always |
| Webfont swap in the navigation | Nav row gets taller/shorter | Metrically matched fallback font (`size-adjust`, `ascent-override`) — see below |
| Sticky header activated via JS | Content jumps after hydration | Reserve the height in CSS, not in JS |
| Cookie banner in the document flow | Everything below shifts down | Render it as an overlay, not as a block |
| Hero image without `aspect-ratio` | Hero unfolds on load | `width`/`height` or `aspect-ratio` |
| Meta bar appearing only after auth | The whole header slides | Reserve the space from the start |

The common denominator: **reserve the space before you know what goes in it.**

**One more word on the webfont problem**, because the usual advice here cures the disease by killing the patient: `font-display: optional` does eliminate the layout shift — but only because there is **no swap phase at all**. If the font does not load within roughly 100 ms, it is **not applied at all** for that page view. On a typical first visit without cache you simply see the fallback. That is not a solution to the webfont problem, that is its abolition.

The clean route is a **metrically matched fallback font**: you declare a local system font as an `@font-face` and align its metrics to the webfont with `size-adjust`, `ascent-override` and `descent-override`. The fallback then occupies exactly the same box as the real font — and the swap costs not a single pixel of layout shift.

```css
@font-face {
	font-family: 'Fallback';
	src: local('Arial');
	/* Tuned so the fallback occupies the same box as the real font */
	size-adjust: 105%;
	ascent-override: 92%;
	descent-override: 24%;
}

body {
	font-family: 'MyWebfont', 'Fallback', sans-serif;
}
```

You have to measure the actual percentages for your own font — they are not a copy-paste value.

## Part 10: Conversion — what the evidence actually supports

Here I separate the proven from the merely asserted — including where the proven is inconvenient.

### The fold is alive (but it is not a wall)

The most robust study comes from the Nielsen Norman Group: [Scrolling and Attention](https://www.nngroup.com/articles/scrolling-and-attention/), 2018, **120 participants, over 130,000 eye fixations** — collected on **1920×1080 desktop screens**. That is an important limitation I state up front, because I am about to apply the numbers to mobile as well: for smartphones they were **not** measured. The attention gradient probably behaves similarly there (the fold exists at 844 px of height too), but that is not proven.

| Region | Share of viewing time |
| --- | --- |
| Above the fold | **57 %** |
| First two screenfuls | **74 %** |
| First three screenfuls | **81 %** |
| Top 20 % of the page | over 42 % |

And the historical context: in 2010 it was still **80 %** of viewing time above the fold. So the effect has **weakened, but not dissolved**.

That refutes **both** camps:

- "Users do not scroll" is **false**. 81 % of time within three screenfuls means: they scroll. NN/g verbatim: "people will scroll if they have a reason to do it."
- "The fold is dead" is **equally false**. 57 % against 43 % is not a dead effect, it is a massive attention gradient.

**The consequence for the header is direct:** every pixel of header height pushes content out of the 57 % zone. A 160 px header consumes a fifth of the most valuable area of the entire page on an 800 px viewport — for a logo and navigation, that is, for things nobody came looking for. Add a hero at full viewport height and the first *real* content sits entirely below the fold, in the 43 % zone.

### Sliders: the honest state of the numbers

I could make it easy for myself and quote the famous 1 % figure. But it is quoted wrongly, and I would rather report what the source actually says.

The source is Erik Runyon, [Carousel Interaction Stats](https://erikrunyon.com/2013/01/carousel-interaction-stats/), data from 2012/13:

| Website | Click rate on the carousel | Share on first position |
| --- | --- | --- |
| nd.edu (the famous number) | **~1 %** | 84 % |
| three static carousels | 1.7–2.3 % | 48–62 % |
| one **auto-rotating** carousel | **8.8 %** | 40 % |

Read that last row. The *auto-rotating* carousel had the **highest** click rate of all. Anyone writing "carousels convert at 1 %" is quoting selectively against their own source. (Incidentally: the popular site shouldiuseacarousel.com gives the first-slot share as 89 % — the primary source says 84 %. The number was already corrupted on its first retelling.)

**What can nevertheless be shown** — and it is quite enough:

Jakob Nielsen, [Auto-Forwarding Carousels Annoy Users](https://www.nngroup.com/articles/auto-forwarding/), documents a test at Siemens UK in which a participant **simply missed** a prominent £100 discount offer, because the carousel advanced every five seconds. Her words: "I didn't have time to read it. It keeps flashing too quickly."

Nielsen adds: "Because it moves, users automatically assume that it might be an advertisement, which makes them more likely to ignore it." And NN/g measures in [Designing Effective Carousels](https://www.nngroup.com/articles/designing-effective-carousels/) that animated advertising gets looked at only **27 % of the time** — banner blindness hits everything that moves.

There is also accessibility. Jared Smith of WebAIM, quoted on shouldiuseacarousel.com: "Carousels pose accessibility issues for keyboard and screen reader users that simply cannot be adequately addressed by markup or hacks."

**My position, as honest as the data allows:** carousels are not *demonstrably* conversion killers — the evidence for that is weaker than their opponents claim. But they are **expensive**: they cost LCP (JS-loaded images), they cost accessibility (WCAG 2.2.2, keyboard operation), they cost attention (banner blindness) — and **the first position collects 40 to 84 % of all clicks**, with every remaining slide splitting the rest. In exchange they deliver a benefit nobody can measure reliably.

That is not a ban. It is a very bad deal.

If it must exist anyway: **max 5 frames** (NN/g), **no auto-rotate without a pause control** (WCAG 2.2.2, Level A), images **not** loaded via JS, controls **inside** the carousel, and — NN/g's most important advice — "**some people will only see the first frame or none at all**": important content must also appear somewhere else.

### The burger menu on desktop: here the evidence is unambiguous

If I were allowed a single recommendation in this article, it would be this one. The numbers come from [Hamburger Menus and Hidden Navigation Hurt UX Metrics](https://www.nngroup.com/articles/hamburger-menus/), NN/g 2016, **179 participants, 6 websites**:

| Metric (desktop) | Hidden (burger only) | Visible | Combo |
| --- | --- | --- | --- |
| Navigation used | 27 % | **48 %** | **50 %** |
| Time to complete task | **at least 39 % slower** | reference | reference |
| Content discoverability | **over 20 % worse** | reference | reference |
| Perceived difficulty | 21 % higher | reference | reference |

NN/g's recommendation is unusually blunt: "**Do not use hidden navigation (such as hamburger icons) in desktop user interfaces.** Instead display the top-level navigation options."

And the sentence that tells me most: "**Discoverability is cut almost in half** by hiding a website's main navigation."

**And on mobile?** Here it pays to look closely, because the study measures three variants, not two. On mobile, **hidden** navigation was used in 57 % of cases — the **combo** version in **86 %**. "Combo" means: a few important items visible, the rest behind the burger.

That is the actual advice, and it beats "on mobile there is no alternative": **even at 360 px you do not have to hide everything.** One or two load-bearing targets stay visible (the primary CTA, maybe "Contact"), the rest moves into the menu. The pure burger is the weakest of the three options on mobile too — it is merely the most convenient.

**On desktop it is simply aesthetics at the users' expense.** If you have 1400 px of room and still hide your navigation, you are trading away half its discoverability for an icon.

### "7±2 menu items" is a myth

Finally, a rule I hear in almost every design review. Jakob Nielsen himself, in [Short-Term Memory and Web Usability](https://www.nngroup.com/articles/short-term-memory-and-web-usability/):

> "It's a **common misconception** that limited short-term memory implies that menus should be similarly limited to 7 items. **It's fine to have longer menus** (if needed), because users don't have to memorize the full list of menu items."

The reasoning is clean: Miller's 7±2 describes the capacity of **working memory** — things you have to *remember*. You do not have to remember a menu, you **see** it. Menus work on *recognition*, not on *recall*.

Shorter menus are still better — but for a different reason: **scanning speed**. There is no defensible maximum, and I will not invent one. My practical recommendation of 3–7 top-level items is a rule of experience, not a study. I say so, because others do not.

## Part 11: The anti-pattern catalogue

The sins I meet most often in design reviews — each with its reference in the article:

| # | Anti-pattern | Why it hurts |
| --- | --- | --- |
| 1 | **Design needs an XXXL breakpoint** | Beyond 1920 CSS px you reach about 4 % of your visitors. Not even a MacBook Pro clears 1536. → Part 4 |
| 2 | **Designed on a 32" monitor, never checked smaller** | A sample size of one — drawn from the hardware bubble developers live in. → Part 1 |
| 3 | **`100vh` hero** | Simply miscalculated on mobile, and a "false floor". → Parts 3, 6 |
| 4 | **Sticky header over 96 px** | At 400 % zoom there is barely any content left. → Parts 6, 8 |
| 5 | **Sticky header without `scroll-padding-top`** | If the tab focus vanishes *entirely* beneath it: AA violation (SC 2.4.11). Partially covered: AAA. Both unusable. → Part 8 |
| 6 | **Burger menu on desktop** | At least 39 % slower, over 20 % worse discoverability. → Part 10 |
| 7 | **Two equal-ranking CTAs** | Two priorities are no priority. → Part 5 |
| 8 | **Auto-rotating slider without pause** | WCAG 2.2.2, Level A. No room for discretion. → Part 8 |
| 9 | **Hero image loaded via JS/CSS background** | The preload scanner cannot find it → LCP wrecked. → Part 9 |
| 10 | **`loading="lazy"` on the LCP image** | The most expensive one-word mistake on the web. 9.5 % of all **mobile** pages make it. → Part 9 |
| 11 | **Logo without `width`/`height`** | A direct CLS source, on every single page view. → Part 9 |
| 12 | **`font-size` in pure `vw`** | W3C failure F94, breaks WCAG 1.4.4. → Part 6 |
| 13 | **`sizes="100vw"` with a capped container** | The browser fetches the largest image variant for a small slot. → Part 9 |
| 14 | **A meta bar "because there's room"** | Every pixel at the top pushes content out of the 57 % zone. → Part 10 |
| 15 | **Header grows with the CMS** | The technology permits more than the design can bear. → Part 4 |

## Part 12: A header that follows the rules

To close, the summary as code. This is not a framework, it is the skeleton — the numbers in it are the ones from Part 6.

```css
:root {
	/* Single source of truth — everything else derives from this.
	   These are the TOP of the sticky ranges from part 6 (48–56 / 56–72),
	   because this header sticks. A static header may go higher. */
	--header-h: 3.5rem; /* 56px mobile */
	--content-max: 80rem; /* 1280px */
}

@media (min-width: 48rem) {
	:root {
		--header-h: 4.5rem; /* 72px desktop */
	}
}

/* --- Header ------------------------------------------------------ */

.site-header {
	block-size: var(--header-h);
	/* Full-bleed background, bounded content */
	background: var(--color-surface);
}

.site-header__inner {
	display: flex;
	align-items: center;
	justify-content: space-between;
	gap: clamp(1rem, 3vw, 2.5rem);
	max-inline-size: var(--content-max);
	margin-inline: auto;
	padding-inline: clamp(1rem, 4vw, 3rem);
	block-size: 100%;
}

/* Only stick when there is vertical room to spare (W3C technique C34).
   Below 480px of viewport height — landscape phones, heavy zoom — the
   header is not worth its height, so it scrolls away like normal content.
   Note: height queries, not the deprecated device-width ones C34 uses. */
@media (height >= 480px) {
	.site-header {
		position: sticky;
		inset-block-start: 0;
	}

	/* Focus and anchors must clear the sticky header (WCAG 2.2 SC 2.4.11) */
	html {
		scroll-padding-block-start: var(--header-h);
	}
}

/* --- Navigation -------------------------------------------------- */

.nav__link {
	/* WCAG 2.5.8 requires 24px; Apple/Material say 44–48. Use the latter. */
	min-block-size: 2.75rem; /* 44px */
	display: inline-flex;
	align-items: center;
	padding-inline: 0.75rem;
	font-size: 1rem;
}

/* --- Hero -------------------------------------------------------- */

.hero {
	/* svh, not vh: guaranteed visible even with mobile toolbars out.
	   Capped at 60% so the next section always peeks above the fold. */
	min-block-size: 60svh;
	display: grid;
	align-content: center;
}

.hero__title {
	/* rem min/max keeps user zoom working (avoids W3C failure F94).
	   Max is exactly 2× min, as MDN requires for 200% scalability. */
	font-size: clamp(1.75rem, 4vw, 3.5rem);
	text-wrap: balance;
}
```

And the result, as the user sees it:

```text
 360px (phone)             1280px (laptop)                 2560px (WQHD)
┌────────────┐         ┌──────────────────────┐    ┌────────────────────────────────┐
│[Logo]  [☰] │  56px   │[Logo]  Nav…   [CTA]  │72px│      [Logo]  Nav…   [CTA]      │ 72px
├────────────┤         ├──────────────────────┤    ├────────────────────────────────┤
│            │         │                      │    │        │                │      │
│  H1        │  60svh  │   H1                 │    │ margin │   H1           │margin│
│  Teaser    │         │   Teaser             │    │        │   Teaser       │      │
│  [Action]  │         │   [Action]           │    │        │   [Action]     │      │
│            │         │                      │    │        │                │      │
├─ ─ ─ ─ ─ ─ ┤         ├─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤    ├─ ─ ─ ─ ┼─ ─ ─ ─ ─ ─ ─ ─ ┼ ─ ─ ─┤
│▓ content ▓ │         │▓▓ content ▓▓         │    │        │▓▓ content ▓▓   │      │
└────────────┘         └──────────────────────┘    └────────────────────────────────┘
                                                    ↑ The space becomes MARGIN,
                                                      not content.
                                                      No XXXL breakpoint needed.
```

That is the whole trick. Beyond ~1300 px it is not the content that grows, it is the margin. Which is why no sensible design needs an XXXL breakpoint — and why a design that *needs* one is not a sensible design.

## Review checklist to take with you

To tick off before every sign-off. **Use the copy button at the top right of the block** — you get ready-made Markdown with working checkboxes that you can paste straight into your ticket, your pull-request template, your notes app or your acceptance protocol.

```markdown
# Header review — checklist

Source: https://www.jpkc.com/db/en/blog/header-groessen/

## Dimensions
_(Recommendations from the article, derived — not standards)_

- [ ] Header MOBILE  ≤ 64 px (sticky) or ≤ 72 px (static)?
- [ ] Header DESKTOP ≤ 96 px (sticky) or ≤ 120 px (static)?
- [ ] Hero ≤ 70 svh, with a visible content sliver below it?
- [ ] No `100vh` / `100svh` hero without a compelling reason?
- [ ] Content container capped at ≤ 1440 px (framework corridor: 1280–1320)?
- [ ] Header background may be full-width — but the CONTENT is capped?
- [ ] Layout works at 1280, 1024, 768, 440 and **320** CSS px?
- [ ] No breakpoint beyond 1536 px needed?

## Accessibility
_(Criterion numbers = actual WCAG requirements)_

- [ ] 400 % zoom at 1280 px: no horizontal scrolling? (WCAG 1.4.10, AA)
- [ ] Text resizable to 200 % without loss of content/function? (1.4.4, AA)
- [ ] Header does not eat half the viewport under heavy zoom? _(own derivation)_
- [ ] Tab focus never disappears under the sticky header?
      `scroll-padding-top` = header height? (2.4.11, AA in WCAG 2.2)
- [ ] All click targets ≥ 24 px? (2.5.8, AA in WCAG 2.2)
- [ ] Icon buttons 44–48 px? (2.5.5 AAA / Apple 44 pt / Material 48 dp)
- [ ] Skip link present and visible on focus? (2.4.1, A)
- [ ] Stickiness disabled at low viewport height? (technique C34)
- [ ] Moving elements can be paused? (2.2.2, A)
- [ ] `prefers-reduced-motion` respected — animation OFF, not just slower?
- [ ] No font size in pure `vw` (W3C failure F94)?
      `clamp()` maximum ≥ 2 × minimum?

## Performance
- [ ] Hero image: NO `loading="lazy"`, but `fetchpriority="high"`?
- [ ] Hero image in the HTML — not a CSS background, not JS/slider-loaded?
- [ ] `srcset` with `w` descriptors?
- [ ] `sizes` describes the REAL rendered width (not a blind `100vw`)?
- [ ] Logo and all header images with `width`/`height`?
- [ ] No JS required for the header to get its height?
- [ ] Webfont: metrically matched fallback instead of a layout shift?
- [ ] Cookie banner as an overlay — not in the document flow?

## Conversion
- [ ] Exactly ONE primary CTA?
- [ ] Navigation visible on desktop — no burger?
- [ ] On mobile: at least one load-bearing target visible next to the burger?
- [ ] `<h1>` says what this is about — not a claim without content?
- [ ] If a slider: max 5 frames, no auto-rotate without a pause control,
      content also reachable somewhere else?

## The self-test that exposes everything
- [ ] Opened at 320 px wide — and it still works?
- [ ] Opened at 400 % zoom — and the header does not eat everything?
- [ ] Operated by keyboard only — and the focus is always visible?
```

That last block is the most important. **Those three moves take under two minutes together and expose more than any audit tool.** If a design survives them it is usually fine elsewhere too. If it does not, you know immediately where to look.

## Conclusion

The suspicion from the introduction was right — though for a different reason than expected.

The reason is not primarily that too few people own large monitors. The reason is that **large monitors do not produce large CSS viewports.** A 4K panel delivers 1920 or 2560 CSS pixels in the browser, depending on scaling — the four million extra pixels go entirely into sharpness. A MacBook Pro 14" delivers 1512. "How many people have 4K?" is therefore the wrong question. The right one is: "**How many have more than 1920 CSS pixels of width?**" And the answer from the German figures: about **7 % of desktop visitors** — that is roughly **4 % of all visitors**.

**A design that needs true XXXL widths is therefore not ambitious. It is built past 96 % of its audience.**

That such designs get made anyway is not malice. It is a **sample size of one**: we have the good monitors. The Steam survey shows what that hardware bubble looks like — a good third of gaming PCs run a panel beyond Full HD. And even that panel delivers no corresponding area in the browser once scaling kicks in. Whoever tests only on their own machine tests the bubble — and does not even see there what their CSS really gets.

The fix is astonishingly unspectacular in the end. It is not called "one more breakpoint", it is called **`max-width`**. Beyond roughly 1300 pixels, space becomes margin, not content. That is exactly what Bootstrap (1320 px) and Tailwind (`max-w-7xl`, 1280 px) have been demonstrating for years. They did not forget to add a `3xl` breakpoint. They decided against one.

And for everything below, an even simpler rule applies: **every pixel of header height is taken from the content** — from precisely the content that receives 57 % of the attention, that fights for 200 pixels of room at 400 % zoom, and that decides conversion. A header is not a design canvas. It is a tax you pay on every single page.

Pay it as low as you can.

---

## Sources and data as of

All market-share and resolution data: **StatCounter GlobalStats, collection month June 2026** (Germany and worldwide). StatCounter measures page views, not people, uses no weighted panel, and revises figures for up to 45 days — the numbers are reliable orders of magnitude, not official statistics. The **Steam Hardware Survey** (also June 2026) measures *physical* panel resolutions and is therefore **not directly** comparable with StatCounter's CSS-pixel values; it appears here solely as evidence for the hardware in the enthusiast population.

Framework versions at the time of research: **Bootstrap 5.3.8**, **Tailwind CSS 4.3.2**.

Criterion numbers follow **WCAG 2.2**. On the legal situation see Part 8: what is binding in Germany today is EN 301 549 v3.2.1 with **WCAG 2.1 AA** — the 2.2 additions (2.4.11, 2.5.8) are not yet in force.

**Where this article uses its own derivations rather than sources, that is marked** — in particular the header-height limits in Part 6, the element recommendations in Part 5 and the menu-item count in Part 10. There is neither a WCAG requirement nor an NN/g study on maximum header height. Anyone selling you a percentage as "the standard" made it up — including if that anyone is me.

This article went through an [adversarial factual review](https://www.jpkc.com/db/en/blog/faktentreue-review/) before publication: every verifiable claim was tested with the goal of **refuting** it. Several numbers and two conclusions did not survive and were corrected.

Further reading on this blog: [Core Web Vitals & Performance](https://www.jpkc.com/db/en/blog/core-web-vitals/) for the measurement methodology behind LCP and CLS, and [Technical SEO](https://www.jpkc.com/db/en/blog/technical-seo/) for the wider technical frame.