Why Is My CSS Grid Layout Breaking on Older Apple Safari Browsers?

You built a clean CSS Grid layout. It looks perfect in Chrome and Firefox. Then you open it on an older iPhone or an old Mac, and the whole thing falls apart. Items overlap. Columns collapse. Gaps disappear. Your heart sinks a little.

You are not alone, and you did nothing wrong. Older versions of Apple Safari handle CSS Grid in slightly different ways than modern browsers do. Some features need prefixes. Some properties never shipped. Some behave in surprising ways.

This post explains why this happens and how to fix it. You will get clear steps, simple code patterns, and the pros and cons of each method. Let’s get your grid working everywhere.

In a Nutshell:

• Old Safari supports Grid, but not perfectly. Safari versions before 10.1 do not support CSS Grid at all. Versions 10 and 10.1 support it with quirks and prefixes. This is the root of most problems.
• Vendor prefixes matter on old WebKit. Properties like min-content and max-content needed the -webkit- prefix in Safari 10. Missing prefixes cause silent failures.
• The gap property is a major trap. On iOS Safari below 14.5, gap worked only inside Grid, not Flexbox. Mixing the two layouts caused broken spacing.
• Feature queries are your best friend. The @supports rule lets you write a modern grid and a safe fallback in the same file. This protects users on both old and new browsers.
• Always test on real devices or emulators. A simulator or a tool like BrowserStack shows the true result. Guessing wastes hours.
• Progressive enhancement beats hacks. Build a simple layout that works first, then layer Grid on top for capable browsers.

Understanding Which Safari Versions Actually Support CSS Grid

First, let’s clear up the confusion. CSS Grid is well supported in modern Safari. The trouble lives in older versions.

Safari versions 3.1 through 10 do not support CSS Grid at all. Safari 10.1, released in March 2017, was the first version with real Grid support. Every version after that supports Grid well.

So if your layout breaks, the user is likely on Safari 10, Safari 10.1, or an early iOS Safari build. These versions either ignore Grid completely or carry small bugs.

Knowing the exact version helps you choose the right fix. You do not need to support Safari 9 in 2026 for most projects. But you may still see traffic from Safari 10 era devices, old iPads, and locked down corporate machines. Check your analytics before deciding how far back to support.

Why Your Grid Looks Fine in Chrome but Breaks in Safari

This is the most common question, and the answer is simple. Chrome and Safari use different rendering engines. Chrome uses Blink. Safari uses WebKit.

Older WebKit shipped Grid features at a different pace than Blink did. A property that worked in Chrome in 2017 sometimes needed a prefix in Safari, or had not landed yet.

For example, Safari 10 marked min-content, max-content, and fit-content as prefixed values. Chrome accepted them without a prefix. So your grid-template-columns: max-content worked in Chrome and failed in old Safari.

The lesson is clear. “Works in Chrome” does not mean “works everywhere.” Each engine has its own bug list and its own timeline. Treat Safari as a separate target during testing, not as an afterthought. This single mindset shift prevents most surprises.

Adding Vendor Prefixes the Right Way

Vendor prefixes are the classic fix for old WebKit issues. In Safari 10, intrinsic sizing keywords needed the -webkit- prefix to work inside grid tracks.

Here is the safe pattern. You write the prefixed value first, then the standard value second.

.grid {
  display: grid;
  grid-template-columns: -webkit-min-content 1fr;
  grid-template-columns: min-content 1fr;
}

The browser reads both lines. Old Safari uses the prefixed line. Modern browsers override it with the standard line. This order matters, so never reverse it.

Pros: This method is small, fast, and needs no JavaScript. It targets the exact bug without changing your layout structure.

Cons: You must remember every prefixed property by hand. Writing prefixes manually is easy to get wrong, and it clutters your stylesheet. For a large project, this becomes hard to maintain, which leads us to the next, better option.

Using Autoprefixer to Handle Prefixes Automatically

Writing prefixes by hand is tiring and error prone. Autoprefixer solves this for you. It is a PostCSS plugin that reads your CSS and adds the right prefixes based on your browser targets.

You set your target browsers in a .browserslistrc file or in package.json. For example, last 2 versions or Safari >= 10. Autoprefixer then adds prefixes only where they are needed.

One important note. Autoprefixer disables Grid prefixing by default. If you want the old IE and early WebKit grid support, you enable it with a control comment like /* autoprefixer grid: autoplace */ at the top of your file.

Pros: It is automatic, accurate, and tied to real browser data. You stop thinking about prefixes and focus on layout. It updates as browser support changes.

Cons: It adds a build step to your project. Beginners on plain HTML and CSS may find the setup confusing at first. The Grid support it adds is also limited and best for simple layouts, not complex auto placement.

Solving the gap Property Problem in Older Safari

The gap property causes huge confusion. Here is the key fact. On iOS Safari below 14.5, gap worked only with Grid, not with Flexbox.

So if you used gap inside a Flexbox container, your spacing vanished on those older devices. The items squashed together with no room between them.

The reliable fix is margins. You give each child a margin and remove it from the last item. This recreates the spacing without relying on gap.

.flex-item {
  margin-right: 16px;
}
.flex-item:last-child {
  margin-right: 0;
}

For Grid itself, gap and grid-gap are well supported once you reach Safari 10.1. The trouble is mostly a Flexbox story that gets blamed on Grid.

Pros: Margins work in every browser ever made. The fix is simple and predictable.

Cons: Margins need more code than a single gap line. Managing the last child rule across wrapping rows can get fiddly. Still, this method is dependable when you need broad support.

Writing Feature Queries with @supports for Safe Fallbacks

This is the cleanest modern technique, and it deserves your attention. The @supports rule checks if a browser understands a feature before applying it. You build a fallback first, then enhance.

.container {
  display: flex;
  flex-wrap: wrap;
}

@supports (display: grid) {
  .container {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
  }
}

Old Safari that lacks Grid uses the Flexbox version. Browsers that support Grid use the grid version. Nobody sees a broken page.

You can also test for a specific quirk. For the old Flexbox gap issue, developers used a clever query combining -webkit-touch-callout and translate to target only old iOS Safari.

Pros: This is the official, future proof way to handle support gaps. It keeps fallback and enhancement together and readable. No JavaScript needed.

Cons: You write your layout logic twice, once as fallback and once as enhancement. This takes more thought. But the payoff in reliability is worth it.

Building a Solid Flexbox Fallback Layout

When Grid is not available, Flexbox is your best replacement. It is supported much further back than Grid, including in Safari versions that have no Grid at all.

The idea is to define your layout with Flexbox as the base. Then add Grid on top with @supports for browsers that can use it. Old Safari keeps the Flexbox view and still looks good.

.cards {
  display: flex;
  flex-wrap: wrap;
}
.card {
  flex: 1 1 300px;
}

This gives you wrapping columns that resize. It is not as powerful as Grid, but it is clean and reliable.

Pros: Wide browser support, including very old Safari. Flexbox handles rows and wrapping well, which covers many common layouts like card grids and navigation bars.

Cons: Flexbox cannot do true two dimensional layouts. Aligning items across both rows and columns is harder than with Grid. Complex magazine style designs need extra effort and may not match the Grid version exactly.

Avoiding the min-content and max-content Trap

We touched on this earlier, but it deserves its own section because it bites so many developers. In Safari 10, the keywords min-content, max-content, and fit-content were prefixed.

If you wrote grid-template-columns: max-content auto without a prefix, Safari 10 ignored that track sizing. Your columns then sized in a way you did not expect.

The fix is the double declaration we saw before. Write the prefixed version, then the standard version.

grid-template-columns: -webkit-max-content auto;
grid-template-columns: max-content auto;

Test this carefully on a real old device. The bug is silent, meaning no error appears. The layout just looks wrong, which makes it hard to spot.

Pros: A two line fix fully solves the issue with no build tools.

Cons: You must remember to add it for every intrinsic sizing value across your whole stylesheet. Autoprefixer handles this better at scale, so reach for that on bigger projects.

Watching Out for auto-fit, auto-fill, and minmax Bugs

Responsive grids often use repeat(auto-fit, minmax(200px, 1fr)). This is powerful, but it has caused trouble in some Safari builds.

Older and even some newer Safari versions sometimes mishandle auto-fit and minmax together, especially with containment or container queries. Columns can collapse to zero width or stack oddly.

A common fix is to add explicit fallback properties. Set grid-auto-flow and grid-auto-rows to guide the browser.

.grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
  grid-auto-flow: row;
  grid-auto-rows: 1fr;
}

Also remember a key rule. You cannot nest repeat() notation, and auto-fit cannot combine with intrinsic sizes inside the same repeat. Breaking these rules causes failures in all browsers, not just Safari.

Pros: Adding explicit flow and row properties stabilizes tricky responsive grids with little extra code.

Cons: It does not fix every Safari containment bug. Some cases need you to move the layout to a wrapper element, which can hurt your HTML structure.

Testing on Real Devices and Emulators

You cannot fix what you cannot see. Guessing about Safari behavior wastes hours. The smart move is to test on the real thing.

If you own a Mac, the built in Safari Technology Preview and the Develop menu let you simulate older user agents and inspect rendering. On iOS, the Simulator inside Xcode runs different iOS versions.

For broad coverage without buying devices, browser testing services let you run real Safari versions in the cloud. You pick a version, load your page, and see the true result.

Always reproduce the bug before you write a fix. Create a small test case with only the broken grid. This removes noise and shows the real cause.

Pros: Real testing gives you certainty. You see the exact break and confirm your fix actually works.

Cons: Owning many devices costs money and space. Cloud services have ongoing fees. Setting up Xcode and simulators takes time and disk space, which can frustrate beginners.

Using Progressive Enhancement as Your Core Strategy

Progressive enhancement is the mindset that ties everything together. You start with content that works for everyone, then add power for capable browsers.

Instead of building a fancy Grid layout and patching it for old Safari, you flip the order. Build a simple, readable layout first. It might use normal block flow or Flexbox. Everyone can use it.

Then you wrap your Grid code in @supports (display: grid). Modern browsers get the upgraded layout. Old Safari keeps the basic version and never breaks.

This approach means your site is never fully broken, only less fancy on old browsers. That is a far better outcome than overlapping, unreadable content. Users on old devices still reach your content and complete their goals.

Pros: Your site stays usable everywhere. The code is logical and easy to reason about. It future proofs your work.

Cons: You design the layout in two passes, which takes planning. The old browser view will look plainer than the modern one, so you must accept some visual difference.

Cleaning Up Common Grid Mistakes That Look Like Safari Bugs

Sometimes the browser is innocent. Many “Safari bugs” are really errors in your own code. Before you blame WebKit, check these common slips.

First, confirm your grid container actually has display: grid. A typo here breaks everything. Second, check that grid items are direct children of the container. Grid only affects direct children, not nested elements.

Third, watch your track counts. If you define three columns but place items at column four, the layout pushes into implicit tracks and looks wrong. Count your lines carefully.

Fourth, certain elements like fieldset and button historically could not act as grid containers in some browsers. Use a plain div if you hit this.

Pros: Checking your own code is free and fast. You often find the real problem in minutes.

Cons: It requires patience and honesty. It is tempting to blame the browser, but a clean reduced test case usually reveals the truth and saves you from chasing a fix that was never needed.

Frequently Asked Questions

Does CSS Grid work on all versions of Safari?

No. CSS Grid does not work on Safari versions before 10.1. Safari 3.1 through 10 either lack Grid entirely or have early quirks. Safari 10.1 and every version after it support Grid well. Check your user analytics to see which versions your visitors actually use before you decide how far back to support.

Why does my gap property fail in Safari but not Chrome?

The gap property worked inside Grid early on, but it did not work inside Flexbox on iOS Safari until version 14.5. If your spacing breaks, you are likely using gap with Flexbox, not Grid. The fix is to use margins on the child items for that case, or to upgrade your support target.

Should I use Autoprefixer or write prefixes by hand?

For small projects with plain CSS, hand written prefixes are fine. For larger projects with a build step, Autoprefixer is the better choice. It adds the correct prefixes automatically based on your browser targets. Remember to enable Grid prefixing with a control comment, since Autoprefixer turns it off by default.

How do I test old Safari without an old iPhone?

You have several options. On a Mac, use Safari Technology Preview and the Xcode Simulator to run older iOS versions. Cloud testing services also let you run real Safari builds in a browser. These let you see the true rendering without buying physical devices.

Is Flexbox a good fallback for CSS Grid?

Yes, for many layouts. Flexbox has wider browser support than Grid and works in older Safari. It handles cards, navigation bars, and wrapping rows well. It cannot do true two dimensional layouts like Grid, so very complex designs need more effort, but it makes a reliable fallback for most common cases.

What is the cleanest way to support old and new Safari at once?

Use the @supports feature query with progressive enhancement. Build a simple Flexbox or block layout as your base, then wrap your Grid code in @supports (display: grid). Old Safari uses the base layout, and modern browsers use the upgraded grid. This keeps your site usable everywhere without messy hacks.