Why Safari Still Uses the -webkit- CSS Vendor Prefix

This article explores the reasons why the Safari web browser continues to support and sometimes require the -webkit- vendor prefix for certain CSS properties, such as -webkit-backdrop-filter. It covers the history of browser rendering engines, the timeline of CSS standardization, the necessity of backward compatibility for the open web, and how Apple’s operating system update model keeps legacy prefixes relevant for modern web developers.

The Purpose of Vendor Prefixes

Browser makers originally introduced vendor prefixes to allow developers to test and use experimental CSS features before those features were officially standardized by the World Wide Web Consortium (W3C). Because Safari is powered by the WebKit rendering engine, Apple used the -webkit- prefix.

When a new CSS concept was invented, browser engineers could not guarantee how the final, official specification would behave. By placing a feature behind -webkit-, Safari allowed developers to use cutting-edge styles without risking future conflicts if the W3C decided to change how the standard property worked.

Delayed W3C Standardization

Many CSS features were invented directly by Apple engineers and implemented in Safari long before other browsers adopted them. A prime example is backdrop-filter, which Apple introduced in 2015 for iOS 9 and OS X El Capitan using the -webkit-backdrop-filter syntax.

Because the W3C standardization process is slow and requires consensus from multiple browser vendors, it can take years for an experimental feature to become an official standard. During the years a property remains in limbo, Safari continues to require the -webkit- prefix because an finalized, unprefixed standard does not yet exist or hasn't been fully agreed upon. In the case of backdrop-filter, Safari did not drop the prefix requirement until version 18, nearly a decade after the feature was first introduced.

Preserving Backward Compatibility

Even after a CSS property is officially standardized and Safari adds support for the unprefixed version, the browser cannot simply delete the -webkit- version from its engine. Doing so would break the visual layout of millions of older, unmaintained websites that were coded when the prefix was mandatory.

A core principle of web browser development is "don't break the web." To ensure that legacy websites continue to render correctly for users, WebKit maintains aliases in its code. This means the engine treats the old -webkit- property and the new standard property as the exact same command.

Safari Updates Are Tied to the OS

Developers often have to keep writing -webkit- prefixes in their stylesheets because of how Apple distributes Safari updates. Unlike Chrome or Firefox, which update automatically in the background regardless of the user's operating system, Safari updates are bundled directly with macOS and iOS system updates.

When an iPhone or Mac reaches the end of its supported lifecycle, it can no longer receive OS updates, which means it can no longer receive Safari updates. Users on older hardware are permanently locked into legacy versions of Safari. Because those legacy versions were released before certain CSS properties were unprefixed, developers must still include properties like -webkit-backdrop-filter alongside the standard backdrop-filter to ensure the visual effect works on older Apple devices.

Non-Standard WebKit Features

Finally, some -webkit- properties still exist because they were never meant to be standards, or the W3C outright rejected them. Properties like -webkit-line-clamp or -webkit-text-stroke were created by Apple to solve specific design problems. Because developers heavily adopted them, they became de facto standards. Safari—and even competing browsers like Chrome and Firefox—must continue to support these specific -webkit- prefixes indefinitely, as no unprefixed equivalents exist to replace them.