Elementary Standards
HTMLCSSWeb StandardsSEOBlogStart reading
Home / Blog / CSS Gets a random() Function in Chrome 156
News

CSS Gets a random() Function in Chrome 156

Scattered dots, shuffled grids and wheel-of-fortune animations no longer need a line of JavaScript to pick a number.

Chrome 156 moved to the beta channel on September 30, 2026, and among its new CSS features is one developers have been asking for since the CSS Working Group first discussed it in 2022: a native random() function. According to the Chrome 156 beta announcement and the matching entry on Chrome Platform Status, the function generates a random numeric value — length, percentage, angle, integer or similar — directly inside a stylesheet, with Chrome 156 scheduled to reach the stable channel on October 20, 2026. Safari previewed the same capability far earlier: WebKit's engineering blog described the function in Safari Technology Preview back in August 2025, which makes this one of the rarer cases where Chrome is catching up to a syntax Safari helped shape, rather than the other way around. For teams building custom interfaces that lean on generative, data-driven visuals, it is a feature worth tracking closely.

top: random(0%, 100%);Chrome 156Safari STP 2025

What random() actually does

The basic form takes a minimum and maximum: random(0%, 100%) or random(10px, 500px). Both arguments must share the same type, so you can mix percentages with percentages or angles with angles, but not percentages with pixels. A documented example from the Chrome release notes scatters elements across a container without any script at all:

.dot {
  position: absolute;
  top: random(0%, 100%);
  left: random(0%, 100%);
}

WebKit's syntax adds an optional third argument for stepping — random(0, 100, 2) restricts output to even numbers, and random(0turn, 1turn) works the same way for angle values. Every element the rule applies to gets its own independently generated value by default, which is what makes the scattering example work: a hundred .dot elements produce a hundred different positions from one declaration.

Controlling which values repeat

Independent randomness per element is useful for scattering, but not every design wants that. Both engines document a sharing mechanism built on identifiers: a named key passed as part of the function lets separate declarations draw from the same random base value, so a dot's size and its color can vary together consistently instead of independently. WebKit's write-up also describes an element-shared keyword that forces every matched element to receive the identical random value rather than its own — useful for a grid where you want one random accent applied uniformly rather than per-cell noise. The precise keyword names were still being discussed in the CSS Working Group as of WebKit's post, so expect the exact syntax to firm up before the feature reaches Baseline.

What this means for developers

The immediate win is removing a category of layout and animation work that previously needed a script tag purely to pick a number: star fields, confetti, randomly tinted grid cells, shuffled photo stacks, spinning wheel-of-fortune animations. None of those are complex JavaScript today, but each one is JavaScript that has to run before the first paint, re-run on resize if the values are positional, and get reconciled against server-rendered markup if the page uses SSR. A CSS-native random value sidesteps all three problems — it's resolved by the rendering engine, not blocked on script execution, and doesn't create a hydration mismatch because there's no server-rendered random value to disagree with. The tradeoff is accessibility-adjacent: motion or flicker driven by random() on every repaint should still respect prefers-reduced-motion, the same discipline teams already apply to scroll-driven and keyframe animations.

When does this ship everywhere

Chrome 156 stable is scheduled for October 20, 2026, which will put random() in a shipping Chromium release for the first time. Safari's implementation has been sitting in Technology Preview since August 2025 without yet reaching a stable Safari release, and Firefox has not shipped or previewed the function as of this writing. MDN's reference page for the function still flags it as outside Baseline because it doesn't yet work across the most widely used browsers. That makes random() safe to experiment with in Chrome-only contexts or behind a @supports check today, but not yet something to depend on for a production layout that needs to render consistently everywhere.

Back to the blog
More notes

Keep reading