Skip to content
HexSlate

CSS Filter Playground

CSS
.image {
  filter: sepia(45%) contrast(110%) saturate(85%) brightness(105%);
}
Tailwind v4
[filter:sepia(45%)_contrast(110%)_saturate(85%)_brightness(105%)]
4 of 4 steps active56 characters of CSS

Filter order changes the result

filter is a pipeline, not a set of options. Each function receives the pixels the previous one produced, so grayscale(1) sepia(1) ends up sepia and sepia(1) grayscale(1) ends up grey: the first drains the colour and the second tints what is left, the second tints and the third drains it again. Almost every filter generator fixes the order and hides this, which is why the list above is reorderable and why the arrows are the most useful control on the page.

The same applies to the pairing people reach for most: brightness() before contrast() lifts the whole image and then stretches it around the new midpoint, while contrast() first stretches around the original midpoint and then lifts, which clips the highlights sooner. Neither is wrong. They are different edits.

The bounds are the specification's, not ours

grayscale(), sepia(), invert() and opacity() are clamped to 0 and 100%, because past full they have no meaning. brightness(), contrast() and saturate() are not: anything from 0 upward is legal, and going past 100% is the entire reason to use them. saturate(300%) is a valid, useful, aggressive edit. hue-rotate() takes any angle and wraps, so 380deg and 20deg are the same rotation.

A function sitting at the value where it does nothing is left out of the output entirely. That is why switching a step off and setting it to its neutral value produce the same CSS, and why the copied declaration never contains saturate(100%).

filter and backdrop-filter are different properties

filter processes the element and everything inside it. backdrop-filter processes whatever is painted behind it and leaves the element's own content sharp, which is the whole frosted-glass effect. Two things bite people here: the element needs a partially transparent background or there is nothing to see through, and Safari still requires -webkit-backdrop-filter alongside the standard property. Both lines are in the output above when the toggle is on.

Common problems

  • The blur has a soft, faded edge.blur() samples transparent pixels from outside the element, so the border fades out. Put the blur on a child with overflow: hidden on the parent, and scale the child slightly past its box.
  • A fixed-position child stopped being fixed. Any filter other than none creates a containing block for descendants, exactly as a transform does, so position: fixed inside it anchors to the filtered element instead.
  • drop-shadow looks the same as box-shadow. On a rectangle it does. drop-shadow() follows the alpha channel, so on a transparent PNG or an SVG icon it traces the artwork and box-shadow traces the box. It costs more to paint, and it takes no spread value.
  • Scrolling stutters. A filter repaints on every frame it is composited. A large blurred backdrop-filter over a scrolling list is the usual culprit; reduce the blur radius or the filtered area, not the frame rate.

Frequently asked questions

Does my image get uploaded?

No, and it is not even read. The file is turned into an object URL, which is a pointer the browser resolves locally, so nothing is decoded, re-encoded or transmitted. That is also why a large photo appears instantly, and why the link you copy shows the sample scene rather than your picture: an object URL is meaningless outside this tab.

Why does the tool emit a plain declaration for Tailwind?

Tailwind's filter utilities compose through separate custom properties in a fixed order, so the order you set here would not survive. The arbitrary-property form [filter:…] is one declaration and keeps the pipeline exactly as shown.

Can I filter only part of an element?

Not with this property. Use a pseudo-element or a child that covers the region, filter that, and clip it. For anything shaped, filter: url(#id) pointing at an inline SVG filter is the full-power version of the same feature.

Are these filters colour-managed?

They operate in sRGB by default, which is why a heavy saturate() on a wide-gamut image can look different from the same edit in a photo editor. The SVG filter equivalents let you choose linearRGB, and the difference is most visible in blurs and in anything touching the highlights.