Header Sizes: How Big Should a Website Header Be?

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 and 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 and 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, 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):

• 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, 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).

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, "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:

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, MacBook Air). 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 and Use Your Loaf — 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:

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 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). 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). 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). 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:

┌─────────────────────────────────────────────────────────────┐
│ 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 — 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:

// 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):

Unit	Meaning
lvh	Large — all browser bars retracted (the optimistic case, equals vh)
svh	Small — all browser bars extended (the pessimistic, guaranteed-visible case)
dvh	Dynamic — 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. 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 and 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.

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:

@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:

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:

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:

.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()).

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).

The framing that matters here comes from Una Kravets at Google (web.dev: The 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

┌────────────────────────────────────────────────────────────────────┐
│ ◇ 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

┌──────────────────────────┐  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:

                       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:

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: 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" — 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), 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), 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: "Create controls that measure at least 44 points x 44 points."
• 48 dp — Android Accessibility Help: "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): "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:

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.

/* 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 */
	}
}

/* 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 (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.

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) 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), 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:

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:

: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, 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:

/* 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 (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.

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

.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 (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.

@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 come back red.

Your hero image is your LCP

That is not a guess, that is measured. Per the Web Almanac 2024, performance chapter:

• 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 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:

<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).

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:

"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 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.

@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, 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, 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, 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 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, 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:

"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.

: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:

 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.

# 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 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 for the measurement methodology behind LCP and CLS, and Technical SEO for the wider technical frame.