The short answer
Every browser you will meet in an analytics report supports box-shadow, unprefixed, with inset, spread and multiple layers. Can I use puts global support at 96.7 per cent, and the missing fraction is not browsers that fail on shadows but browsers that fail on everything, mostly ancient embedded engines. If you are writing a vendor prefix for box-shadow in 2026, you are writing dead code. The generator on this site emits none, and this page exists so you can delete yours with a clear conscience.
When each engine dropped the prefix
The prefix era for shadows was short. Firefox 3.5 and Safari 3.1 shipped the property behind -moz- and -webkit- in 2009; the unprefixed versions arrived within two years. The full picture, from Can I use's data:
| Browser | Prefixed from | Unprefixed from | Year unprefixed |
|---|---|---|---|
| Chrome | 4 (-webkit-) | 10 | 2011 |
| Firefox | 3.5 (-moz-) | 4 | 2011 |
| Safari | 3.1 (-webkit-) | 5.1 | 2011 |
| iOS Safari | 3.2 (-webkit-) | 5.0 | 2011 |
| Edge | never needed | 12 | 2015 |
| Internet Explorer | never | 9 | 2011 |
I still find the three-line prefixed block in inherited WordPress themes, usually pasted from a generator that has not been updated since 2012, and the fix is always the same: keep the unprefixed line and delete the other two. Nothing changes on any device anyone owns.
Colour syntax is the real compatibility question
The lengths in a shadow are not where compatibility bites. The colour is. The property accepts any CSS colour, and CSS has added four new ways to write one since the shadow property settled:
| Syntax | Example | Safe from |
|---|---|---|
rgba() with commas | rgba(27, 35, 64, 0.18) | Everywhere, 2012 |
| Eight digit hex | #1b23402e | Chrome 62, Firefox 49, Safari 10 (2017) |
| Space separated with slash | rgb(27 35 64 / 18%) | Chrome 65, Firefox 52, Safari 12.1 (2019) |
oklch() | oklch(25% 0.05 268 / 0.18) | Chrome 111, Firefox 113, Safari 15.4 (2023) |
| Relative colour | oklch(from var(--shade) l c h / 0.18) | First shipped in Chrome 119, Safari 16.4, Firefox 128; complete in Chrome 131, Safari 18, Firefox 133 (2024) |
A shadow with an unsupported colour is not a slightly wrong shadow; the whole declaration is invalid and the browser draws nothing. That is why the generator writes rgba() with commas, the one form that cannot fail, even though the site's own stylesheet uses relative oklch() for its tokens. Choose by audience: a design tool for developers can assume 2024 browsers; a council website cannot.
Inset, spread and multiple shadows
All three arrived with the property itself. There was never a browser that supported box-shadow without supporting inset, the fourth spread length or the comma separated list, so anything the generator produces is either fully supported or not at all, and the second case is confined to browsers that predate the iPhone 4.
Backdrop blur, the one that still varies
The generator's box has a backdrop blur control because glass effects need it, and backdrop-filter is the one property on this site with a genuinely recent support history. Safari shipped it in 2015 with a -webkit- prefix and only dropped the prefix in Safari 18 (2024); Chrome unprefixed it in 76 (2019); Firefox did not support it at all until 103 (2022). The generator writes the unprefixed form. If you must support Safari 17 and earlier, add the prefixed line before it:
-webkit-backdrop-filter: blur(12px); /* Safari 9 to 17 */
backdrop-filter: blur(12px);The failure mode is gentle: a browser without support shows the translucent box with a sharp view of what is behind it. The glassmorphism example is designed so the card still reads without the blur, with the inset edge and outer shadow doing the separating.
Rendering differences you will actually see
Support is binary; rendering is not. The specification says the shadow "must approximate a Gaussian blur", and approximation leaves room. In practice three differences show up when you compare screenshots across engines. Blur edges differ by a pixel or so, most visibly on hard, high-contrast shadows; soft, tinted ones hide it. Very large blur values (150 pixels and up) can render banded on some GPU paths, which is one more reason to prefer several moderate layers over one huge one. And on iOS, a shadow that extends beyond a scrolling container with overflow: auto is clipped where desktop browsers would show it, so give scrolling containers padding equal to the shadow's reach.
None of this is a bug to report. It is the reason to test a shadow on a real phone before shipping, which the dark and image canvases in the generator make faster but do not replace.
Email clients
HTML email is where box-shadow genuinely does not work. Outlook on Windows uses Word's rendering engine and ignores the property entirely; Gmail strips it in some views. Treat a shadow in email as decoration that some readers will not see, never as the only thing separating a button from its background. A solid border or a contrasting background is the dependable choice there.
Everything it writes works in every current browser.
Frequently asked questions
Do I still need -webkit-box-shadow?
No. Chrome dropped the prefix in version 10 (2011), Safari in 5.1 (2011), Firefox in 4 (2011), and Edge never needed it. Unprefixed box-shadow reaches over 96 per cent of users worldwide according to Can I use, and the rest are browsers that do not run modern CSS at all.
Does box-shadow work on Internet Explorer?
IE9 and later support it unprefixed. IE8 and earlier do not; Can I use notes it "can be partially emulated in older IE versions using the non-standard shadow filter". Internet Explorer has been retired since June 2022, so a site that needs it is a site with a bigger problem than shadows.
Which colour format is safest in a box shadow?
rgba(). It has worked everywhere since 2012. Eight digit hex (#rrggbbaa) needs 2017 or later browsers, space-separated rgb() with slash alpha needs 2020 or later, and oklch() and relative colour syntax need 2023 or later.
Is backdrop-filter supported everywhere?
Current versions of every major browser support it: Safari since 9 with a -webkit- prefix and unprefixed from 18, Chrome since 76, Edge since 17 and Firefox since 103. Users on older Firefox see a translucent box without the blur, which is a graceful fallback.
Do mobile browsers render box-shadow the same as desktop?
The same values render the same shape. Differences are in blur quality on low-powered devices and in how far a shadow extends past the viewport; iOS Safari in particular can clip a large shadow at the edge of a scrolling container.
Why does my shadow look different in Safari?
Usually blur radius rounding on retina displays or a translucent colour composited slightly differently. Nothing in the specification requires pixel-identical output, only an approximation of a Gaussian blur, so a hairline difference between engines is expected.