{"id":376352,"date":"2023-01-17T05:51:20","date_gmt":"2023-01-17T13:51:20","guid":{"rendered":"https:\/\/css-tricks.com\/?p=376352"},"modified":"2023-01-17T05:51:30","modified_gmt":"2023-01-17T13:51:30","slug":"6-common-svg-fails-and-how-to-fix-them","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/6-common-svg-fails-and-how-to-fix-them\/","title":{"rendered":"6 Common SVG Fails (and How to Fix Them)"},"content":{"rendered":"\n
Someone recently asked me how I approach debugging inline SVGs. Because it is part of the DOM, we can inspect any inline SVG in any browser DevTools. And because of that, we have the ability to scope things out and uncover any potential issues or opportunities to optimize the SVG.<\/p>\n\n\n\n
But sometimes, we can’t even see our SVGs at all. In those cases, there are six specific things that I look for when I’m debugging.<\/p>\n\n\n\n\n\n\n
viewBox<\/code> values<\/h3>\n\n\nThe viewBox<\/code> is a common point of confusion when working with SVG. It\u2019s technically fine to use inline SVG without it, but we would lose one of its most significant benefits: scaling with the container. At the same time, it can work against us when improperly configured, resulting in unwanted clipping.<\/p>\n\n\n\nThe elements are there when they\u2019re clipped \u2014 they\u2019re just in a part of the coordinate system that we don\u2019t see. If we were to open the file in some graphics editing program, it might look like this:<\/p>\n\n\n\n