iOS Safari fixed backgrounds: a static-image fallback
AI-assisted editorial resource. Sources listed below.
A fixed background can behave differently in iOS Safari than on desktop. Start with a static-image baseline, then test any scrolling effect on the browsers and devices you support.
What the documented Safari issue actually says
WebKit issue 275247 describes a background that scrolls with the page on iOS rather than remaining fixed as it does on macOS. The report identifies iOS 17.4; the tracker was open when checked on October 15, 2026.
MDN defines background-attachment: fixed relative to the viewport. That is different from an ordinary image positioned inside a section. Decide whether you need the scrolling effect or simply need the image and content to remain visible.
Keep a static image as the baseline
The example below keeps an image in the section and adds a separate fixed-background layer as an optional enhancement. Replace the image path with an asset that exists in your project. The checkbox lets you compare the effect without adding a scroll-event script.
The fixed layer is shown only after opting in, at a wide viewport with hover and a fine pointer, when reduced motion has not been requested. Those conditions describe layout and input preferences. They do not identify Safari or prove support.
<!doctype html>
<html lang="en">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Static image with optional fixed background</title>
<style>
body { margin: 0; font: 1rem/1.5 system-ui; }
label { display: block; padding: 1rem; }
.hero { position: relative; min-height: 24rem; overflow: hidden; background: #172f3d; }
.hero-image, .fixed-layer { position: absolute; inset: 0; width: 100%; height: 100%; }
.hero-image { object-fit: cover; }
.fixed-layer { display: none; background: url('/images/hero.svg') center / cover no-repeat fixed; }
.hero-copy { position: relative; padding: 3rem 1rem; color: white; background: rgb(0 0 0 / .55); }
.after { min-height: 100vh; padding: 1rem; }
@media (min-width: 64rem) and (hover: hover) and (pointer: fine) and (prefers-reduced-motion: no-preference) {
#try-fixed:checked ~ .hero .fixed-layer { display: block; }
}
</style>
<body>
<label for="try-fixed">Try the optional fixed background</label>
<input type="checkbox" id="try-fixed">
<section class="hero" aria-label="Image example">
<img class="hero-image" src="/images/hero.svg" alt="" width="1600" height="900">
<div class="fixed-layer" aria-hidden="true"></div>
<div class="hero-copy"><h1>Your section heading</h1><p>Your section content.</p></div>
</section>
<div class="after">Scroll to compare the background behavior.</div>
</body>
</html>The underlying image stays in the markup in both states. object-fit: cover fills its box while preserving aspect ratio, which can crop the image. Choose an image and crop that still make sense at narrow and wide sizes.
The media query uses prefers-reduced-motion to leave the static baseline in place when reduced motion is requested.
A support query is not a rendering test
@supports checks support for a CSS declaration. WebKit issue 196327 specifically discusses the mismatch for background-attachment: fixed on iOS. A positive feature-query result is not a substitute for observing the background while the page scrolls.
Troubleshoot the image and the effect separately
- Check the image asset and the size of its containing section before changing the scrolling behavior.
- Compare the static version with the optional fixed layer. Record which version has the problem.
- Check cropping independently of attachment. Background sizing and the section dimensions can change which part of an image is visible.
- Check whether another rule overrides the image, visibility, position or sizing. Keep responsive styling in a place where you can inspect the active rules.
- If the problem belongs to a framework image component, investigate that component separately. This HTML/CSS example does not establish a universal cause for framework rendering bugs.
Test the devices you intend to support
Chrome describes Device Mode as an approximation of a mobile experience, not code running on a mobile device. A desktop viewport preview alone does not validate Safari rendering on an iPhone or iPad.
- Record the browser version, device, viewport and orientation for each check.
- Load the static version first. Check that its image, heading and controls are visible.
- Where the example permits it, opt into the fixed layer and scroll. Compare the result with the static version.
- Repeat with reduced motion enabled and with the page rotated or resized.
- Keep the static version if the optional effect does not behave acceptably on a browser you support.