Codec Support Differences
Chrome supports H.264, VP8, VP9, AV1, and HEVC (on devices with hardware support). This makes Chrome the most codec-flexible browser. Safari supports H.264 and HEVC natively (leveraging Apple's hardware decoders on Mac and iOS), but historically lacked VP9 and AV1 support. Safari 17+ on macOS Sonoma added AV1 support on Apple Silicon devices. In practice: MP4 H.264 plays everywhere. WEBM VP9 plays in Chrome, Firefox, and Edge, but not in older Safari. Always test on Safari separately — it will reject formats Chrome accepts.
HLS vs Everything Else
This is the biggest divergence. Safari natively supports HLS (.m3u8) via the HTML5 video element — no JavaScript required. It does not support MPEG-DASH at all (natively or via polyfill gracefully). Chrome is the opposite: no native HLS support, but it runs hls.js and dash.js via MSE perfectly. This means any adaptive streaming app must ship hls.js for Chrome/Firefox users and rely on native HLS for Safari — or use a library like Vidstack or Video.js that handles this detection automatically.
Autoplay, Permissions, and DRM
Both browsers block autoplay of videos with audio, requiring a user gesture before sound plays. Chrome enforces this via a 'media engagement' score — sites you visit frequently get slightly more permissive autoplay behavior. Safari is stricter and more consistent regardless of engagement history. For DRM: Chrome uses Widevine (Google's DRM system), while Safari uses FairPlay (Apple's). A video protected with Widevine will not play on Safari, and vice versa. Services that need DRM on both browsers must license and implement both, which is why DRM usually appears only in large commercial platforms.