{"id":9094,"date":"2026-04-09T09:00:06","date_gmt":"2026-04-09T14:00:06","guid":{"rendered":"https:\/\/frontendmasters.com\/blog\/?p=9094"},"modified":"2026-04-09T09:00:07","modified_gmt":"2026-04-09T14:00:07","slug":"svg-filters-guide-getting-started-with-the-basics","status":"publish","type":"post","link":"https:\/\/frontendmasters.com\/blog\/svg-filters-guide-getting-started-with-the-basics\/","title":{"rendered":"SVG Filters Guide: Getting Started with the Basics"},"content":{"rendered":"\n

Visual effects like those produced by SVG <filter><\/code>s used to live in the \u201chere be dragons\u201d<\/em> zone for me. I’m more of a tech, not an artist, so I usually steer clear of anything designery like UI, layout, typography, etc. My strength lies in building compact, logical solutions, not creating stunning aesthetics.<\/p>\n\n\n\n

That is, until I accidentally fell into it. A problem popped up, and I thought SVG filters might do the trick. One thing led to another, and deeper and deeper down the rabbit hole I went. Luckily, there’s mathematics involved, which, up to a certain point at least, makes sense to me.<\/p>\n\n\n\n

Since I’ve started posting SVG filter demos, people often ask me how to get started in this area. While I firmly believe the best way is to just start using SVG filters<\/em>, I’d also like to provide this starter’s guide, the stuff I wish I had read while getting into all this.<\/p>\n\n\n\n

Introduction to SVG filters<\/h2>\n\n\n\n

All SVG filters must live inside an <svg><\/code> element. If we use that element only<\/em> for defining filters (and not for rendering graphics as well), then it is functionally the same as a <style><\/code> element.<\/p>\n\n\n\n

So we set its dimensions to 0 and hide it from screen readers.<\/p>\n\n\n

<svg<\/span> width<\/span>='0'<\/span> height<\/span>='0'<\/span> aria-hidden<\/span>='true'<\/span>><\/span><\/svg<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
In CSS, we take it out of the document flow so it doesn’t affect the layout.<\/p>\n\n\n
svg<\/span>[aria-hidden='true'<\/span>]<\/span>[height='0'<\/span>]<\/span> { position<\/span>: fixed }<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
We do this because collapsing its dimensions to zero via width<\/code> and height<\/code> attributes may not be enough.<\/p>\n\n\n\n
Some scenarios may require, for example, setting display: grid<\/code> on the parent of the <svg><\/code> element. In such a case, the <svg><\/code> element takes up a grid cell by default. This is less than ideal, but setting position: fixed<\/code> (or any kind of positioning that removes the element from the document flow) on our <svg><\/code> solves the problem.<\/p>\n\n\n\n
We may now drop any number of <filter><\/code> elements inside this <svg><\/code> and reference them from the CSS.<\/p>\n\n\n\n
Every <filter><\/code> element needs to have an id<\/code> attribute set.<\/p>\n\n\n
<filter<\/span> id<\/span>=\"my-filter\"<\/span>><\/span><\/filter<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
This is used to apply the filter<\/code> on an element that becomes the filter input:<\/p>\n\n\n
.my-filtered-elem<\/span> { filter<\/span>: url<\/span>(#my-filter) }<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
SVG filters may be chained just like CSS ones:<\/p>\n\n\n
.my-filtered-elem<\/span> { filter<\/span>: url<\/span>(#my-1s<\/span>t-filter) url<\/span>(#my-2<\/span>nd-filter) }<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
They may also be chained with CSS ones:<\/p>\n\n\n
.my-filtered-elem<\/span> { filter<\/span>: url<\/span>(#my-1s<\/span>t-filter) blur<\/span>(.5rem<\/span>) url<\/span>(#my-2<\/span>nd-filter) }<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
All SVG filters doing something with the RGB channels need to have the color-interpolation-filters<\/code> attribute explicitly set in order to produce consistent results across browsers. This is because the default is inconsistent across browsers. Safari uses the sRGB<\/code> value, while Chrome and Firefox use the linearRGB<\/code> value.<\/p>\n\n\n\n
In theory<\/a>, the default is linearRGB<\/code>, so this is a bug in Safari. In practice, what we need in order for our computations to work correctly is sRGB<\/code>. We’re not going any further into this because I don’t fully get it myself, but for anyone curious, this is the only explanation<\/a> I’ve ever read that ever made any sense at all to me. In any case, just know that this is an attribute that almost always needs to be set, together with the id<\/code> attribute.<\/p>\n\n\n
<svg<\/span> width<\/span>='0'<\/span> height<\/span>='0'<\/span> aria-hidden<\/span>='true'<\/span>><\/span>\n  <filter<\/span> id<\/span>='my-filter'<\/span> color-interpolation-filters<\/span>='sRGB'<\/span>><\/span><\/filter<\/span>><\/span>\n<\/svg<\/span>><\/span><\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
The <filter><\/code> element may also get attributes specifying the filter region, which is the area the filter effect is clipped to. Four attributes are used to define the filter region. First, we have the x<\/code> and y<\/code> attributes that give us the top-left corner coordinates of the filter region (where it starts) relative to the filter input’s bounding box. Then we have width<\/code> and height<\/code> attributes, which are the filter region dimensions.<\/p>\n\n\n\n
If we don’t specify any of these attributes, the browser default is a filter region whose dimensions are 120%<\/code> of the filter input’s bounding box. The extra 20%<\/code> gives room for effects like blur or drop\u2011shadow, which often spill outside the bounding box of the filtered element.<\/p>\n\n\n\n
\"Illustration.
why the filter region needs to be bigger than the filter input’s bounding box<\/figcaption><\/figure>\n\n\n\n
Also by default, this 120%<\/code> region is positioned symmetrically around the bounding box, so it starts at -10%<\/code> along both axes. This means the filter region goes from -10%<\/code> to 110%<\/code> of the input’s dimensions along both the x<\/em> and y<\/em> axes, so we have a 10%<\/code> buffer outside each of the four edges.<\/p>\n\n\n\n
\"Diagram
the default filter region<\/figcaption><\/figure>\n\n\n\n
Just like the values inside some CSS filters (for example saturate()<\/code> or opacity()<\/code>), these attributes can be set to either percentages or decimal values – width='200%<\/code> and width='2<\/code> produce the exact same result. So do y='-50%<\/code> and y='-.5<\/code>.<\/p>\n\n\n\n
There are two common reasons why we may need need to override the default filter region:<\/p>\n\n\n\n
For anyone just starting out and unsure about whether it’s really needed, it’s probably best to add it just to be on the safe side. And remember, it’s best to add it on the filter<\/code> element itself<\/a>, not on the individual elements inside it.<\/p>\n\n\n\n