Glassmorphism — The UI Trend Explained
Glassmorphism is one CSS property and a pile of hierarchy problems. What the frosted-glass look actually does to legibility, why neumorphism died of the same cause, and where it earns its place.
You've seen the card. A translucent panel floating over a photograph or a color gradient, the background behind it blurred into soft shapes, a hairline of white along the top edge like light catching glass. It looks expensive. It photographs beautifully in a portfolio shot. Take it outdoors on a phone and the labels start to disappear into whatever's behind them.
That's the gap this article is about: how good the panel looks in the design file versus how it performs on a stranger's screen, in daylight, over content you didn't pick. The technique is fine. It's being asked to do a job it can only do under conditions you don't control.
What glassmorphism actually is
The name was popularized around 2020 by designer Michal Malewicz. The look predates the label by more than a decade: Windows Aero in 2007, iOS 7's translucent panels in 2013, macOS Big Sur's frosted sidebars in 2020. The word gave a scattered set of decisions a shared vocabulary, and the trend took off from there.
Four ingredients make a surface read as glass:
- A blurred backdrop. Whatever sits behind the panel is blurred, not the panel's own contents. This is the load-bearing one.
- Partial transparency. Usually a white or dark fill at 10–30% opacity, so the color behind bleeds through.
- A thin light border. A 1px semi-transparent white edge, brightest along the top, imitating a refracted highlight.
- A layered background. Glass needs something to be glass over. On a flat gray page the effect is invisible, which is why every glassmorphism demo you've seen sits on a gradient or a photo.
Drop any one of those and it stops reading as glass. The blur is the one people cut first, usually for performance, and without it you have a translucent rectangle.
The CSS is one property
.glass-panel {
background: rgba(255, 255, 255, 0.15);
backdrop-filter: blur(12px);
-webkit-backdrop-filter: blur(12px);
border: 1px solid rgba(255, 255, 255, 0.25);
border-radius: 16px;
}
backdrop-filter applies a filter to everything painted behind the element, which is the entire trick. Its sibling filter blurs the element's own contents, including your text. Reach for the wrong one and you get a panel with smeared labels over a perfectly sharp photo, which looks like a browser bug for about five minutes before you find the typo.
Browser support is broad now. Safari needs the -webkit- prefix and has since it shipped the property first; Firefox joined in version 103, back in 2022. Keep the prefixed line, and give the panel something to fall back to:
@supports not (backdrop-filter: blur(12px)) {
.glass-panel { background: rgba(20, 20, 24, 0.85); }
}
The fallback matters more than it looks. Without it, a browser that ignores backdrop-filter renders your panel at 15% opacity over a photograph. The text lands directly on the image. Nobody can read it.
Transparency and elevation compete for the same job
Glassmorphism isn't a color choice. It's a depth choice, and depth is already spoken for.
An interface tells the eye what to look at first through a small set of signals: size, weight, color, contrast, spacing, and elevation. Elevation is normally carried by shadow — the sense that one surface floats above another. Glass carries it too, through blur and translucency. Now two systems are both saying "this is on top," and they don't automatically agree.
So the practical rule is one glass layer per view. Pick the surface that genuinely floats, the navbar or the modal, and make everything else opaque.
Watch what happens when you don't. A glass modal over a glass navbar over a glass card gives you three surfaces that all announce elevation and none that establish rank. The user's eye has nothing to sort by, because every layer is doing the same thing at the same intensity. That's the ordinary failure of any strong visual treatment applied uniformly, and the fix is usually fewer instances at higher contrast. Our visual hierarchy hub covers how the other signals — size, weight, spacing — divide the work between them.
The contrast problem no linter can catch
WCAG asks for a 4.5:1 contrast ratio between normal text and its background, 3:1 for large text and for meaningful non-text elements. Those are ratios between two specific colors.
A glass panel doesn't have a background color. It has whatever happens to be behind it, tinted and blurred, which changes as the page scrolls, as the hero image loads, as the user switches to dark mode, as a video plays underneath. Your white label sits at 6:1 over the dark part of the photo and 1.8:1 over the bright part, and both states are on screen at once.
This is why automated accessibility checkers are close to useless here. They sample a computed background color, get rgba(255,255,255,0.15), and either report a pass against the wrong value or throw up their hands. There is no single number to test, so nothing fails, so the report comes back clean on a panel that is genuinely hard to read.
Three things actually help:
- A solid scrim under the text. A slightly more opaque layer behind the text block specifically, leaving the rest of the panel alone. It costs a little of the effect and buys back a deterministic contrast ratio.
- Raising the fill opacity until the worst case passes. Sample the brightest and darkest regions your background can actually produce. The pretty middle of the gradient will pass on its own.
- Constraining the backdrop. If the panel only ever floats over a gradient you control, you can reason about the range. If it floats over user-uploaded images, you can't, and you should stop trying.
Take those two worst-case colors to our free contrast checker and you'll get the ratio for each. That's the measurement your CI pipeline can't make on your behalf.
While you're there, respect the user's stated preference. Both major mobile platforms have shipped a Reduce Transparency accessibility setting for years, and CSS exposes the equivalent:
@media (prefers-reduced-transparency: reduce) {
.glass-panel {
background: rgb(20, 20, 24);
backdrop-filter: none;
}
}
Support for this query is newer than the rest of the stack, so check it against your own browser matrix before you lean on it. The @supports fallback above is still the one carrying the load.
Neumorphism, and the lesson it already taught
Glassmorphism has an older sibling. Neumorphism, from the same designer a year earlier, extruded buttons out of the background using two shadows, one light and one dark, on a surface the exact same color as the page behind it.
It was everywhere for about six months and then essentially vanished from shipped products. The reason is instructive: by definition, a neumorphic control is the same color as its background. The only thing separating a button from the page is a soft shadow, which puts its effective contrast far below 3:1. Raise it enough to pass and the effect is gone. The aesthetic and the requirement were the same variable pulling in opposite directions.
Glassmorphism isn't in that trap, which is why it's still here six years later. Its contrast is adjustable: turn up the fill opacity and the text gets more legible while the panel still reads as glass. There's a dial. Neumorphism had a switch.
Liquid Glass and the second wave
Apple's Liquid Glass, introduced at WWDC in June 2025 and shipped across iOS 26 and its sibling releases, is the reason this conversation restarted. It's glassmorphism with the physics turned up: surfaces that refract, throw specular highlights, and respond to motion and to the content scrolling beneath them. Most web implementations stop at a flat blur.
It also ran into exactly the problem described above. Early betas drew sustained criticism over legibility: control labels sitting on unpredictable backdrops, tab bars washing out over bright content. Apple adjusted the opacity in later betas before release.
Take that as the calibration. The most-shipped implementation of the idea in history, from a company with a serious accessibility organization, still had to be walked back toward opacity during beta. If your glass panel feels slightly too transparent, it is.
What it costs to render
backdrop-filter is not free. The browser has to rasterize what's behind the element, run a blur over it, and composite the result, then redo that work whenever the content behind changes. A blurred panel pinned over a scrolling page is asking for it on every frame.
You'll rarely notice on a development machine. You will notice on a mid-range Android phone, as dropped frames during scroll and as battery drain. Keep the blurred area small, don't animate the blur radius, don't stack blurred layers over each other. And if you're debugging jank on a page with glass in it, switch the blur off first and see whether the problem goes away.
When glassmorphism is the right call
It works when the blurred backdrop is carrying information. Think of a maps app's bottom sheet: you drag it up to read the route details, and the map stays visible underneath, still oriented, still showing where you are. An opaque sheet would cover the thing the sheet is about. The translucency is doing real work there, and the same argument covers a media player over album art or an editing toolbar over the photo being edited.
Temporary surfaces are the other safe case. A modal, a popover, a toast. Translucency reads as this is on top of your work, not instead of it, which is the right message for something the user is about to dismiss.
Where it breaks down is anything you have to read carefully: long-form text, data tables, dense settings screens. Those need a background that holds still, and glassmorphism's defining property is that its background doesn't. Scale it up to the whole design language and every surface is translucent, so no surface stands out, and you're paying the rendering cost on all of them.
FAQ
What is glassmorphism? A UI style where a panel appears to be frosted glass: the content behind it is blurred, the panel itself is partly transparent, and a thin light border suggests a refracted edge. It needs a layered background, a photo or a gradient, to be visible at all.
Is glassmorphism still relevant in 2026? Yes, more than it was two years ago. Apple's Liquid Glass in iOS 26 pushed the idea back into the mainstream, and CSS support is now broad enough to use without heavy fallbacks. Use it on specific surfaces; it falls apart as a whole design language.
How do I create glassmorphism in CSS?
backdrop-filter: blur(12px) on an element with a semi-transparent background and a light 1px border. Include the -webkit- prefix for Safari and an opaque fallback via @supports for browsers that don't apply the filter.
Is glassmorphism accessible?
It can be, but not by default. Because the effective background is whatever sits behind the panel, contrast varies as content changes, and automated checkers can't evaluate it. Test against the brightest and darkest backdrops your layout can produce, and honor prefers-reduced-transparency.
What's the difference between glassmorphism and neumorphism? Neumorphism extrudes shapes out of a background of the same color using paired light and dark shadows. Glassmorphism layers a translucent, blurred surface over a distinct background. Neumorphism's contrast couldn't be raised without destroying the effect, which is largely why it disappeared.
What is Liquid Glass? Apple's 2025 design language, shipped in iOS 26 and its companion releases. It extends glassmorphism with refraction, specular highlights and motion response, where most web implementations stop at a flat blur.
Does glassmorphism hurt performance?
It can. backdrop-filter forces the browser to blur and composite the region behind the element, repeated as the underlying content changes. Keep blurred areas small, don't stack them, and don't animate the blur radius.
The background you don't control
Everything above assumes you know what's behind the glass. Most of the time, at design time, you do — there's a gradient in the file and it doesn't move.
Then the feature ships and users put things behind it. A profile header over an uploaded photo that's 90% white sky. A dashboard card over a chart that turns red during an incident. A dark-mode toggle that inverts the whole stack while your border highlight stays the same white it was designed as. In every one of those cases, someone else's content is deciding whether your labels are readable.
So before shipping glassmorphism anywhere users supply the backdrop, spend ten minutes trying to break it. Load the whitest image you have, then the busiest one, then flip the theme. Panels that survive all three have earned the effect. Panels that only work over the gradient in the design file were never tested against a user.
Related
Information Architecture
UX Collective UX Teardown: Building the Biggest Design Publication on Rented Land
A UX teardown of UX Collective: the largest independent design publication runs entirely on Medium, and every page is shaped by owning the taste but not the platform. How the read flow races Medium for the reader — and the one tab that wins.
TYPENORMLabs · 5 min · July 24, 2026
Research Methods
Usability Testing — A Step-by-Step Guide
How to run a usability test end to end: framing the question, picking moderated or unmoderated, recruiting five people, writing tasks that don't lead, and turning what you watched into a ranked list of fixes.
TYPENORMLabs · 8 min · July 29, 2026
Accessibility
Skip Navigation Links for Accessibility
A skip navigation link lets a keyboard user jump past the nav straight to the content. Four lines of markup, and almost every implementation gets the CSS or the focus wrong.
TYPENORMLabs · 7 min · July 25, 2026