Your SVG icon will not change colour: five causes and the fix for each

The icon is on the page. The colour control is right there. You change it, and nothing happens — or the label changes colour and the icon does not. This is one of the most common frustrations with custom SVG icons, and it is not a bug in WordPress, Elementor, Webflow or your theme.

It is CSS working exactly as specified. Five situations produce this symptom, and each has a different fix, so the useful first step is working out which one you have.

The thirty-second diagnosis

Right-click the icon on your page and choose Inspect. What you see in the markup tells you almost everything:

• An img tag pointing at a .svg file, or a div with a background-image — that is cause 1, and no amount of CSS will fix it in place.
• An svg tag with path elements inside it, and each path carrying its own fill="#something" — cause 3.
• An svg tag containing a style element with rules like .cls-1 { fill: #000 } — cause 4.
• Attributes reading style="fill:#000" — cause 5.
• An svg tag whose only child is an image element with a long base64 string — cause 2, and the file is not really a vector.

Cause 1: the SVG is loaded as an image

If your icon is an img tag, or a CSS background-image, your stylesheet cannot touch it. This is not a restriction anyone chose to be awkward — an SVG loaded that way is a separate document, and by design a page's CSS does not reach into other documents it happens to be displaying. The browser treats it the way it treats a JPEG: something to paint, not something to style.

You can hold the most perfectly written recolourable SVG in existence and it will still be black in an img tag. This is the single most common cause, and the one people spend longest on because the file looks fine when they open it.

Fix: put the markup in the page

Open the SVG in a text editor, copy the whole thing, and paste it where the image was — a Custom HTML block in WordPress, an embed in Webflow, a component in React. Now it is part of the page and every rule can reach it. In Elementor, use the Icon widget rather than the Image widget: the Icon widget writes the markup into the page, the Image widget links to the file.

Fix, if it must stay a file: use it as a mask

There is one way to colour an SVG that stays an external file, and it is genuinely useful for icons that live in a stylesheet. Give the element the colour you want as its background-color, then use the SVG as a CSS mask rather than an image: mask, with a url pointing at the file, no-repeat, centre, contain. The browser paints the background colour through the shape of the SVG and the file's own colours are discarded entirely. Add the -webkit-mask version alongside it for older Safari.

Cause 2: it is not actually a vector

Inspect the icon, or open the file in a text editor. If what you find inside the svg tag is a single image element carrying a very long run of base64 characters, you have a PNG in an SVG wrapper. It has the file extension and none of the properties.

A great many converters do this, because embedding is instant and tracing is not. It looks like a conversion in the download folder and fails at everything you wanted the format for: it still blurs when enlarged, the file is larger than the PNG was, and there is no shape for a fill to apply to, so no colour rule will ever do anything.

Fix: trace it properly

There is nothing to repair in a file like this — the outlines were never worked out, so there is nothing to recolour. Go back to the original PNG and trace it into real path data. Open the result in a text editor afterwards: you should see coordinates, not base64.

Cause 3: every shape names its own colour

This is the one worth understanding properly, because it explains why so many otherwise correct-looking files fail.

Your theme colours icons by setting a colour on the wrapper and letting it flow down into the SVG. Inheritance is the weakest thing in CSS: it only reaches an element that has no answer of its own. A path carrying fill="#1a1a1a" has an answer of its own, so the inherited value never applies to it. The theme is doing its job correctly, the value arrives at the SVG, and it stops there.

The confusing part is that this is not about specificity in the usual sense. A CSS rule that targets the paths directly — something ending in svg path with a fill — does override the attribute, because any stylesheet rule outranks an attribute written on the element. But themes do not write rules like that, because they cannot know what is inside your file. They set a colour on the wrapper and rely on inheritance, and inheritance is precisely what a fill attribute blocks.

Fix: delete the fills

In a text editor, remove every fill="..." attribute from inside the file, and put fill="currentColor" on the outer svg tag instead. currentColor means take whatever colour this element has been given, so the file now inherits rather than deciding. That is the whole change, and it is usually a two-minute edit on a simple icon.

Cause 4: there is a style block inside the file

Illustrator and Figma both offer export settings that move colours into a stylesheet inside the SVG, which is how files end up containing rules like .cls-1 { fill: #000 } or .st0 { fill: #231F20 } with matching classes on every path.

This is the most stubborn version of the problem. A rule inside the file targets the paths by class, and a class selector carries more weight than the element selector a theme would use. So even a theme that does write a proper rule loses to the one shipped inside your icon. It is also the version people most often try to beat with !important, which sometimes works and leaves you with a stylesheet full of exceptions.

Fix: delete the block and the classes

Remove the entire style element, remove the class attributes it was targeting, and set fill="currentColor" on the outer svg tag. Or re-export from Illustrator with Styling set to Presentation Attributes rather than Internal CSS, which produces the fill attributes of cause 3 — still to be removed, but far easier to see and safer to strip.

Cause 5: an inline style attribute

A path carrying style="fill:#000000" beats every rule in every stylesheet on the site, short of !important. These usually arrive from a design tool export or from a WYSIWYG editor that touched the markup on the way through.

The fix is the same as before: delete the style attributes, set currentColor on the root. It is worth checking for these specifically even after you have cleared the fill attributes, because they are easy to miss and produce the identical symptom.

Making an existing SVG recolourable, start to finish

1. 1Open the .svg file in any plain text editor. It is XML — you can read it.
2. 2Delete the entire style element if there is one, along with the class attributes it targets.
3. 3Delete every fill="..." attribute and every style="fill:..." attribute inside the file.
4. 4Check for stroke as well. An outline icon drawn with strokes rather than fills needs stroke="currentColor" for the same reason.
5. 5On the outer svg tag, set fill="currentColor". Remove any width and height attributes but keep the viewBox, so it scales to whatever box you put it in.
6. 6Save, and place the markup in the page rather than linking to it.

If the file turns out to be an embedded raster, or the markup is dense enough that editing it by hand is unappealing, tracing the original PNG again is faster than repairing it — and produces a file with none of these problems in it, because it is written from scratch with no colour named anywhere.

Common questions

Why does it look right in my browser but not on my site?

Opening an SVG on its own shows it exactly as the file describes itself, with nothing around it to inherit from. That is a test of what the file looks like alone, not of whether it can be recoloured. A file that renders black on its own and recolours on a page is behaving correctly; a file that renders in its own colour on its own is the one that will not budge later.

Does adding !important fix it?

For causes 3, 4 and 5, usually yes, and it is still worth fixing the file instead. !important works because it climbs above the declaration inside your icon, which means you now need it in every place the icon appears — hover, dark mode, each section colour — and you have written a rule your future self will have to reverse-engineer. It does nothing at all for causes 1 and 2, where there is no shape to colour.

Can I recolour only part of an icon?

Yes, if the file is built for it. Give each part its own group with an id or class, leave the parts that should follow the theme set to currentColor, and let the parts that should stay fixed keep their fill. That is a deliberate design and worth doing for a two-tone brand mark. It is not something a tracer can decide for you.

What about SVG sprites and the use element?

Sprites referenced with use do inherit colour, which is why currentColor is standard practice in icon systems built that way. The catch is the same one as everywhere else: the symbols inside the sprite must not name their own fills, or the inherited colour has nothing to apply to.

Is this specific to WordPress?

Not at all. The mechanism is CSS, so it is identical in Webflow, Shopify, Framer, Squarespace, a React application and a hand-written HTML page. WordPress comes up most because its default block on SVG uploads pushes people towards img tags and plugins, which is cause 1 by a different route.

Is there a way to just get a file that always works?

That is what Icon to SVG produces: real traced paths, no colour named anywhere, no style block, no class attributes, transparent background. It comes out black on its own and takes your site's colour once it is on the page. There is more on why it refuses to let you pick a colour in the guide to getting an SVG icon for WordPress.