
CSS Anchor Positioning lets you tether one element to another so a positioned element can be sized and placed relative to an anchor element. Chrome called the API “a game‑changer” that “lets you natively position elements relative to other elements,” and that description captures why this feature has excited UI engineers: it brings native tethering and scroll‑tracking into CSS instead of relying on JS calculations.
The feature rolls several complementary pieces into a coherent API , anchor-name, position-anchor, position-area, anchor-size, and position-try mechanisms , and it is now available across modern engines. With staggered shipping in Chromium in 2024 and follow‑up releases from WebKit and Gecko, developers can start using anchor positioning in production with progressive enhancement and sensible fallbacks.
At its heart, Anchor positioning gives you a way to declare that a positioned element should be placed relative to another element on the page. The basic building blocks are anchor-name (a dashed identifier you apply to the anchor), and on the positioned element you use position-anchor to refer to that name. The position-area (formerly inset-area) is a 9‑cell grid concept that defines the bounds and alignment options.
Other important properties and functions include anchor, anchor-size (to size an element relative to an anchor), and the position-try / @position-try / position-try-fallbacks feature that lets the UA attempt alternative placements when an ideal placement would overflow. You can also cancel associations with position-anchor: none if you need to remove a tether dynamically.
Implementations require the positioned element to use absolute or fixed positioning for anchor relationships to take effect. Anchor-name identifiers follow the dashed ident style (similar to custom properties), so authors typically use names that begin with two dashes, e.g. –my-anchor, to avoid clashes and to match examples in Chrome docs and MDN guides.
Anchor positioning first shipped in Chromium/Chrome 125; Google announced the availability in a Chrome blog post published May 10, 2024: “Anchor positioning is available from Chrome 125.” That initial shipping marked the beginning of a broader cross‑engine effort to standardize tethering in CSS.
WebKit picked up the feature next and documented it as part of “WebKit Features in Safari 26.0” (Safari 26.0; blog post dated Sep 15, 2025). WebKit’s notes include usage examples for position-area, anchor, and pairing anchor positioning with popover behavior for tooltips and menus.
Firefox enabled CSS anchor positioning by default in Firefox 147 (stable release date: January 13, 2026), completing the goal of having all major engines support the feature. Chromium‑based browsers such as Edge and Opera follow Chromium’s releases (Edge 125+ and Opera tracking the engine), so support arrived there once Chromium shipped the feature.
Can I Use shows anchor positioning as supported in Chrome 125+, Edge 125+, Safari 26.x, Opera 111+ and Firefox 147+. The page aggregates usage data and lists an estimated global support figure of roughly 76.17% at the top of the compatibility table, indicating that a strong portion of the web can natively consume the API today.
That percentage is useful for assessing progressive enhancement decisions: while a majority of users will have native support, older browsers and some mobile or embedded browsers may still need fallbacks. Compatibility tables and browser/version rows are the immediate source of truth when planning rollout.
Keep an eye on engine release notes and the Can I Use table for incremental additions or sub‑feature gaps; for example, some engines shipped a baseline implementation first and then added refinements in later releases, so checking exact version rows is important for edge cases.
The API saw a few syntax renames and editorial fixes after initial shipping. Notably, inset-area was renamed to position-area, and position-try-options was renamed to position-try-fallbacks. Chrome’s developer blog and later Chromium updates documented these renames and the edits were coordinated via the CSS Working Group.
Chrome noted that some of these updates shipped in later Chromium releases (changes referenced as shipping in Chrome 129), so authors referencing older tutorials should verify current property names before copying examples. MDN and web.dev followed with updated pages to reflect the canonical names.
These edits are an expected part of maturing a new CSS API: early adopters should prefer up‑to‑date documentation and test across the minimum versions they intend to support to avoid surprises from renamed syntax or behavior tweaks.
Browser vendors and web guides call out common uses for anchor positioning: tooltips, popovers, dropdowns and submenus, select-style controls, contextual labels, and context menus. The API shines in layered or top‑layer UIs (dialogs and popovers) where tethering and scroll tracking eliminate jitter and complex JS positioning logic.
Chrome and WebKit docs include short example snippets that combine anchor-name on an anchor element with position-anchor and position-area on a positioned element to get predictable alignment. Using anchor-size you can also size a popover to match or relate to the anchor, which is handy for menus and select replacements.
Because anchor positioning is declarative, it reduces the need for layout thrashing caused by JavaScript measurement loops. For many common patterns , a tooltip that follows a target while staying within viewport bounds, or a dropdown that flips when space is constrained , the API provides ergonomics that previously required complex libraries.
There are important behavior constraints to keep in mind. Anchor‑positioned elements must be absolute or fixed positioned; without such positioning the anchor properties do not apply. Anchor names are dashed idents (e.g. –anchor-name), which helps avoid clashes with regular IDs or classes.
The position-try and @position-try rules let the user agent attempt alternative placements when a chosen alignment would overflow; you can provide position-try-fallbacks so the browser can flip or shift placements automatically. Also, position-anchor: none cancels an association if you conditionally disable tethering via CSS.
The position-area concept is effectively a 3×3 grid for alignment and clipping decisions; understanding that grid and how anchor-size can relate a popover’s size to its anchor will help you create robust, adaptive UIs. As always, test interactions like scrolling, transforms, and stacking contexts, since top‑layer scenarios have interplay with z-index and layering APIs.
A community polyfill (oddBird’s css-anchor-positioning) exists to help bridge older browsers, but its authors note the polyfill stops applying on engines that already ship the feature (it will not polyfill Chromium 125+). Some later sub‑features are also not polyfilled, so polyfills are best used as a short‑term bridge for older builds.
Given the Can I Use numbers and staggered rollouts, recommended practice is progressive enhancement: use anchor positioning for enhanced behaviors, but provide JS/CSS fallbacks or polyfill routes for critical UI so users on older engines don’t experience regressions. Web.dev’s “Anchor positioning” guide and MDN’s “Using CSS anchor positioning” page give step‑by‑step examples and pitfalls to consider when designing fallbacks.
Community writeups and interop efforts (notably Interop 2025) helped move anchor positioning and related features such as View Transitions toward cross‑browser parity. Still, project leads should pin minimum supported versions in documentation and run tests across the browsers their users actually use.
If you want to experiment, start with the official Chrome developer blog and docs for examples and the web.dev learning guide for guided tutorials. MDN’s Using CSS anchor positioning page is also an authoritative how‑to reference that explains property details, examples and fallbacks for production usage.
For compatibility checks consult Can I Use for version tables and the aggregate support figure; check browser release notes (Chrome 125 announcement May 10, 2024; WebKit’s Safari 26.0 notes Sep 15, 2025; Firefox 147 release notes Jan 13, 2026) for engine‑specific details. If you need temporary coverage for older browsers, evaluate the oddBird polyfill but plan to prefer native behavior when it’s available.
Try small, progressive refactors: convert a single tooltip or dropdown to anchor positioning first, add position-try fallbacks, and monitor cross‑browser behavior before rolling the pattern broadly across a large component library.
Anchor positioning is now broadly available across major browsers and offers a declarative, CSS‑level solution for common tethering problems. With Chrome 125 initially shipping the feature, Safari 26 and Firefox 147 following, and Chromium‑based browsers tracking those releases, most modern users can benefit from native anchor behavior.
As with any evolving web feature, adopt it thoughtfully: follow up‑to‑date docs, provide fallbacks for older engines, and test real‑world interactions. Do that and anchor positioning can simplify code, improve performance, and make UI placement far more predictable.