DEV Community: Björn Crombach

Dynamic Border-Image Recoloring with SVG Filters

Björn Crombach — Mon, 09 Mar 2026 18:56:42 +0000

border-image has been supported in CSS for many years and allows complex decorative borders without additional markup. It works particularly well for pixel-art, where alternatives like clip-path or box-shadow quickly become difficult to maintain as the design becomes more detailed. border-image keeps the complexity constant, regardless of the level of detail in the design because it is handled as an image.

However, border-image has one major limitation: it is static. If you want multiple states (hover, active, focus-visible, theme variants), you normally need multiple image assets. This will result in more HTTP requests, more data being transferred and more image files that need to be maintained and handled.

One solution I found was to use SVG filters to dynamically recolor border-image files by referencing the filter via url(). In practice the filter is applied to a pseudo-element that renders the border-image so that the filter does not affect the content inside the element.

border-image: url("fileName.png") 8 fill;
/* Re-color the border-image */
filter: url("#remap");

<!-- Invisible SVG filter for color remapping -->
<svg
    xmlns="http://www.w3.org/2000/svg"
    style="position: absolute; width: 0; height: 0; overflow: hidden"
>
    <filter id="remap" color-interpolation-filters="sRGB">
    <feColorMatrix
        id="svg-matrix"
        type="matrix"
        values="
            1  0  0  0  0
            0  1  0  0  0
            0  0  1  0  0
            0  0  0  1  0
        "
    />
    </filter>
</svg>

For this to work, we first need to create a specialised asset. Each region that should be able to receive a specific color must use a unique placeholder color. The filter then uses these placeholder colors as keys and remaps them to the desired output colors. Then we create multiple SVG filters that transform the image into each desired state. See the following demo to see this in action on a pixel art button.

codepen.io

Another use case for dynamic recoloring could be to support more color themes, or simply light and dark variants.

Recoloring

The first approach I took was to use the feColorMatrix filter to remap red, green, blue and black pixels to the target colors. While this worked, it was limited to only four colors.

codepen.io

The next approach was to replace feColorMatrix with feComponentTransfer to build a look-up table (LUT) for greyscale texture maps.

feComponentTransfer allows remapping individual color channels using lookup tables with up to 256 discrete slots while preserving the full transparency range. When applied to a grayscale asset, the filter effectively becomes a palette lookup: each gray value acts as an index into the color table and is mapped to a corresponding output color.

<!-- Invisible SVG filter for color remapping -->
<svg
    xmlns="http://www.w3.org/2000/svg"
    style="position: absolute; width: 0; height: 0; overflow: hidden"
>
    <filter id="palette-remap" color-interpolation-filters="sRGB">
    <feComponentTransfer>
        <feFuncR id="fr" type="discrete" tableValues="0 0 0 0 0 0 0 0 0 0" />
        <feFuncG id="fg" type="discrete" tableValues="0 0 0 0 0 0 0 0 0 0" />
        <feFuncB id="fb" type="discrete" tableValues="0 0 0 0 0 0 0 0 0 0" />
    </feComponentTransfer>
    </filter>
</svg>

codepen.io

An even more powerful approach that came to mind was to utilise all channels, essentially trying something similar to channel packing, which is commonly used in game engines to combine multiple greyscale maps into one image for data transport.

To achieve this, we combine both techniques. feColorMatrix is used to isolate individual channels (R, G, B), while feComponentTransfer applies the lookup table that remaps the grayscale values to their target colors. This filter setup is repeated for each channel.

<svg
    xmlns="http://www.w3.org/2000/svg"
    style="position: absolute; width: 0; height: 0; overflow: hidden"
>
    <!-- R channel: extract + remap (7 slots, tableSize=7) -->
    <filter id="unpack-r" color-interpolation-filters="sRGB">
    <feColorMatrix
        type="matrix"
        values="
        1 0 0 0 0
        1 0 0 0 0
        1 0 0 0 0
        1 0 0 0 0
    "
    />
    <feComponentTransfer>
        <feFuncR id="ur-r" type="discrete" tableValues="0 0 0 0 0 0 0" />
        <feFuncG id="ur-g" type="discrete" tableValues="0 0 0 0 0 0 0" />
        <feFuncB id="ur-b" type="discrete" tableValues="0 0 0 0 0 0 0" />
        <feFuncA type="linear" slope="255" intercept="0" />
    </feComponentTransfer>
    </filter>

    <!-- ... Other channels -->
</svg>

However, the alpha channel turned out to be problematic. Browsers internally premultiply RGB values with the alpha channel before the image reaches the SVG filter. This means that storing an independent texture map in the alpha channel corrupts the RGB data, making it unsuitable for channel packing.

Another limitation of this approach is that it cannot fully support transparency when independent texture maps are used in each channel, as can be seen in the demo below. To support basic visibility of pixels, I decided that #000 should be treated as fully transparent. This means that we lose one slot per channel (leaving us with 255 slots), but gain support for pixel visibility.

While this approach is by far the most complex, it reduces the number of requests and file size even further. The packed texture in the following demo is only 432 bytes, but it serves three border-images.

codepen.io

Conclusion

While the last approach is technically very interesting, I don't think it justifies the extra complexity and preparation needed to fully utilise it, unless you really want to optimise to the limit.
The first approach is fairly simple, but it lacks flexibility because it does not support enough colors.
In my opinion, the second approach, which uses the greyscale asset, is the winner, as it allows for a large number of color slots while keeping the concept simple.

SVG filters are GPU-accelerated in modern browsers. The filters used in these demos are particularly efficient because they operate per pixel and do not require sampling neighbouring pixels.

Modern CSS Spritesheets with Native HTML Elements

Björn Crombach — Mon, 12 May 2025 18:14:40 +0000

The common approach to using sprite sheets involves applying CSS classes with pre-calculated coordinates to control the positioning within the sheet. This typically relies on background-image, which does not natively support features like alt text or lazy loading that come built-in with <img> elements. Additionally, using <img> can improve accessibility and semantics depending on how the image is used.

This approach builds upon an article on css-tricks, and expands it by introducing scaling of the individual sprites.

Skip to Codepen Demo

object-fit: none and object-position: x y allow us to select specific areas of an image which is the basis of this idea. The object-position values need to be pre-calculated, just like in the class-based approach. This could be stored as an object literal in a .ts file which would also generate typing for this object by using keyof and typeof.

// Automatically generated file!
export const Pokemon = {
    '0001-bulbasaur': {
        sheet: 'sp1',
        pos: { x: 0, y: 0 }
    },
    '0002-ivysaur': {
        sheet: 'sp1',
        pos: { x: -96, y: 0 }
    },
    '0003-venusaur': {
        sheet: 'sp1',
        pos: { x: -192, y: 0 }
    } // ...
} as const

export type PokemonType = keyof typeof Pokemon

To dynamically set the object-position on the <img> element, a helper function can be used:

export function setObjectPosition(pos: { x: number; y: number }) {
    return `object-position: ${pos.x}px ${pos.y}px;`
}

<!-- Svelte code -->
{#each Object.entries(Pokemon) as [name, data]}
    <div class="container">
        <img
            src={`/spritesheets/${data.sheet}.webp`}
            style={setObjectPosition(data.pos)}
            alt={name}
            loading="lazy"
        />
    </div>
{/each}

.container img {
    width: calc(var(--original-width) * 1px); /* 96 * 1px */
    height: calc(var(--original-height) * 1px); /* 96 * 1px */

    object-fit: none;
    /* object-position: x y; is directly set on the <img> element */
}

This will render a page with each element in the pre-calculated values Object as a separate image, cut out from the sprite sheet.

In order to change the size of these elements while maintaining the correct container size, we need to know the original size of the original single image before it was added to the sprite sheet. In this example it is 96px * 96px.

If we now want to display a smaller 64px * 64px version of this, we can use transform: scale(). It is important here to also use transform-origin: top left, as it would otherwise scale the image towards the center, leaving unwanted spacing around the image.

.container img {
    width: calc(var(--original-width) * 1px);
    height: calc(var(--original-height) * 1px);

    object-fit: none;
    /* object-position: x y; is directly set on the <img> element */

    transform: scaleX(var(--scale-factor-x)) scaleY(var(--scale-factor-y));
    transform-origin: top left;
}

This has made the images visually smaller, but the container size is still like before, to fix this we can set width and height on the parent element.

.container {
    max-width: calc(var(--target-width) * 1px);
    max-height: calc(var(--target-height) * 1px);
}

To use variables for width, height and scale, they must be defined without a unit, because scale needs a unitless value, while width and height need a length value, which can be created by multiplying by 1 length unit e.g. *1 px.

:root {
    --target-width: 64;
    --target-height: 64;
    --original-width: 96;
    --original-height: 96;
    --scale-factor-x: calc(var(--target-width) / var(--original-width));
    --scale-factor-y: calc(var(--target-height) / var(--original-height));
}

Plain HTML, CSS, JS Demo

Conclusion

Benefits:

Using sprite sheets reduces the number of HTTP requests and can therefore improve performance, particularly in HTTP/1.1 environments where request overhead is more significant.
Sprite sheets also eliminate the "pop-in" effect of individual images, as all images are available immediately after a single request.

Downsides:

Generating the sprite sheets and maintaining a synchronized coordinate data structure adds an extra step to the build process.
Handling sprite sheets introduces significantly more code complexity compared to using regular images.
Sprite sheets are generally less flexible than standalone images.

Alternatives:

Depending on the style and use case, an icon font can offer a simpler and more reliable way to reduce requests.
HTTP/2 and HTTP/3 multiplexing, combined with good caching strategies, can help mitigate the performance impact of serving many individual images.
If sprite sheets are necessary, the traditional CSS class-based approach remains a valid and often simpler alternative.