Inset vs. Drop Shadow: Which One Your Design Actually Needs

A card and a pressed button can use the exact same offset, blur, spread and opacity values and still look completely different, because one setting decides which side of the element's border the shadow paints on: outside, for something that should look raised, or inside, for something that should look pushed in. Getting that one checkbox backwards is the fastest way to make a design read wrong even though every number is technically correct.

What "raised" actually needs: an outer shadow

Cards, modals, floating action buttons, dropdown menus, tooltips - anything meant to look like it's sitting a little above the rest of the page uses a normal, outer shadow, Inset left unchecked. A card in the tool's default preview (after Start fresh) reads as raised with nothing more than box-shadow: 0px 4px 12px 0px rgba(0, 0, 0, 0.25);, and for anything that needs to look genuinely elevated rather than just gently lifted, stacking a second, softer layer further out - the "layered" preset - reads more convincingly than pushing one layer's numbers higher, for the reasons covered in the depth-shadow guide.

What "pressed" or "sunken" actually needs: an inset shadow

A button in its active/pressed state, a search input, a progress track, a well something else visually sits inside - all of these want the opposite visual claim: this surface is a hollow, not a platform. The tool's inset preset, box-shadow: inset 0px 2px 6px 0px rgba(0, 0, 0, 0.25);, is the same shape of value as the default outer shadow with one flag flipped, and it reads as a dent rather than a lift the instant it renders. A common, effective pattern for a pressed-button state is switching a button's own shadow from a small outer lift to a small inset shadow on :active - nothing else about the element needs to change for the state swap to read correctly.

The mistake that's easy to make and easy to miss

Because inset changes only where the shadow paints and not its shape, a hastily-checked or unchecked Inset box produces something that still looks like "a shadow" in a quick glance - it just claims the wrong thing about the surface underneath it. A search field with an outer shadow instead of an inset one reads as a floating pill rather than a receptacle to type into; a "pressed" button state that uses an outer shadow instead of inset never actually looks pressed, just slightly re-lit. Neither is a rendering bug. Both are a shadow doing its job on the wrong side of the border.

Animating between the two, not just switching instantly

A button that shifts from a small outer lift to a small inset shadow on :active reads as a genuine physical press if the change animates smoothly rather than snapping between the two states in a single frame. One catch: browsers cannot interpolate an outer shadow into an inset one - a shadow pair only animates when both sides are inset or both are outer, otherwise it snaps. The working pattern is to list both layers in both states and fade the unused one to zero: 0 2px 4px rgba(0,0,0,0.2), inset 0 0 0 rgba(0,0,0,0) at rest and 0 0 0 rgba(0,0,0,0), inset 0 2px 6px rgba(0,0,0,0.25) on :active. That is fine for one button; on a whole grid of cards animating together, repainting every shadow each frame is a heavier cost worth avoiding.

A quick way to check which one a design needs

Ask what the element is doing relative to the page around it: is it sitting on top of something (a card, a menu, a tooltip - outer), or is something else sitting inside of it (a pressed button, an input, a well - inset)? If the honest answer is "it's just a container with no particular depth claim," a subtle outer shadow (the tool's own subtle preset) is usually the safer default - it reads as a gentle lift without over-claiming elevation the element doesn't actually need in the layout.

Box-shadow generator lets you toggle Inset on the same layer instantly and compare both directions live before deciding which one the design actually needs.