CSS Box Shadow Generator
Presets
Layers
This CSS Box Shadow Generator is a free, browser-based tool that lets you build and export box shadows visually, without writing a single line of code.
Drag a slider and the preview updates instantly. Every property is right in front of you.
What you can control:
- Horizontal and vertical offset
- Blur and spread radius
- Shadow color and opacity
- Inset or outset direction
Stack multiple shadow layers for complex effects. Not sure where to start? Pick one of the 8 built-in presets like Soft Lift, Neon Glow, or Retro, then tweak from there.
The preview box is flexible too. Switch between rounded, square, circle, and card shapes. Change the box color and canvas background to match your actual design context.
When you're done, export in the format you need:
- Plain CSS
- A CSS custom property (
--shadow: ...) - A Tailwind config entry
- A React inline style object
Minify the output or keep it readable. Add the -webkit- prefix with one click. Copy and paste directly into your project.
No sign-up. No ads. Just a fast, clean tool that gets out of your way.
What Is a CSS Box Shadow Generator?
A CSS box shadow generator is a browser-based tool that turns slider and color inputs into ready-to-copy box-shadow syntax.
Instead of guessing offset and blur values by hand, you drag a few controls and the tool writes the declaration for you.
The whole tool is built around a single property in CSS, nothing more.
- It doesn't touch pixels or rasterize anything
- It doesn't design your layout, only one line of styling
- It doesn't replace a design tool's export step, just the manual math behind it
It's also not the same thing as a text shadow generator, which shades letterforms rather than element boxes.
What it actually produces is one string of code, ready to paste straight into a stylesheet.
How Does the box-shadow Property Work?
The box-shadow property draws a shadow using five values in a fixed order: horizontal offset, vertical offset, blur radius, spread radius, and color.
Skip a value and the browser falls back to its default, so a shadow with only two numbers still renders, just without blur or spread.
| Value | Controls | At zero or negative |
|---|---|---|
| Horizontal offset | Shadow position, left or right | Negative pushes the shadow left |
| Vertical offset | Shadow position, up or down | Negative pushes the shadow up |
| Blur radius | Edge softness | Zero gives a hard, sharp edge |
| Spread radius | Overall shadow size | Negative shrinks the shadow |
Order matters: swap blur and spread and the browser reads the second number as spread regardless of intent.
Outer Shadow vs Inset Shadow
Outer shadow: the default behavior, it sits behind the element as if the box were lifted off the page.
Inset shadow: adding the inset keyword flips the effect, so the shadow falls inside the element's edges as if it were pressed into the surface.
The keyword always goes first in the declaration, before any of the numeric values.
What Color Formats Can a Box Shadow Use?
A box-shadow color accepts any valid CSS color value: hex, rgb, rgba, hsl, or a named color like black.
rgba is the one that matters most for shadows, because its fourth value controls transparency.
- Hex: solid color only, no transparency channel
- rgba: red, green, blue, plus an alpha value between 0 and 1
- hsl / hsla: hue, saturation, lightness, with the same optional alpha slot
A shadow set to full opacity looks like a hard-edged block. Drop the alpha to something like 0.15 or 0.2 and it reads as a shadow instead of a shape.
Designers often hand off colors as hex codes from a mockup, and converting that hex value to rgba is usually the first real step in matching a generator's output to a comp.
The same goes the other direction. If a palette was built in HSL, translating an HSL pick into rgb or rgba keeps the shadow color consistent with the rest of the design system.
How Do You Layer Multiple Box Shadows in One Declaration?
Separate each shadow with a comma and the browser stacks them in a single box-shadow declaration.
Order controls depth: the first shadow listed sits on top, closest to the element, and each one after it sits further back.
A two-layer card shadow often looks like this:
box-shadow: 0 2px 4px rgba(0,0,0,0.2), 0 8px 16px rgba(0,0,0,0.15);The first shadow is tight and dark, doing the close-up work. The second is larger and softer, giving the illusion of ambient light falling around the whole object.
- Two layers: a tight contact shadow plus a soft ambient shadow
- Three layers: adds a third, even softer shadow for extra depth on large cards or modals
- No practical limit on layer count, though browsers slow down once you stack more than four or five
Single-div CSS loaders lean on this trick constantly, faking a ring of dots with one element instead of six separate nodes.
That's the same layering technique behind most entries in a CSS loader generator.
Which Browsers Support box-shadow, and Do You Need a Vendor Prefix?
No. Every current browser renders box-shadow without any prefix, and has for well over a decade.
The property reached Baseline Widely Available status on January 29, 2018, according to the web-features dataset that powers MDN's compatibility table.
That milestone actually landed years after browsers had already made the property safe to use.
- Chrome dropped the -webkit- prefix requirement at version 10, released March 2011
- Firefox dropped -moz- at version 4, also March 2011
- Safari followed at version 5.1, mid-2011
- Internet Explorer added unprefixed support at version 9, its first CSS3-aware release
The underlying specification, CSS Backgrounds and Borders Module Level 3, is still published by the W3C as a Candidate Recommendation Draft, not a finished Recommendation.
That's despite the box-shadow property itself being stable in browsers for well over a decade.
That gap between spec status and real-world reliability is exactly the kind of thing cross-browser compatibility testing is meant to catch.
A property working fine on your machine doesn't guarantee it behaves the same everywhere.
Old projects sometimes still carry -webkit-box-shadow or -moz-box-shadow declarations left over from a decade-old boilerplate. Deleting them today changes nothing in any supported browser.
Box Shadow Generator vs Writing CSS by Hand: Which Should You Use?
Use a generator for a one-off shadow, and reach for hand-coding once you're maintaining a design system with dozens of them.
The two aren't really rivals, more like tools suited to different stages of the same job.
| Method | Ease of use | Output accuracy | Best for |
|---|---|---|---|
| Generator tool | High, drag and copy | Good for single shadows | Quick one-off styling |
| Browser devtools | Medium, needs an existing element | Exact, live values | Fine-tuning an existing shadow |
| Hand-coded CSS | Low, requires memorizing syntax | Depends on the coder | Design systems, reusable tokens |
| Design tool export | High inside Figma or XD | Often needs manual cleanup | Handoff from design to code |
Devtools win on accuracy because you're editing a real element in a real layout. There's no guessing at how a value will look once it's dropped into your actual page.
Hand-coding wins once shadows become tokens.
A design system with elevation-1 through elevation-4 needs shared variables, not four separately generated strings that happen to look similar.
Most frontend teams face the identical trade-off with a different property entirely.
A quick background often starts life in a CSS gradient generator.
It usually gets rebuilt as hand-written custom properties once that gradient needs to live in five different components.
A generator also can't tell you when a shadow is the wrong tool entirely. That's a decision no slider will make for you.
Which Shadow Style Fits Which Design Goal?
Four shadow styles cover most real interfaces: soft, hard, neumorphic, and material elevation.
Each one is really just a different combination of blur, spread, and layering applied to the same property.
Soft Shadow
A soft shadow uses a wide blur radius and low opacity, so the edge fades out instead of stopping abruptly.
It's the default choice for cards, modals, and anything meant to feel like it's resting gently above the page.
Pros:
- Reads as calm and modern across almost any background
- Forgiving of small offset or color mistakes, since the blur hides sharp edges
Cons:
- Can look washed out or barely visible on busy backgrounds
- Overused across an entire page, it stops signaling depth at all
The CSS shadow effects gallery is a fast way to see soft shadows applied across buttons, cards, and headers side by side.
Hard Shadow
Zero blur, some spread, an offset that's easy to see. That's a hard shadow, and it reads as a graphic element rather than a lighting effect.
Pro: it gives interfaces a distinct, almost retro personality that soft shadows can't fake.
Con: it clashes badly with any UI that already leans soft or minimal, since the two styles don't blend.
Brutalist and neo-brutalist web design lean on hard shadows constantly, often paired with thick borders and flat colors instead of gradients.
Neumorphism
WCAG 2.1's non-text contrast rule requires a 3:1 ratio for interactive components, and most neumorphic interfaces fail it by design.
The style relies on two shadows, one light and one dark, sitting on a background barely different from the element itself.
That's exactly what creates the low-contrast problem.
| Pros | Cons |
|---|---|
| Distinctive, tactile visual identity | Frequently fails WCAG contrast checks |
| Strong on-brand feel for niche products | Interactive states are hard to distinguish |
| Works well for dashboards viewed by one trained audience | Poor fit for public-facing accessibility needs |
If a frosted, translucent look is closer to what you're after, that's a different technique entirely, built from backdrop blur rather than layered shadows.
A separate glassmorphism generator covers that style.
Material Elevation
Google's Material Design elevation guidelines map shadow depth to a z-space scale running from 0 to 24.
Each level ties to a specific dp value and a slightly different shadow.
Higher elevation means a larger, softer shadow, mimicking an object physically closer to the light source.
Where it excels: consistency across a large app, since every component picks a level instead of a one-off shadow value.
The system scales cleanly from buttons to modals.
Where it falls short: it's a full design system commitment, overkill for a single marketing page that just needs one nice card shadow.
Does box-shadow Affect Page Rendering Performance?
Yes, more than most properties. Box-shadow forces the browser to repaint pixels on every frame it changes. That's one of the more expensive steps in the rendering pipeline.
Google's rendering performance documentation puts the frame budget at roughly 16 milliseconds to hold 60fps, covering scripting, style, layout, and paint combined.
Painting is singled out in that same documentation as one of the costliest parts of that budget.
- Animating box-shadow directly triggers a repaint on every single frame
- Animating opacity or transform instead avoids that repaint almost entirely
- A static, unanimated box-shadow costs nothing extra once the page has painted
Tobias Ahlin's rendering tests found a workaround: put the shadow on a pseudo-element and animate that element's opacity instead of the shadow itself.
The visual result looks identical to animating box-shadow directly, just without hammering the paint step on every frame.
When Does box-shadow Not Apply?
box-shadow stops being the right tool the moment the shape you need isn't a rectangle.
The property always follows the element's box, or its border-radius if one is set. It has no idea what's inside that box.
- Transparent PNGs and logos: use filter: drop-shadow() instead, since it follows the alpha channel of the image rather than its rectangular frame
- Irregular vector shapes: a native SVG filter traces the actual path instead of a bounding box
- Cheap, constant animation: box-shadow forces a repaint on every frame, so an animated pseudo-element is the better pick
- Print stylesheets: most browsers strip box-shadow when printing by default
That second case matters most for logos and icons built in SVG, where a rectangular shadow behind a star or logo shape looks obviously wrong.
MDN's own documentation on filter: drop-shadow() makes the distinction explicit. box-shadow shadows the box, drop-shadow shadows the content.
A design tool's exported shadow can fail to translate cleanly too. Figma's drop shadow effect maps closely to box-shadow, but a glow built from layered fills usually has no clean CSS equivalent at all.
How Do You Use a CSS Box Shadow Generator, Step by Step?
The order below matches how most generators are actually laid out, left to right, top to bottom.
- Step 1: pick horizontal and vertical offset first, since these decide where the shadow sits before anything else matters
- Step 2: set the blur radius to control how soft or sharp the edge looks
- Step 3: adjust the spread radius only if the shadow needs to look bigger or smaller than the element itself
- Step 4: set color and opacity last, since a shadow's darkness only makes sense once its size and shape are settled
- Step 5: toggle inset on if the shadow needs to sit inside the element instead of behind it
- Step 6: preview the result against the actual background color the element will sit on, not the generator's default canvas
- Step 7: copy the generated box-shadow declaration and paste it into the element's stylesheet rule
Previewing against the wrong background is the most common reason a shadow looks perfect in the tool and wrong on the live page.
A generator's default preview area is usually plain white or light gray, which flatters almost any shadow value.
How Do You Add Generated box-shadow Code Into Tailwind CSS, Sass, or Bootstrap?
A generator hands you a raw box-shadow string. What you do with it next depends on which framework the project already uses.
| Framework | Where the value goes | Result |
|---|---|---|
| Tailwind CSS | boxShadow key in the theme config, or an arbitrary value class | shadow-brand or shadow-[value] utility |
| Sass | A variable or a reusable mixin | $shadow-card: 0 2px 4px rgba(0,0,0,0.2); |
| Bootstrap | Override one of three Sass shadow variables | $box-shadow, $box-shadow-sm, or $box-shadow-lg |
Tailwind ships with a fixed shadow scale out of the box.
Its current v4 documentation lists seven size utilities, from shadow-2xs up through shadow-2xl.
Each one maps to a CSS variable rather than a hardcoded value.
Dropping a generator's output into Tailwind means either replacing one of those seven variables or reaching for the shadow-[value] arbitrary syntax for a one-off.
Sass takes the value as-is. Storing it as a variable, $shadow-card for instance, is what turns a one-time generator output into something reusable across a whole component library.
Bootstrap is the most rigid of the three.
Its official documentation defines exactly four shadow classes, shadow-none, shadow-sm, shadow, and shadow-lg, built from three Sass variables.
A generator's custom value doesn't slot into Bootstrap directly. It has to replace one of those three variables before a recompile, or get applied as inline style.
Shopify's Polaris design system takes the token approach a step further.
It defines named shadow depths in its own tokens package instead of letting individual components carry raw box-shadow strings. That's the same instinct behind a Sass variable, just formalized as an actual design system.
What Are the Most Common box-shadow Mistakes?
Most box-shadow bugs come down to a handful of repeatable mistakes.
- Missing comma between layered shadows
- Blur and spread values swapped
- inset placed in the wrong position
- Shadow color left at full opacity
Two of these are silent. The browser doesn't throw an error, it just renders something that doesn't match what you intended.
| Mistake | What it looks like | Fix |
|---|---|---|
| Missing comma | Second shadow gets ignored or breaks the whole declaration | Separate every shadow with a comma, not a space |
| Blur and spread swapped | Shadow balloons far past the element's edge | Keep the order: offset-x, offset-y, blur, spread, color |
| inset placed last | The declaration is invalid and no shadow renders | inset always comes first, before any numbers |
| Full-opacity color | Shadow reads as a solid block instead of a shadow | Use rgba with an alpha around 0.15 to 0.3 |
Border-radius mismatches cause a quieter problem. A shadow on a rounded element still follows the border-radius automatically.
A shadow that looks square against rounded corners usually means the radius was set on a child element, not the one carrying the shadow.
Transparent backgrounds cause a similar confusion. A shadow renders around the element's box, not around whatever's visible inside it.
A transparent PNG sitting inside a div will still show a rectangular shadow, no matter how irregular the image itself looks.
FAQ on CSS Box Shadow Generator
What Is the Difference Between box-shadow and text-shadow?
text-shadow shades the letterforms of text content, while box-shadow shades the element's entire border-box.
A heading can carry both at once: a text-shadow behind its characters and a separate box-shadow behind the container that holds them.
Does box-shadow Work Correctly With border-radius on Rounded Elements?
Yes. A box-shadow automatically follows an element's border-radius, curving at the same corners instead of staying rectangular. If a shadow looks square on a rounded element, the radius sits on a child element, not the one carrying the shadow (see common mistakes).
Can box-shadow Be Animated With CSS Transitions?
Technically yes, though it comes at a cost: transitioning box-shadow forces the browser to repaint on every frame. A smoother alternative animates the opacity of a pseudo-element that already carries the shadow, as covered in the performance section.
How Do You Make a box-shadow Value Responsive Across Screen Sizes?
Scale offset, blur, and spread inside a media query, shrinking every value together as the viewport narrows.
A common pattern uses clamp() on the blur radius alone, letting one declaration adjust smoothly instead of writing a separate rule per breakpoint.
How Do You Reuse Generated CSS Across Multiple Projects?
Store the declaration once, in a CSS custom property like --shadow-card, instead of pasting the same string into every stylesheet.
Any project that imports the shared property file inherits the same shadow value, and a single edit updates it everywhere.
Where Does a CSS Box Shadow Generator Break Down?
A CSS box shadow generator breaks down once a project accumulates more than a dozen distinct shadow values across its component library. At that point a maintained token system replaces one-off generator output.
Fixing that sprawl follows a specific order, not a random cleanup pass.
- Cross-browser rendering check first
- Duplicate value consolidation second
- Token extraction into a shared design-token file third
Checking rendering first catches the rare bug before it gets baked into a dozen components. Consolidating near-duplicate values second removes the noise that makes token extraction painful.
Standardizing shadows into a fixed token set costs flexibility. A component can no longer request an arbitrary tuning without a small build step, trading one-off polish for consistency across the interface.
The next natural step is rounding that same element's corners with a dedicated border-radius generator, since shadow depth and corner radius get tuned together on almost every card or button.