Neumorphism Generator

Features

• An adjustable surface colour from which both shadows are derived (same hue, different lightness)
• Adjustable offset distance, blur radius and intensity
• Raised and inset in one toggle — inset swaps the direction of both shadows
• Adjustable corner radius
• The preview backdrop matches the surface, which is what makes the effect hold together
• A complete copyable CSS rule below, with a `.soft` selector
• Values are clamped and colours validated, so the CSS stays valid
• Everything is computed in your browser; nothing is uploaded

How to use

1. Pick the surface first: the whole effect depends on it, and a pale grey-blue is the archetypal choice
2. Adjust distance and blur to set how far the element sits above the surface
3. Use intensity for the darkness of the shadows — too much and the page looks grubby
4. Tick "inset" to see the pressed state, then copy the CSS

FAQ

Why can I not choose the shadow colours?

Because a small error destroys the effect. The two colours have to satisfy two conditions: derived from the same surface, and sharing its hue — otherwise it does not read as light falling on one material, but as two mismatched patches stuck on. The common hand-rolled approach, "add 40 to each RGB channel", shifts the hue as well (obvious on a warm surface, where it comes out cold and whitish). So this moves lightness in HSL and nudges saturation, leaving the hue untouched, and asks you only for a surface.

How bad is the accessibility problem, really?

Significant — and it is intrinsic to the style, not a matter of doing it badly. Its beauty comes from the element and the background being nearly the same colour, while accessibility asks for enough contrast between them. The two are in direct conflict. Concretely: users with reduced vision, or anyone in bright light, cannot see which parts are buttons. Three workable mitigations: keep critical actions (submit, delete) out of pure neumorphism — give them a border or an explicit label; keep hit areas generous (44×44pt and up); and use the inset state for `:active` so the press gives more feedback than the resting state.

Why does the preview backdrop match the element?

Because that is the precondition for the whole effect: it assumes the element and its surroundings are one material with light coming from the top left. With a different colour around it the two shadows give themselves away at the edges — it looks like a sticker rather than something pressed out of the surface. So the preview follows the surface colour here, and in a real project the element must also sit on a background of the same colour.

Where should I use the inset state?

Raised (the default) is for things you can press: buttons, cards, the off state of a switch. Inset has two uses: the pressed state (`:active`, where the contrast against raised gives the most natural feedback), and recessed containers such as inputs and progress tracks — those are semantically "dented in" already. The toggle here lets you compare the two before deciding.

What kind of project suits this style?

It suits interfaces with few elements, generous space and low information density: settings panels, control surfaces, players, dashboards — a few large buttons on open ground. It does not suit dense interfaces. Tables, lists and admin screens rely on borders and dividers to create hierarchy, and neumorphism removes exactly those, so everything smears together. That is also why, after a spell of popularity around 2020, it mostly lives in concept work.