Why does neumorphism need two shadows?

One light shadow (highlight) and one dark shadow (depth) — both tinted versions of the surface color. Together they fake the look of the element being extruded from the surface.

Is neumorphism accessible?

It's notoriously hard to make accessible — soft shadows don't provide enough contrast for interactive elements. Use it for decorative containers; pair with clear borders/text for buttons and inputs.

What background color works best?

Mid-tone grays (#e0e5ec is the canonical 'soft UI' base). Pure white or pure black surfaces don't show the shadows — you need room for both the highlight and depth tints.

neumorphism · soft-ui · live preview · css

Build a neumorphism shape

Q: Is anything sent to a server?

No — runs entirely in your browser.

Soft-UI box-shadow builder — automatic light/dark shadow pair derived from the background color. Toggle inset for pressed states.

Neumorphism Generator

#E0E5EC

surface

Size

20px

distance

Radius

50px

corner

Mode

outset

raised

input · color

Surface color

Shadow size — 20px

Intensity — 15%

Corner radius — 50px

output · preview

Live preview

border-radius: 50px;
background: #e0e5ec;
box-shadow: 20px 20px 40px #b1bdcf, -20px -20px 40px #ffffff;

Quick Start

How to build a neumorphism shape

Pick a soft mid-tone bg, then tune size/intensity/radius until the surface looks right.

01
Pick the surface
Mid-light colors work best (#e0e5ec). Pure white or black ruin the effect.
Colors round-trip through a normalised OKLCH representation, so manipulations (lighten, mix, contrast) preserve perceptual uniformity per CSS Color 4.
bgOKLCHCSS Color 4perceptuallive
bg · colorhex · sRGB
```
#e0e5ec
```
loaded · normalisedOKLCH · ready
02
Adjust intensity
The auto light/dark shadows are derived from this percentage.
Format conversion handles hex, rgb(), hsl(), oklch(), color(display-p3 …) with proper gamut mapping when crossing colour spaces.
inthex · rgb · hslP3gamut-mappedlive
int · options15% · live
```
±15% light/dark
```
options applied · livelive
03
Toggle inset
Outset = raised. Inset = pressed (great for active states).
Contrast and accessibility checks evaluate against WCAG 2.2 AA (4.5:1) and AAA (7:1) thresholds; APCA is offered when contrast is the goal.
stateWCAG 2.2APCAAA · AAAcontrast
state · convertedoutset · ready
```
raised / pressed
```
converted · liveWCAG-aware
04
Copy CSS
The full declaration includes border-radius and background.
Copy formats any swatch in the chosen syntax (#aabbcc, rgb(170 187 204), etc.); downloads emit CSS variable blocks or palette JSON.
shipclipboardCSS varspalette JSONblob
ok · copiedready · done
```
✓ Copied
```
shipped · ready to shipsuccess

Pro tips

Colour work that survives accessibility audits

Use OKLCH for manipulation

OKLCH is perceptually uniform — lightness changes look uniform. hsl() isn’t, and produces muddy mid-tones.

Test against WCAG 2.2

4.5:1 for normal text (AA), 7:1 for AAA. Use Contrast Checker before shipping.

Mind gamut clipping

P3 colours that exceed sRGB get clipped on standard displays. Choose relative colorimetric in CSS Color 4.

Colour blindness affects 8%

Use the Color Blindness simulator to check critical UI before launch.

Don’t hardcode hex

Use CSS variables. Light/dark themes become trivial when colours are tokenised.

Dark mode isn’t inverted

Don’t simply invert lightness — desaturate slightly and re-pick accents. Pure-inverted UIs look harsh.

Use Cases

When to use neumorphism

Soft UI, theming, decorative surfaces.

Soft UI dashboards

Build cohesive monochrome cards with raised/pressed states. Conversions go through OKLCH so perceptual lightness stays uniform across hues — a 50% L blue looks as bright as a 50% L yellow. HSL fakes this and produces muddy mid-tones, OKLCH solves it per CSS Color 4.

WCAG 2.2 AA

Decorative buttons

Pressed-button feedback without changing color. WCAG 2.2 contrast is sampled live for AA (4.5:1) and AAA (7:1) — flip foreground/background to test both directions. APCA is offered when contrast itself is the goal (e.g., dataviz).

P3-aware

Sliders & toggles

Recessed tracks with raised thumbs. Output covers hex, rgb(), hsl(), oklch(), and color(display-p3 …) for CSS Color 4. Drop straight into Tailwind config, CSS custom properties, or Figma without re-typing values.

perceptually-uniform

Avatars & badges

Soft-elevated circular surfaces. Pair with the Contrast Checker before shipping any new theme. Catches accessibility regressions before they become bugs filed against you by users with low vision.

gamut-safe

Quick prototyping

Beat hand-tuning matched-pair shadows. Tokens drop straight into Figma variables, Tailwind config, or CSS custom properties. Theme switching becomes a single variable swap rather than a search-replace across stylesheets.

a11y-ready

Cross-tool

Drop into CSS or styled-components. Gamut-aware: tools warn before you ship a P3 colour that clips on sRGB displays. Choose the appropriate fallback strategy (relative colorimetric vs perceptual) per CSS Color 4 spec.

design-token

FAQ

Frequently asked questions

Why does it look bad on white?

Neumorphism needs a mid-tone bg so both lighter and darker shadows are visible.

Is it accessible?

Often not — low contrast affordances. Combine with stronger focus/hover states.

Can I tint the shadows differently?

We auto-derive light/dark from bg. For custom shadow colors use the Box Shadow generator.

Why two shadows?

One darker (bottom-right), one lighter (top-left) — simulates directional light.

Is anything sent to a server?

No — generated locally.

Suggest a tool

Something missing?

Tell us what you need. We ship the top requests every two weeks.

47 in queue·8 shipped this month

Request queued. Thanks!