---
title: SVG ガイドライン
slug: Mozilla/Developer_Guide/SVG_Guidelines
translation_of: Mozilla/Developer_guide/SVG_Guidelines
---
The SVG format has the advantage of being able to describe complex images while being lightweight and to scaling them very well at all resolutions. Unfortunately, a lot of SVG files (often generated by SVG editors) ship without being cleaned up, so the benefit of them being lightweight is gone. Here are some best pratices to keep SVGs lightweight. These rules are based on some real examples seen in Mozilla's code.
Basics
- 2 spaces indenting
- No useless whitespaces or linebreaks (see below for more details)
- Adding a license header
- Use double quotes
Whitespace and line breaks
Whitespace
In addition to trailing whitespace at the end of lines, there are a few more cases more specific to SVGs:
- Trailing whitespaces in attribute values (usually seen in path definitions)
- Excessive whitespace in path or polygon points definition
Examples
This path:
<path d=" M5,5 L1,1z ">
can be cut down to this:
<path d="M5,5 L1,1z">
Similarly, this polygon:
<polygon points=" 0,0 4,4 4,0 "/>
can be cut down to this:
<polygon points="0,0 4,4 4,0"/>
Line breaks
You should only use line breaks for logical separation or if they help make the file readable. You should avoid line breaks between every single element or within attribute values. It's recommended to put the attributes on the same line as their tagnames if possible. You should also put the shortest attributes first so they are easier to spot.
Vector editors (Inkscape, Adobe Illustrator, Sketch, …) usually add a bunch of metadata in SVG files when saving them. Metadata can mean many things, including:
- The common "Created with editor" comments
- Non-standard editor specific tags and attributes (
sketch:foo, illustrator:foo, sopodi:foo, …)
- The XML namespace definition that comes with the latter (
xmlns:sketch, xmlns:sopodi, …)
In addition to non-standard editor metadata, standard compliant metadata also exists. Common examples of this are <title> and <desc> tags. Although this kind of data is supported by the browser, it can only be displayed when the SVG is opened in a new tab. Plus, the filename is descriptive enough most of the time. So it's recommended to remove that kind of metadata, since it doesn't bring much value.
You shouldn't include DOCTYPEs in your SVGs either, they are source of many issues and the SVG WG recommends not to include them. See SVG Authoring guidelines.
Avoid the use of CDATA sections
CDATA sections are used to avoid parsing some text as HTML. Most of time, CDATA isn't needed, for example, the content in <style> tags doesn't need to be wrapped in a CDATA section as the content inside the tag is already properly parsed as CSS.
Invisible shapes
There are 2 kinds of invisible shapes: the offscreen ones and the uncolored ones.
The offscreen shapes are hard to spot, even with an automated tool, and are usually context aware. Those kind of shapes are visible, but off the SVG view box. Here's an example of a file with offscreen shapes.
On the other hand, the uncolored ones are easier to spot, since they usually come with styles making them invisible. They must meet 2 conditions: they must have no fill (or a transparent one) and no stroke.
Unused attributes on root <svg> element
The root <svg> element can also host many useless attributes. Here's an example taking into account the list below:
versionx="0" and y="0"enable-background (unsupported by Gecko and now deprecated by the Filter Effects specification)id (id on root element has no effect)xmlns:xlink attribute when there are no xlink:href attributes used throughout the file- Other unused XML Namespace definitions
xml:space when there is no text used in the file
Other
- Empty tags, this may be obvious, but those are sometimes found in SVGs
- Unreferenced ids (usually on gradient stops, but also on shapes or paths)
clip-rule attribute when the element is not a descendant of a <clipPath>fill-rule attribute when the element is a descendant of a <clipPath>- Unreferenced/Unused clip paths, masks or defs (example)
Styling
Basics
- Privilege short lowercase hex for colors
- Don't use excessive precision for numeric values (usually comes from illustrator)
- Use descriptive IDs
- Avoid inline styles and use class names or SVG attributes
Examples
Here are some examples for excessive number precision:
- 5.000000e-02 → 0.05 (as seen here)
- -3.728928e-10 → 0 (as seen here)
- translate(0.000000, -1.000000) → translate(0, -1) (as seen here)
As for descriptive IDs:
- For gradients: SVG_ID1 → gradient1 (as seen here)
Use of class names
- Avoid using a class if that class is only used once in the file
- If that class only sets a fill or a stroke, it's better to set the fill/stroke directly on the actual shape, instead of introducing a class just for that shape, you can also use SVG grouping to avoid duplicating those attributes
- Avoid introducing variants of the same file (color/style variants), and use sprites instead (with class names)
Default style values
There's usually no need to set the default style value unless you're overriding a style. Here are some commonly seen examples:
style="display: none;" on <defs> elements (a <defs> element is hidden by default)type="text/css" on <style> elementsstroke: none or stroke-width: 0
SVG grouping
Style grouping
Group similarly styled shapes under one <g> tag, this avoids having to set the same class/styles on many shapes.
Avoid excessive grouping
Editors can sometimes do excessive grouping when exporting SVGs. This is due to the way editors work.
Nested groups
Avoid multiple-level nesting of groups, these make the SVG less readable.
Some editors use <g> tags to do nested transforms, which is usually not needed. You can avoid this by doing basic algebra, for example:
<g transform="translate(-62, -310)"><shape transform="translate(60, 308)"/></g>
can be cut down to:
<shape transform="translate(-2,-2)"/>
because: -62+60 = -310+308 = -2
These rules are optional, but they help speeding up the SVG.
- Avoid using a
<use> tag when that <use> tag is being referenced only once in the whole file
- Instead of using CSS/SVG transforms, apply directly the transform on the path/shape definition
Tools can help clean SVG files. Note however that some of the rules stated above can be hard to detect with automated tools since they require too much context-awereness.
To this date, there doesn't seem to be a tool that handles all of the above. However, there are some existing utilities that cover some parts of this document:
