18 Pure CSS4 Light JSPublished 9 new designs · Updated on
Neumorphism renders an element as if it were pushed out of its own background — one dark shadow, one light shadow, and a surface that matches its parent exactly. These 22 hand-coded patterns cover the dual-shadow reference build, the light-source rule, deriving both shadows from one token with color-mix(), raised and inset state systems, dark-mode recalibration, and the contrast problem the style is rightly criticised for. Scoped under .nm-NN; drops into React, Vue, Svelte, or Astro.
Taking this style from one component to a whole product?
You just browsed 22 neumorphic patterns. Untitled UI is the Figma UI kit 380,000+ designers use, with 10,000+ components and variants in Pro, plus a matching React library on Tailwind CSS. Figma Pro is a one-time purchase from $129.
The reference build every other demo in this collection borrows from. One surface, one box-shadow declaration, both halves labelled in place: the dark shadow offset away from the light, the light shadow offset toward it. An annotation panel names all six values, and a side panel shows the effect collapsing the moment the surface stops matching its parent's background — the single rule the technique cannot survive without.
The two styles people conflate, rendered on the same background with both sides labelled. Neumorphism is opaque, the same colour as its parent, and lit by a mirrored shadow pair. Glassmorphism is translucent, blurs what sits behind it, and needs a light border to catch its edge. The practical rule sits underneath: soft UI needs a plain background, glass needs a busy one, which is why swapping one for the other rarely survives a redesign.
The three-state system that makes soft UI feel like something you can touch: raised for rest, inset for pressed, flat for inactive. One control is shown in all three states side by side and again as a live button you can press. Includes the trap nobody warns you about — an outset shadow does not interpolate into an inset one, so the transition jumps at the midpoint — and the two workarounds that fix it.
The most important demo here. Neumorphism's defining trait — an element the same colour as its background — is also its accessibility failure: there is no contrast at the boundary, so the control's edge is invisible to low-vision users and its affordance is invisible to everyone in bright sunlight. A naive soft-UI button is shown failing, then four fixes that keep the aesthetic intact, each with its measured contrast ratio printed beside it.
A complete button family in soft UI: primary, secondary, ghost, icon-only and destructive, each at three sizes, each with rest, hover, active, focus and disabled worked out. The press uses a shallow lift on hover and a genuine inset on active, so the control feels like it travels. Every variant carries a boundary border and a real focus ring, because a button nobody can find is not a button.
One surface token feeds an entire soft-UI palette. Four cards on four different surface colours — grey, sand, sage, slate — all rendering from the same component CSS, because both shadow colours are derived with color-mix(in oklab) rather than hardcoded. Includes the pair of cards showing what happens when you copy the standard blue-grey shadows onto a warm surface: the shadows read as dirt.
Newsletter
Enjoying these demos? Get new ones by email.
A short email when a new collection ships. Unsubscribe any time.
The fourth axis of soft UI after raised, inset and flat: surface curvature. A barely-there linear-gradient at the same angle as the light source makes a surface read as bulging toward you or dished away from you, without touching the shadow pair. Four tiles — flat, convex, concave, and pressure-dished — with their gradient stops printed underneath, plus the angle rule that keeps curvature and lighting consistent.
Switches, checkboxes and radios in soft UI, built on real form inputs rather than divs. The track is an inset well, the knob is a raised puck, and the on state changes colour and position and label — never depth alone. Keyboard focus, disabled and indeterminate states are all handled, and the whole set works with the native input hidden but still reachable.
Take the mirrored shadow pair and set blur to zero. What comes out is a legible, high-contrast cousin of soft UI that keeps the extrusion logic but reads clearly on cheap screens and in sunlight — a practical middle ground between neumorphism and neubrutalism. Three depths, an interactive press that slides the object into its own shadow, and a direct comparison against the blurred original.
Soft UI's hardest layout problem: everything is the same colour, so hierarchy has to come from depth alone — and depth runs out of range after about three levels. A grid of cards on an explicit three-step elevation scale, with nested surfaces showing where the scale breaks, and the compensations that let a nested inset well read clearly inside a raised card.
Text fields, search, select and textarea as carved wells. An inset shadow makes a field look like something you can type into — the strongest affordance soft UI has — but it also hides the focus state, so the focus ring here is a real outline with a colour shift on the icon. Includes the error and valid states that soft UI usually forgets, and the placeholder-contrast trap.
Twelve keys, twenty-four blurred shadows, and a measurable cost. A working soft-UI keypad with a live toggle between three shadow strategies — full blurred pairs, a single shadow, and a pre-composited parent — so you can watch the difference in a profiler. The lesson: box-shadow is cheap once and expensive in bulk, and the fix is almost never will-change.
Range inputs styled as carved tracks with raised pucks — soft UI's most convincing component, because a groove with a knob in it is a real object people already know how to use. Horizontal and vertical sliders plus a stepped one, all on native input[type=range], with the WebKit and Firefox pseudo-element pairs written out and the fill-before-thumb technique that neither engine supports natively.
Circular gauges as rings carved into the surface with a coloured arc filling the groove. Built on conic-gradient with a radial mask for the hole, an inset shadow for the channel, and a registered custom property so the arc can animate smoothly. Three sizes, an activity-ring stack, and the mask-versus-inner-circle trade-off spelled out.
Newsletter
Enjoying these demos? Get new ones by email.
A short email when a new collection ships. Unsubscribe any time.
A vertical rail and a mobile bottom bar where the current page is a pressed-in well and everything else sits flush. The active state is carried by depth, an accent bar, colour and aria-current together — because on a nav, getting the current-page indicator wrong is the difference between an interface and a maze.
Dark neumorphism is not the light theme with inverted colours — the mix ratios have to change or the surface looks flat and grimy. Side-by-side cards show the naive inversion against a recalibrated pair, with the numbers: darker surfaces need a much heavier shadow and a much weaker highlight, because there is no headroom above the surface and plenty below it.
The showcase piece: a player where every control is a physical object. Album art sunk into a recess, a scrubber running in a carved channel, transport buttons as convex pucks, and a play button that visibly stays pressed while playing. Eighteen lines of script drive play state and the scrubber; everything else is the depth system from the earlier demos, applied at once.
Two rules that decide whether a soft-UI interface looks designed or assembled: one light source for the whole page, and a radius scale that grows with the element. Twelve tiles show radius against size, a control panel shows what happens when three components disagree about where the light is, and the offset-to-radius relationship is spelled out with numbers.
Segmented controls and tab bars where the selected segment is pressed into the track and the rest sit flush. Built on radio inputs so the whole thing works without script, with the selected panel revealed by :has(). Includes the two-way version soft UI does best — a recessed track holding raised segments — and the filter-chip row that uses the same logic.
The layer soft UI cannot express: a modal has to sit above everything, and depth-by-shadow has already run out at three levels. The answer is to change technique — a scrim to separate the layers plus the deepest shadow in the system — built on the native <dialog> element so focus trapping, Escape and inertness come for free.
The hardest test of soft UI: dense data, where every widget competing for depth turns the screen to mush. Five widgets — stat, bar chart, sparkline, gauge, list — on a strict depth budget, with a density toggle showing the same data comfortable and compact. The rule that saves it: data lives in wells, chrome is raised, and nothing else gets a shadow.
The closing argument. Four contexts where soft UI is the right call, four where it is actively harmful, and the hybrid that most production teams should actually ship: a flat, accessible base with soft-UI depth applied to the two or three controls that benefit. Includes the checklist to run before committing, and an honest account of what the style costs.
FAQ
Frequently asked questions
How do you make a neumorphism effect in CSS?
Two shadows on one element, and one rule that most tutorials leave out. The shadows are a pair: a dark one offset in the direction light is falling away from, and a light one offset toward the light source, both with a generous blur. Written together they read as a single declaration — something like box-shadow: 8px 8px 16px [dark], -8px -8px 16px [light]. The rule that actually makes it work is that the element's background colour must be identical to its parent's. The illusion is that the surface was pushed out of the page rather than placed on top of it, and the moment the two colours differ, the eye reads a card with two shadows instead. That is why pasting a neumorphic component onto a gradient or an image background looks broken no matter how carefully the shadows are tuned. Demo 01 is the annotated reference build and shows the effect collapsing when that rule is violated.
Is neumorphism accessible, and can it pass WCAG?
It can, but not by default, and the criticism the style attracts is fair. The defining trait — an element the same colour as its background — means there is no colour contrast at the element's boundary, so its edge is invisible to low-vision users and its affordance is weak for everyone in bright light. WCAG 2.2 SC 1.4.11 requires 3:1 contrast for the boundary of an interactive element, and shadow alone does not supply it. Three fixes keep the aesthetic intact: give interactive elements a real border or inner edge that meets 3:1, keep text at the full 4.5:1 against the surface rather than tinting it into the background, and make :focus-visible a genuine ring rather than a shadow swap, since swapping outset for inset changes almost nothing measurable at the boundary. The related trap is signalling state by shadow direction alone, which fails SC 1.4.1 because a raised-versus-pressed difference is not perceivable to everyone. Demo 04 shows a naive soft-UI button failing with a live contrast readout, then the corrected version beside it.
What is the difference between neumorphism and glassmorphism?
They solve opposite problems and are frequently swapped for each other by mistake. Neumorphism is opaque: the surface matches its parent exactly, the depth comes entirely from a dual shadow, and nothing behind the element shows through. Glassmorphism is translucent: it uses backdrop-filter to blur whatever sits behind it, adds a light border to catch the edge, and depends on there being something interesting back there to blur. The practical consequence is that they need opposite backgrounds. Neumorphism needs a plain, flat ground — put it over an image and the illusion collapses. Glassmorphism needs a busy ground — put it over flat grey and it looks like a slightly foggy rectangle. That is why swapping one for the other during a redesign almost never survives contact with the actual page. Demo 02 renders both on the same background, labelled, so the difference is visible rather than described.
How do I pick the two shadow colours?
Derive both from the surface colour rather than picking them by hand, because hardcoded greys break the moment you change the surface. The dark shadow is the surface darkened, the light shadow is the surface lightened, and color-mix() expresses that directly from a single token — which is what lets an entire palette retint when you edit one value. Two details matter beyond the arithmetic. The lightening and darkening should not be symmetrical on dark surfaces, which is the subject of demo 16. And every element on a page must share one light direction: if one card's highlight sits top-left while its neighbour's sits top-right, the page reads as broken even though no individual element looks wrong. Demo 05 drives every shadow on the page from one light-angle custom property, with one element deliberately inconsistent so the effect is obvious.
Why does neumorphism look bad in dark mode?
Because most implementations invert the light palette and stop there, which produces mud. On a light surface the light shadow reads as a highlight catching real light; invert the same values onto a dark surface and that highlight becomes a grey smear sitting on top of the element rather than lighting it. The fix is asymmetric rather than mirrored: on dark surfaces the highlight has to be dimmer and tighter than the shadow, not its equal and opposite. The second requirement is headroom — the surface must sit meaningfully above pure black, because a near-black surface cannot be darkened any further and the dark half of the pair simply disappears. The same constraint applies at the light end, which is why near-white surfaces fail too. Demo 16 puts the naive inversion beside a correctly recalibrated pair with the actual ratios listed.
Does box-shadow hurt performance?
It costs paint, and neumorphism uses more of it than most styles because every surface carries at least two shadows and often four once inset states are involved. A static layout is fine on any modern device. The problems appear in two places. Animating box-shadow repaints on every frame, so a press transition on a large blur radius across many elements is measurably expensive — transition transform and swap the shadow discretely instead where you can. And large blur radii multiplied across a dense grid add up, which is why a dashboard of twenty soft-UI tiles can feel sluggish on a mid-range phone while a single card is instant. Demo 12 measures the difference directly on a keypad, which is the densest arrangement in the collection.
When should you not use neumorphism?
Whenever affordance matters more than atmosphere. Dense data tables suffer because a shadow on every row is visual noise rather than hierarchy. Anything under time pressure or stress — checkout, error recovery, authentication — needs controls that are unmistakably controls, and low-contrast surfaces work against that. High-ambient-light contexts wash out the subtle value differences the style depends on entirely. And any surface where the background is an image or gradient is simply the wrong ground, since the technique requires a flat parent. Where it genuinely shines is calm, single-purpose panels: media and smart-home controls, focus and wellness apps, dashboards with room to breathe — contexts where the physical-control metaphor helps and nothing is urgent. Demo 22 walks each verdict with a miniature example rather than leaving it as advice.
How do I use these in React, Vue, Svelte, or Tailwind?
Every demo is framework-agnostic HTML and CSS scoped under a unique .nm-NN root, and 18 of the 22 need no JavaScript at all. The scoping matters more in this collection than most: neumorphism is a token-driven style, so each demo declares its own surface, shadow, and accent custom properties, and every one of them is namespaced. An unscoped --surface or --primary would inherit from whatever the host application defines and silently retint the component. When porting, keep the whole token block together — the shadow pair is derived from the surface value, so moving one without the others is what produces the washed-out result people report after copying a snippet. Tailwind users can lift the rules into @layer components on v3, or declare the same tokens in @theme on v4 so utilities and demo CSS share one source of truth.
