Anticode Open builder

Shadows in UI design: when elevation needs a shadow, when a border is better

Shadows in UI design should answer one question: is this element above the page? Menus, dialogs, popovers and dragged items genuinely are, and a soft shadow says so. Cards sitting in a grid usually aren't, and a hairline border or a slightly different surface separates them more cleanly. Coloured glows answer no question at all.

Updated · By the Anticode team

What a shadow means

In the physical world a shadow tells you an object is lifted off a surface and where the light comes from. Interface design borrowed this to show layers. Skeuomorphic interfaces used heavy, realistic shadows; flat design removed them; Google's Material Design reintroduced them in a disciplined way as “elevation”, with each layer of the interface sitting at a defined height and casting a matching shadow. The lasting lesson is that a shadow is information, not decoration.

Elevation that earns a shadow

Which elements usually need a shadow
ElementShadow?Why
Dropdown menus, popovers, tooltipsYes, soft and closeThey float over content and need separating from whatever is underneath
Dialogs and sheetsYes, larger and softerThe highest layer; the shadow (and often a dimmed backdrop) signals it's modal
Dragged itemsYes, while draggingShows the item has been picked up
Sticky headersOptional, only once scrolledSeparates the header from content passing underneath
Cards in a gridUsually noThey're on the page, not above it; a border or surface colour is enough
ButtonsRarelyA fill already identifies them; a shadow under every button adds noise

Borders and surfaces instead

A one-pixel border in a low-contrast line colour, or a surface a step lighter or darker than the ground, separates content without implying height. It's sharper on high-density screens, it works identically in light and dark themes, and it doesn't fight with photography. Many of the most carefully designed interfaces use almost no shadows at all and rely on lines, spacing and surfaces. If a border is the only thing showing where a form field is, though, WCAG 2.2's non-text contrast criterion asks for 3:1 against the background.

Drawing a believable shadow

  1. Use a neutral, mostly transparent colour. Black, or a very dark version of the ground's hue, at low opacity. Pure grey on a tinted background looks dirty.
  2. Offset it downwards. Light usually comes from above, so the y-offset is positive and the x-offset is zero or small.
  3. Layer two shadows. A tight, slightly darker one close to the element and a wide, faint one further out look more natural than a single blur, for example box-shadow: 0 1px 2px rgba(0,0,0,.08), 0 8px 24px rgba(0,0,0,.08).
  4. Scale with height. Higher layers get larger offsets and blurs and lower opacity, not just a darker shadow.
  5. Keep one light source. Shadows pointing in different directions on the same page look broken.

Why coloured glows read as generated

A large, blurred shadow in the accent colour under a button or card, often purple or blue, is a common pattern on template and model-generated pages. It doesn't describe light, since nothing in the scene is glowing, and it makes elements look as if they're floating in neon. It also tends to lower the contrast of anything nearby. If an element needs emphasis, a solid fill, a stronger border or more surrounding space does it more clearly. Glow effects in web design covers the pattern in detail.

Hard offset shadows: the exception

Neo-brutalist designs use shadows with no blur at all, offset a few pixels down and right in solid black. They don't pretend to be light; they're a graphic device, closer to a print shadow. They work when used consistently on every boxed element, and when pressing a button visibly moves it into its shadow. See neo-brutalism web design.

Shadows in dark themes

Shadows almost disappear against a dark ground. Dark interfaces show elevation by making higher surfaces lighter instead, sometimes with a subtle top border. If you do keep a shadow, make it darker and wider than in the light theme, and don't rely on it as the only separator.

Shadows in Anticode

Anticode's design systems prefer lines and surfaces to shadows. By default cards, plans and form panels carry no shadow; Technical separates them with one-pixel borders, Swiss and Editorial with rules, Organic and Playful with tinted surfaces and outlines. Organic's buttons have a one-pixel shadow at low opacity. Brutalist is the deliberate exception, with hard black offset shadows on cards, images and buttons, and buttons that shift into their shadow on hover.

The Critic flags a coloured glow on every build: a box-shadow with a large blur in a colour other than black.

Questions people ask

Should cards have a shadow or a border?

For cards in a grid, a border or a slightly different surface is usually cleaner. Save shadows for things that genuinely sit above the page.

What colour should a box-shadow be?

Black or a dark version of the background's hue, at low opacity. Coloured shadows in the accent colour read as a glow rather than a shadow.

Do shadows work in dark mode?

Poorly. Use lighter surfaces for higher layers instead, and keep any shadow as a secondary cue.

Sources

  1. box-shadow, MDN Web Docs, checked
  2. Understanding Success Criterion 1.4.11: Non-text Contrast, W3C, checked