Modernize Default MUI Shadows / Add Theme Shadow Options

[mordeccai]

Summary

The default Material UI box shadows feel dated and don't match the cleaner, flatter aesthetic of modern applications. They often make the UI look heavier than necessary.

I'd like one of the following improvements:

• Update the default MUI shadow system to use more modern, subtle shadows.
• Alternatively, provide an easy way to switch between multiple built-in shadow themes (e.g. Classic, Modern, Flat, Soft, Material 3) through the theme configuration, similar to how color palettes can be customized.

This would make it much easier for developers to achieve a contemporary look without overriding shadows throughout their application.

Examples

Many modern design systems, including Material Design 3, use softer, lower-contrast shadows. Providing built-in shadow presets would allow applications to easily adopt different visual styles without overriding the entire theme.shadows array.

Motivation

Shadows are one of the most noticeable aspects of an application's visual design. While MUI already makes colors, typography, and spacing easy to customize, shadows still require replacing the entire shadow array. Built-in shadow themes or a modern default would improve aesthetics and reduce customization effort.

Search keywords: modern box shadow theme

[SiddGud]

Hi @zannager! I agree that having modern built-in shadow presets would be awesome for developer experience. I would love to work on a PR for this.

My proposal would be to allow passing a preset string like 'soft' | 'material3' | 'flat' into createTheme({ shadows: 'soft' }), or export a clean shadowPresets helper object from @mui/material/styles.

Would the team be open to a PR implementing optional modern presets in the theme creator?

[mordeccai]

Update?

[SiddGud]

Hey @mordeccai , just waiting for the approval from @siriwatknp

I've got an implementation locally that adds clean presets (soft, material3, flat) so you don't have to override the whole 25-item array. Can open a draft PR whenever the team is ready

[mordeccai]

@siriwatknp we are still waiting for an update please.

[siriwatknp]

Thanks for the proposal and the patience.

We don't want to ship a fixed set of named presets (soft/material3/flat) inside the library.

Maintaining opinionated shadow themes is not something we want to own. Taste varies too much for a small fixed list.

The direction we prefer: let you replace the theme.shadows structure itself.

You can change its shape from the default 25-item array to something semantic like Record<'xs' | 'sm' | 'md' | 'lg' | 'xl', string>.

For typings, this uses an augmentable marker interface. Same pattern as BreakpointOverrides:

declare module '@mui/material/styles' {
  interface ShadowsOverrides {
    xs: true;
    sm: true;
    md: true;
    lg: true;
    xl: true;
  }
}

Shadows becomes a derived type. It switches from the default array to a Record when the marker is augmented.

One trade-off, and it is intentional.

Components like Paper, Button, Fab read theme.shadows[elevation] by number. Once you change the structure, those numeric slots no longer exist.

So the built-in components will not pick up your new shadows automatically. You apply them through component styleOverrides.

Material UI gives you the structure and the types. Wiring the new tokens into components is on the app side.

Does this direction cover your use case?

cc @silviuaavram

[mordeccai]

@siriwatknp Thanks for the response.

I have to strongly disagree with this direction.

While design preferences certainly vary, I don't think it's accurate to suggest that shadows are entirely subjective. The default MUI shadows feel noticeably dated compared to the direction of modern UI design. Most contemporary design systems—including Material Design 3—have moved toward softer, lower-contrast, less "floaty" shadows.

There is a reason so many developers immediately override the default shadow array. It's one of the first things people customize because the defaults often make applications feel heavier and older than intended.

I also don't think the proposed solution addresses the underlying problem. Allowing developers to redefine the entire theme.shadows structure and then manually wire every component through styleOverrides is significantly more work than simply providing a modern default.

To me, this isn't about shipping dozens of opinionated themes. It's about keeping Material UI visually current. Just as typography, spacing, and colors evolve over time, shadows should evolve as well. Framework defaults influence thousands of applications, and today's defaults don't reflect the visual direction that much of the industry has adopted.

Is there a reason the Material Design guidelines prevent updating the default shadow system? If not, I'd encourage the team to reconsider whether the current defaults still represent modern UI design.

I suspect a large majority of developers would welcome a refreshed default shadow system without having to replace all 25 shadow values themselves.

[thisisgurkaran]

This ia great idea. I was looking for a solution to this for my previous project. We ended up building a custom component of our own. Any solution to this ?