What iOS 26 Safari puts behind the clock

The problem

On iOS 26, a web page in Safari can run edge to edge: content scrolls up behind the status bar, under the clock, the battery icon and the camera cut-out (the Dynamic Island), the way native apps do. It is one of the nicest things about the new Safari, and it is why a page can feel like an app.

Most sites don’t get it. Scroll them up and, instead of the page, you see a flat band of colour sitting behind the clock. Sometimes it matches the header, sometimes it is a colour from somewhere else on the page, and sometimes it gets stuck on an old colour until you refresh.

Our own site did all three. The page showed behind the clock in light mode, but not reliably. In dark mode it never did. And on the homepage, whose sections pin in place while you scroll, the strip froze partway down the page. Apple doesn’t document how Safari decides, so we tested it.

How we tested

We built one test page with a colourful, scrolling background, so anything showing behind the clock is obvious, and 26 versions of its top edge. Each version changed exactly one thing: whether the header is pinned, how it is pinned, how far down it starts, what its background is, whether it takes taps. We opened each version on an iPhone running iOS 26, in an ordinary Safari tab (not a home-screen web app), scrolled up, and recorded one thing: does the page show behind the clock, or does Safari paint a strip?

Changing one thing at a time matters here. Real headers change several things at once, and the fixes people share online usually do too, so it is hard to tell which change did the work.

The results

Three results surprised us. A see-through, blurred header, the look most sites reach for, is painted as a solid strip: Safari treats a translucent colour as opaque. A coloured bar just 1px down still counts, so the check is not on the very top row of pixels. And a colour that fades in from fully transparent at the top edge still counts, because the element itself starts at the top.

The rule

Put together, the results describe one check. WebKit’s source code (the function LocalFrameView::fixedContainerEdges) matches what we measured:

• Safari looks at one thin band, about 4px below the top of the screen, in the middle.
• It walks up from whatever is there to the first pinned element: position: fixed or sticky. If nothing pinned is there, the page shows behind the clock. That is why a bar starting 10px or 24px down, or an ordinary scrolling page, is fine.
• It ignores pinned elements that are narrower than about 90% of the screen, or 10px thick or less. Small floating buttons at the top don’t count.
• It skips a pinned element that is invisible and ignores taps: transparent, hidden or fully faded, with pointer-events: none. This is the opening that lets you keep a pinned header and still show the page.
• Otherwise, that element owns the status bar. If it has a plain background colour, Safari paints it, and paints it opaque, even if it is 70% see-through. If it has no plain colour (a gradient, an image, a colour on a ::before), Safari takes a colour sample instead.

The frozen strip

The sample is the part that makes this feel random. When the pinned element at the top has no plain colour to read, Safari samples it once, and keeps that colour for as long as the same element stays on top. Scroll on, and the page under the strip changes while the strip doesn’t.

That was our homepage bug. Its scroll scenes pin in place, one after another. When the site’s header slid away, the first scene became the top pinned element, Safari sampled it, and the strip stayed that colour through the rest of the page. A refresh fixed it, until it happened again. It also explains the reports that a site “works after a refresh”.

A plain background colour isn’t sampled. It is read again every time Safari re-checks, so a solid header at least stays in sync with itself. It just never lets the page through.

What doesn’t work

• theme-color. It made no difference to what showed behind the clock in a Safari tab.
• A translucent, blurred header. Painted solid.
• Moving the colour onto a ::before, a gradient or a background image. Sampled, and then possibly frozen.
• A header that fades from transparent at the top. The element still starts at the top edge.
• Pinning a scene above the screen to fill the camera area. Safari never drew pinned content there, even 80px above the top. Only normal, scrolling content passes behind the status bar.

How we designed around it

We wanted the page visible behind the clock everywhere, in light and dark mode. The rule left us three tools, and each part of the site uses one of them.

On desktop: a header Safari skips

The desktop header is pinned at the top and fully transparent. The bar itself ignores taps; the logo, links and buttons inside it turn taps back on. Safari’s check finds a transparent element that ignores taps and moves past it, so the page shows through, and nothing about the header works differently for the reader.

.nav { position: fixed; top: 0; left: 0; right: 0;
       background: transparent;
       pointer-events: none; }   /* Safari skips the bar */
.nav > * { pointer-events: auto; }  /* its buttons still work */

On phones: no bar, two floating pills

On phones there is no header bar at all. The logo and the Menu button are two separate floating pills, 12px below the top of the safe area. They are narrower than 90% of the screen and they start below the band Safari checks, so they are ignored twice over.

The pills are a tint of the page background at 86%, not a blur. A blur over the moving hero behind them has to be redrawn every frame, which is expensive and warms up phones. Each pill has a hairline border in the text colour at 9%, a thin highlight along its top edge and a soft shadow, so it reads as glass without blurring anything. When you scroll down, the pills fade out and lift 4px instead of a bar sliding away, and they come back when you scroll up.

.logo, .menu-btn {
  position: fixed;
  top: calc(env(safe-area-inset-top) + 12px);  /* below the check */
  height: 44px; border-radius: 999px;
  background: color-mix(in srgb, var(--bg) 86%, transparent);
  border: 1px solid color-mix(in srgb, var(--ink) 9%, transparent);
  box-shadow: inset 0 1px 0 rgb(255 255 255 / .55),
              0 12px 28px -18px rgb(20 10 35 / .5);
}

For scroll scenes: hide the box, keep the content

Our homepage scenes pin in place while their content animates, and they fill the screen, so they sit right at the top edge. We made the scene’s own box visibility: hidden and made everything inside it visible again. Visually nothing changes, but to Safari’s check the pinned element is now hidden, so it is skipped. The scenes are animation only, so they also ignore taps, down to every element inside them. A live child under the check point would otherwise be what Safari hits.

.scene            { position: sticky; top: 0;
                    visibility: hidden; pointer-events: none; }
.scene *          { pointer-events: none; }
.scene > *,
.scene::before    { visibility: visible; }  /* still drawn */

One limit stays: Safari won’t draw pinned content in the camera area, so while a scene is pinned, the strip shows whatever scrolls above it rather than the scene itself. The hero and every normal section pass behind the clock as intended.

Everywhere else: start coloured bars 12px down

Where we do want a solid, coloured bar, such as the documentation’s header, it starts 12px down, and when it hides on scroll it stops 12px short of the top instead of sliding flush to it. The store dashboard uses the same tap-through header as the site, with a floating bar on smaller screens.

Check your own site

This snippet asks the browser the same question Safari asks: what pinned element sits at the top-centre of the screen, and would it be skipped? Paste it into the console with the page scrolled to where the problem appears. It is an approximation of Safari’s check, not a copy of it.

(() => {
  for (const hit of document.elementsFromPoint(innerWidth / 2, 5)) {
    for (let el = hit; el && el !== document.documentElement; el = el.parentElement) {
      const cs = getComputedStyle(el)
      if (cs.position !== 'fixed' && cs.position !== 'sticky') continue
      const r = el.getBoundingClientRect()
      return console.log('Safari will judge this element:', el, {
        widthShare: +(r.width / innerWidth).toFixed(2),   // under 0.9 is ignored
        background: cs.backgroundColor, image: cs.backgroundImage,
        pointerEvents: cs.pointerEvents, visibility: cs.visibility })
    }
  }
  console.log('Nothing pinned at the top: the page shows behind the status bar.')
})()

Because elementsFromPoint passes over elements that ignore taps, a header you have already fixed with pointer-events: none won’t be reported, which is what you want. We ran the same check in a headless browser at each step of a scroll down our homepage, and fixed things until it found nothing.

Questions people ask

What we learned

1. 1
   Safari decides from one band near the topWhatever pinned element is there, full width, owns the status bar. Keep it transparent and tap-through, or keep it out of the way.
2. 2
   Translucent is not transparentA 70% see-through blurred header is painted as a solid strip.
3. 3
   12px is enoughPinned bars that start 12px down, or are narrower than 90% of the screen, don’t count.
4. 4
   A sampled colour goes staleAnything without a plain background colour is sampled once and kept. That is the “works after refresh” bug.
5. 5
   Change one thing per testReal headers change several things at once. Twenty-six versions, each with one change, made the rule visible.

The result is small and it is easy to miss when it works: the page runs up behind the clock and the camera, in light and dark, on every page. It is also the kind of detail that makes a website feel like it belongs on the phone.

HawkShift Research · September 24, 2026. Numbers are from our own tests while building Concierge; small samples are marked as small.