Which browsers support the CSS env() function?

Chrome 69+, Edge 79+, Firefox 65+, Safari 11.1+ on macOS, Safari 11.3+ on iOS, Opera 56+, and Samsung Internet 10.1+ support env(). Internet Explorer never added support, so any IE traffic falls back to the second argument or to the property's default value.

Does Safari support env()?

Yes. Safari supports env() from Safari 11.1 on macOS and from Safari 11.3 on iOS and iPadOS. Safari originally shipped the same feature as constant() in Safari 11.0 to handle the iPhone X notch, then renamed it to env() one version later.

What is the env() function in CSS?

env() reads a user-agent defined environment variable and inserts its value into a CSS property. The browser controls the value, so authors cannot set or override it. The classic example is env(safe-area-inset-bottom), which exposes the height of the iOS home indicator.

What is the difference between env() and var()?

var() reads custom properties scoped to an element, while env() reads global, user-agent defined variables scoped to the whole document. var() values are author-defined; env() values are browser-defined and read-only. Both accept a fallback as the second argument.

Can env() be used inside media queries?

Yes, but only the safe-area-inset-* and keyboard-inset-* family. env() works as a property value, in calc() expressions, in custom property defaults, and inside @media query value positions where a length is allowed. The full set of legal positions is browser-dependent.

What environment variables can env() read?

Browsers expose safe-area-inset-top, safe-area-inset-right, safe-area-inset-bottom, safe-area-inset-left, titlebar-area-x, titlebar-area-y, titlebar-area-width, titlebar-area-height, keyboard-inset-* and viewport-segment-* values. Only the safe-area-inset-* set is supported across every modern engine.

Why does env(safe-area-inset-bottom) return 0?

The viewport has no obstructions or the page is missing viewport-fit=cover in its meta viewport tag. Add so iOS Safari can report the real notch and home-indicator insets.

How do you provide a fallback when env() is not supported?

Pass the fallback as the second argument, like padding-bottom: env(safe-area-inset-bottom, 16px);. If the variable is missing or the browser does not support env() at all, the fallback wins. You can also wrap rules in @supports (padding: env(safe-area-inset-bottom)) for legacy browsers.

Is the CSS env() function part of Baseline?

Yes. The Web Platform Baseline marks env() as Widely Available because every modern Chromium, Gecko, and WebKit engine supports it. The safe-area-inset-* variables ship with the function on all of those engines, so the core feature is safe to use without a polyfill.

Does env() work on foldable and PWA window-controls overlay surfaces?

Partially. titlebar-area-* needs Chrome 93+ or Edge 93+ on a desktop PWA running with display_override: window-controls-overlay. viewport-segment-* needs Chrome 125+ behind the Viewport Segments API. Safari and Firefox do not expose either group yet.

Home
/
Learning Hub
/
CSS env(): Browser Support, Syntax, Use Cases

Testing

CSS env(): Browser Support, Syntax, Use Cases

The CSS env() function works in Chrome 69+, Edge 79+, Firefox 65+, Safari 11.1+, Opera 56+, and Samsung Internet 10.1+. See full browser support and syntax.

Prince Dewani

May 6, 2026

On This Page

About env()
Browser Support
Use env()
Use Cases
Known Issues
Citations

The CSS env() function is a W3C CSS Environment Variables Module Level 1 feature that reads user-agent defined values such as safe-area-inset insets, virtual keyboard offsets, and PWA title bar dimensions into your stylesheet. It works in Chrome 69+, Edge 79+, Firefox 65+, Safari 11.1+ on macOS, Safari 11.3+ on iOS, Opera 56+, and Samsung Internet 10.1+, while Internet Explorer never shipped support.

This guide covers what the CSS env() function is, the browsers that support it, how to use the syntax, the use cases, and the known issues.

What is the CSS env() function?

The CSS env() function is a W3C CSS Environment Variables Module Level 1 feature that reads a user-agent defined environment variable and inserts its value into a CSS property. The browser owns the values, so authors get read-only access to system-level data such as device safe-area insets and on-screen keyboard offsets.

Which browsers does the CSS env() function support?

env() ships by default in every modern engine. The Web Platform Baseline marks it as Widely Available across Chromium, Gecko, and WebKit, with the safe-area-inset-* set supported everywhere and a few advanced variables limited to Chromium-based browsers.

Loading browser compatibility data...

CSS env() compatibility in Chrome

Chrome supports env() from Chrome 69 on Windows, macOS, Linux, ChromeOS, and Android. Chrome 4 to 68 did not parse env(), so any rule that depended on it was discarded and the fallback property value applied. titlebar-area-* arrived in Chrome 93 and viewport-segment-* in Chrome 125.

CSS env() compatibility in Edge

Microsoft Edge supports env() from Edge 79 on Windows, macOS, and Linux through its Chromium pipeline. Legacy Edge 12 to 18, which used the EdgeHTML engine, ignored the function entirely and dropped the property. titlebar-area-* shipped alongside Chrome 93 in matching Edge builds.

CSS env() compatibility in Firefox

Firefox supports env() from Firefox 65 on Windows, macOS, Linux, and Android. Firefox 2 to 64 did not parse env(), so any property that used it fell back to its declared default. Firefox exposes the safe-area-inset-* set but does not yet expose titlebar-area-*, keyboard-inset-*, or viewport-segment-* values.

CSS env() compatibility in Safari

Safari supports env() from Safari 11.1 on macOS High Sierra and from Safari 11.3 on iOS and iPadOS. Safari 11.0 shipped the same feature as the prefixed constant() function for the iPhone X notch, then renamed it to env() in 11.1. Safari 3.1 to 10.1 on macOS and Safari 3.2 to 10.3 on iOS did not support either form.

CSS env() compatibility in Opera

Opera supports env() from Opera 56 on Windows, macOS, and Linux through its Blink engine. Opera 9 to 55 did not parse the function. Opera Mobile picked up support from Opera Mobile 80 on Android, in line with the Chromium update for the safe-area-inset-* and titlebar-area-* sets.

CSS env() compatibility in Samsung Internet

Samsung Internet supports env() from Samsung Internet 10.1 on Galaxy phones and tablets through its Chromium base. Samsung Internet 4 to 9.2 did not recognise env(), so safe-area styles silently dropped on those builds. Newer builds expose the same safe-area-inset-* and titlebar-area-* sets as their underlying Chromium release.

CSS env() compatibility in Android Browser

Modern Android WebView and Chrome for Android support env() in line with desktop Chrome 69 forward. The legacy stock Android Browser 2.1 to 4.4.4 did not support env(), so any traffic from those devices needs the second-argument fallback or a property-level default value.

CSS env() compatibility in Internet Explorer

Internet Explorer 5.5 through Internet Explorer 11 never added support for env(). Microsoft has retired Internet Explorer, so any legacy intranet pages still served to IE need to provide static padding values and skip safe-area handling entirely on the IE Mode path.

Note: The CSS env() function behaves differently across iOS Safari, desktop Safari, and Chromium browsers, especially for titlebar-area-* and viewport-segment-* variables. Test it on real browsers and OS with TestMu AI. Try TestMu AI free!

How do you use the CSS env() function?

Add the viewport-fit=cover meta tag so iOS reports real safe-area insets, then pass the variable name and a fallback to env() inside any property that accepts a length. Combine env() with calc() when you need to add or subtract from the system value.

Opt in to safe-area insets: Add <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover"> to your HTML head so iOS Safari extends the layout under the notch and home indicator and starts reporting non-zero values.
Read a variable with a fallback: Pass the environment variable as the first argument and a sensible default as the second, like padding-bottom: env(safe-area-inset-bottom, 16px);. The fallback covers older browsers and pages without viewport-fit=cover.
Combine env() with calc(): Use calc() when you need to add the system inset to a fixed value, like height: calc(56px + env(safe-area-inset-bottom, 0px));. This keeps a sticky bottom bar above the iOS home indicator.
Detect support before relying on it: Wrap rules in @supports (padding: env(safe-area-inset-bottom)) { ... } so legacy browsers that ignore env() get the basic stylesheet without partial styling.
Cover Safari 11.0 with constant(): Safari 11.0 shipped the same feature as constant(). If you still see traffic on iOS 11.0, declare both: padding-bottom: constant(safe-area-inset-bottom); padding-bottom: env(safe-area-inset-bottom);.

Verify the values in DevTools by inspecting the Computed pane on a real iOS device or a notched-device emulation profile, then confirm the resolved length matches what the simulator reports for the safe area.

/* 1. Add viewport-fit=cover so iOS reports real safe-area insets. */
/* In your HTML <head>:
   <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover"> */

/* 2. Read safe-area insets with a sensible fallback. */
.app-bar {
    padding-top: env(safe-area-inset-top, 16px);
    padding-bottom: env(safe-area-inset-bottom, 16px);
    padding-left: env(safe-area-inset-left, 12px);
    padding-right: env(safe-area-inset-right, 12px);
}

/* 3. Combine env() with calc() for a sticky bottom bar that clears the iOS home indicator. */
.bottom-tab-bar {
    position: fixed;
    bottom: 0;
    height: calc(56px + env(safe-area-inset-bottom, 0px));
    padding-bottom: env(safe-area-inset-bottom, 0px);
}

/* 4. Detect support before relying on env(). */
@supports (padding: env(safe-area-inset-bottom)) {
    .bottom-tab-bar { padding-bottom: env(safe-area-inset-bottom, 0px); }
}

What are the use cases of the CSS env() function?

env() is the only standard way to read system-level layout offsets in CSS. Most teams reach for it on mobile web apps with notches, PWAs that paint into the title bar, and foldable layouts that span more than one viewport segment.

Notch-safe iOS layouts: Use safe-area-inset-top and safe-area-inset-bottom on full-bleed pages so headers clear the iPhone notch and bottom bars sit above the home indicator without hard-coding device-specific paddings.
Sticky bottom navigation: Combine env(safe-area-inset-bottom) with calc() on fixed tab bars and chat input docks. The bar height grows when the home indicator is present and collapses on hardware-button devices.
Desktop PWAs with window-controls overlay: Read titlebar-area-x, titlebar-area-y, titlebar-area-width, and titlebar-area-height on installed PWAs so custom title bars never overlap the minimize, maximize, and close buttons.
Foldable and dual-screen surfaces: Use viewport-segment-width and viewport-segment-height in Chrome to lay out two columns into the left and right segments of a hinged device without measuring the hinge yourself.
Virtual keyboard avoidance: Read keyboard-inset-height to lift critical input fields above the on-screen keyboard on Chromium browsers that have opted into the Virtual Keyboard API.

What are the known issues with the CSS env() function?

env() ships widely, but each engine exposes a different subset of variables and the iOS Safari opt-in trips up most teams. Most production bugs come from missing viewport-fit=cover, the constant() to env() rename in Safari 11, and Firefox's narrower variable surface.

safe-area-inset-* returns 0 without viewport-fit=cover: iOS Safari reports zero for every safe-area-inset variable until the page declares viewport-fit=cover in its meta viewport tag. Pages copied from older templates silently lose notch handling.
Safari 11.0 only knows constant(): The first iPhone X release used constant() instead of env(). Sites that drop the constant() fallback see broken layouts on the small slice of users still on iOS 11.0.
Firefox exposes a narrow variable set: Firefox supports env() and the safe-area-inset-* family, but not titlebar-area-*, keyboard-inset-*, or viewport-segment-*. PWA and foldable code paths must fall back gracefully on Gecko.
env() cannot be set or polyfilled: Authors cannot write to env() variables. There is no JavaScript API to override or polyfill them, so legacy browsers can only be served via fallbacks or @supports queries.
Media-query usage is uneven: env() inside @media value positions works in Chrome and Safari for safe-area-inset-* but produces inconsistent results in older Firefox builds. Stick to property values when you need cross-engine parity.

In my experience, the trap that bites teams hardest is shipping a redesign that drops the viewport-fit=cover meta tag during a templating refactor, then watching every iPhone user lose the safe-area padding while desktop QA reports nothing wrong.

Citations

All CSS env() function version numbers and platform notes in this guide come from these primary sources:

MDN Web Docs - env() CSS function: developer.mozilla.org/en-US/docs/Web/CSS/env
MDN Web Docs - Using environment variables in CSS: developer.mozilla.org/.../Environment_variables/Using
W3C CSS Environment Variables Module Level 1: www.w3.org/TR/css-env-1
WebKit blog - Designing Websites for iPhone X: webkit.org/blog/7929/designing-websites-for-iphone-x
Apple Developer - Safari 11.1 release notes: developer.apple.com/.../safari-11_1-release-notes
Chrome for Developers - Customize the window controls overlay of your PWA: developer.chrome.com/docs/web-platform/window-controls-overlay
Chrome Platform Status - CSS Environment Variables: chromestatus.com/feature/5694140828024832
Mozilla Firefox 65 release notes: mozilla.org/en-US/firefox/65.0/releasenotes
Chrome for Developers - Viewport segments API: developer.chrome.com/docs/web-platform/viewport-segments
Wikipedia - Cascading Style Sheets: en.wikipedia.org/wiki/Cascading_Style_Sheets

Author

Prince Dewani

Blogs: 8

Prince Dewani is a Community Contributor at TestMu AI, where he manages content strategies around software testing, QA, and test automation. He is certified in Selenium, Cypress, Playwright, Appium, Automation Testing, and KaneAI. Prince has also presented academic research at the international conference PBCON-01. He further specializes in on-page SEO, bridging marketing with core testing technologies. On LinkedIn, he is followed by 4,300+ QA engineers, developers, DevOps experts, tech leaders, and AI-focused practitioners in the global testing community.