Embracing Playful Imperfection With The CSS random() Function — Smashing Magazine

Brecht De Ruyte is a self-taught front-end developer located in Belgium with a passion for UX and Design. After more than a decade of working in tech, he … More about Brecht ↬
Weekly tips on front-end & UX.Trusted by 182,000+ folks.
In design, we love spending hours obsessing over consistency, grids, and alignment. But when I heard that the native CSS random() function landed in Safari and is rolling out in Chrome 156, I started wondering: where does randomness actually make sense on the web? Is it something we want in our design system? To find out, I did what I always do in doubt: I built a bunch of playful CodePen demos exploring organic typography, bouncing letters, splayed cards, and a punk fanzine.
As someone who loves building design systems and tinkering with CSS architecture, a big part of my day job revolves around control. We set up spacing scales, lock down typography, set up color tokens, and make sure everything aligns on a grid. Consistency is usually our bread and butter as design engineers and a proud badge of skill when creating design systems. If a card suddenly jumps 20 pixels to the left on a refresh, it’s not creative expression; it’s a bug that the project manager will log.
So when I first heard that the native random() function from the CSS Values and Units Level 5 spec was shipped in Safari, and is currently rolling out in Chrome 156 (with positive signals from Mozilla on Firefox as well), my first reaction was: that’s pretty cool!
And my second reaction was: wait… where would I actually use this without making a mess? How can I convince designers that random might be a good idea for a design system?
Because let’s be honest: why on earth would we want randomness in our stylesheets when we’ve spent the last decade trying to make the web more predictable? Even when using flexbox or fluid typography, we’re still trying to make things as aligned and uniform as possible.
If you step away from the browser for a second and look at physical things around you, nothing is ever truly uniform.
Take an old letterpress print: the ink bleeds slightly into the paper grain, some letters have a microscopic tilt, and the baseline isn’t always that straight. Or think about a deck of Polaroid photos dropped on a coffee table; those photos aren’t perfect, probably not straight either. Or what about lights flickering in a street at night? That little bit of analog messiness is what makes things feel alive, organic, and human.
On the web, we’ve gotten so good at pixel perfection that sometimes our interfaces end up feeling a bit sterile. We notice this even more now with rapidly created designs by an unguided LLM; we usually end up with the same sort of design we had 10 years ago. Everything is squared off, aligned, neat. It works, but frankly, it does get a bit boring.
Randomness in CSS doesn’t have to mean throwing your design system out the window. It’s about little imperfections and playfulness. Maybe let’s even call it fun.
To see what this actually looks like in practice, I spent a few hours tinkering in CodePen. The demos might feel a bit isolated, but I’m sure that many designers could make the best of this controlled chaos. But before we look at those demos, let’s take a look at the syntax.
Meet Smashing Workshops on front-end, design & UX, with practical takeaways, live sessions, video recordings and a friendly Q&A. With Brad Frost, Stéph Walter and so many others.
The random() function is specified in CSS Values and Units Module Level 5. It generates a pseudo-random value inside your CSS without needing JavaScript or a build-time Sass loop.
The formal specification looks like this:
In practice, and across current browser implementations, you can just write comma-separated arguments:
It won’t be a shocker for most people, but I thought I should at least mention that your minimum and maximum bounds must share the exact same unit type.
The CSS parser needs to know what dimension it’s dealing with. You can use lengths, angles, time, percentages, or plain unitless numbers:
If you ever need to combine units, you’ll have to reach for calc() inside the arguments so each side resolves properly.
The optional third argument is the step size. If you don’t add it, the browser picks from a continuous range. But if you provide a step, it rounds the random value to discrete increments:
This can be helpful in cases where you want things to jump around a bit, but you still want them to land on your pre-defined grid.
Normally, every time random() is evaluated on a property, it creates an independent random value. But there could be an example where you create a box that sets inline-size and block-size at random, but at the same time you need them to match so the element stays a perfect square.
That’s where the caching key comes in:
In the latest spec, a bare dashed ident like --square-size shares its seed globally across every element in the document (which would make all cards identical). To keep width and height linked on a single element while giving each card its own independent size, the spec requires pairing it with the element-scoped keyword (e.g. --square-size element-scoped).
To see this in action, I created a little example. In the top row, the tiles have uncached dimensions, which distorts each tile into an unpredictable, mismatched rectangle. In the bottom row, both inline-size and block-size share --square-size, guaranteeing that each tile remains a pristine 1:1 square. Refresh the CodePen a couple of times and notice the bottom cards keeping the same randomness:
See the Pen [Uncached vs cached random() [forked]](https://codepen.io/editor/smashingmag/pen/01a15e91-4bac-765e-b04e-a53636759163) by @utilitybend.
Where can you test this today?
Because we’re still in the rollout phase, you’ll want to wrap your experiments in @supports:
There’s also another function in the spec called random-item(). While random() handles numerical ranges, random-item() lets you pick from a list of p