Drop in every SVG that ends up on the same page. This finds the IDs that two or more files share — the reason an inlined icon suddenly shows another icon's gradient, clip path or mask — and rewrites each file's IDs with its own prefix, updating every url(#…), href="#…" and aria-labelledby that points to them. Nothing is uploaded.
Only id attributes and the references to them change. The rest of each file is left byte-for-byte as it was, so this is safe to run before or after an optimizer.
An SVG that is inlined into HTML stops being a separate document. Its ids join the page's single ID namespace, and every reference such as fill="url(#a)" or clip-path="url(#clip0)" is looked up across the whole page. When two inlined SVGs both define id="a", the browser resolves both references to one of the two definitions. The second icon then gets the first icon's gradient, clip or mask, or nothing at all if the definition it got is inside a hidden element. Each file looks perfect when opened on its own, which is why this is so confusing to debug. SVGs used through <img>, CSS background-image or <object> are separate documents and can't collide. Why inline SVG icons show the wrong gradient explains where the duplicate IDs come from and every way to fix them.
id="…" attributes on every element.url(#…) anywhere in the file: presentation attributes (fill, stroke, clip-path, mask, filter, marker-*), inline style attributes and <style> blocks.href="#…" and xlink:href="#…", which is how <use>, gradients that inherit from other gradients, and <textPath> point at each other.aria-labelledby and aria-describedby, so an accessible <title id="…"> keeps working.#id selectors inside <style> blocks. Only selectors are rewritten, so a color like #abc in a declaration is never mistaken for an ID.A reference to an ID the file doesn't define is left alone and listed as a warning. That's normal for a <use href="#icon-x"> pointing into a sprite defined elsewhere on the page. In a standalone icon it usually means an optimizer removed a definition that was still needed.
All, in most cases. "Only colliding" fixes the files you have today, but the next icon someone adds can collide with an ID you left untouched. Prefixing every ID per file is what build tools do (SVGO's prefixIds plugin, for example). Choose "only colliding" when other code refers to specific IDs from outside the SVG, such as CSS or JavaScript on the page, and you want to change as few as possible.
By default, the file name: icon-home.svg turns id="a" into id="icon-home-a". That makes it obvious in DevTools which file an ID belongs to. Prefixes are made safe for use as IDs and CSS selectors (letters, digits, -, _, never starting with a digit), and two files whose names produce the same prefix get -2, -3 added. A custom text option gives svg1-a, svg2-a, and so on, in file order.
Technically yes, because the same IDs appear twice. It's usually harmless, since both copies resolve to identical definitions. The exception is when the first copy sits inside something hidden with display: none (a closed menu, an inactive tab). Gradients and masks defined there may not render, so the visible copy loses its gradient too. Prefixing can't help with two copies of the same file. Keep one visible copy of the definitions, or use the icon through <img>.
IDs referenced from outside the SVG (your page's CSS or JavaScript), SMIL animation timing such as begin="fade.end", and IDs inside embedded scripts. Those references keep the old names, so search your code for any ID the results list as renamed. Files that aren't well-formed XML are reported and left unchanged.
No. Files are read with your browser's FileReader, parsed with the built-in XML parser to find IDs, and rewritten with string operations on your device.