Stuff at the Top of an SVG

If you’ve ever opened up an SVG file to look at the code, you’ve probably thought to yourself: “What’s all that stuff at the top? DOCTYPE, version, xmlns, xmlns:xlink… what’s their purpose, and can I get rid of them?” Unlike the majority of SVG code—which is readable and understandable to an English-speaker—these bits at the top can seem completely foreign.

I’ve asked those same questions myself, so, in preparation for my new course on SVG workflows in Sketch, I’ve done a ton of research and made this cheat sheet for designers and developers.

⚠️ Note: This article only applies to SVG graphics used on modern websites—which is by far their most common use case. Some of the guidelines in this article might not hold up with less-common use cases, like re-importing an SVG back into a design tool, converting it into a different type of file, or using it on an older website that isn’t HTML5.

🌿 This is a living document. If you are extremely knowledgeable about this topic, or have encountered situations where the points from this article don’t hold up, please let me know. Together, let’s keep this accurate and up-to-date!

I do declare!

The majority of these “things” at the top of an SVG are called declarations.

When you give a web browser (or any other software) your SVG file or SVG code to display, the browser needs to know which language you’re speaking. That’s what most of these declarations are for.

But when you’re using your SVG on a modern webpage, as most of us are, some of these aren’t necessary; others are effectively obsolete; and some are only useful some of the time. That’s why I’ve created this list of guidelines, based on the two most common scenarios for using SVG.

✴️ Practical Guidelines

All of the ways to present an SVG on a website effectively fall into two categories: 1. the SVG is linked as an independent file, or 2. the SVG’s code is incorporated into the webpage itself. The latter is typically achieved by nothing more than pasting the SVG code into an HTML5 page, right alongside other elements on the website—a method known as “inline SVG.” Based on these two categories, here’s what you need and what you don’t:

1. Using an SVG as an independent graphic

• Remove the DOCTYPE declaration ( <!DOCTYPE svg … )
  (Sketch and Illustrator don’t include this in SVGs anymore)
• Keep the XML declaration ( <?xml … ) just in case. In my tests it wasn’t necessary, but the consensus from my research is that it is advisable.
• Remove the version attribute (it’s never needed)
• Keep the xmlns namespace declaration
• Keep the xmlns:xlink XLink declaration if some part of your SVG uses “xlink” (most likely a <use>, <a>, or <image> element’s xlink:href attribute). If you aren’t sure, keep it.

2. Using an SVG “inline” with HTML code on a webpage

• Remove the DOCTYPE declaration ( <!DOCTYPE svg … )
  (Sketch and Illustrator don’t include this in SVGs anymore)
• Remove the XML declaration ( <?xml … )
• Remove the version attribute (it’s never needed)
• The xmlns namespace declaration isn’t necessary on most modern webpages, but it doesn’t hurt to keep it just in case.
• Keep the xmlns:xlink XLink declaration if some part of your SVG uses “xlink” (most likely a <use>, <a>, or <image> element’s xlink:href attribute). Like the xmlns declaration, xmlns:xlink isn’t necessary on most modern webpages, but it doesn’t hurt to keep it.

Other things at the top of your SVG:

You may also notice attributes like viewBox, width, height, and preserveAspectRatio at the top of your SVG. Unlike the declarations and attributes mentioned above, these do affect the visual result of your graphic. They are worth keeping unless you know exactly what you’re doing.

You’ll also notice that many design tools include a comment about the software used to export the SVG. For example:

<!-- Generator: Sketch 44.1 (41455) - http://www.bohemiancoding.com/sketch -->
  OR,
<!-- Generator: Adobe Illustrator 19.2.1, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->

These comments are harmless, and are always safe to delete.

A Note on Optimization

The popular optimization engine SVGO—which powers Sketch’s SVGO Compressor plugin and the web app SVGOMG—has options to remove the unwanted declarations and attributes for you. It’s even smart enough to check for the presence of elements using xlink, to keep that declaration on the <svg> element when necessary. That’s super convenient and generally reliable. But ultimately you’re the only one who knows how your SVG will be used, so I hope the guidelines in this article will help you decide when to use those optimizations and when to turn them off.

What do these acronyms mean?

Don’t let these terms intimidate you; they’re all based on simple ideas.

XML stands for “Extensible Markup Language,” which is simply a versatile way to structure information—like an outline with some extra punctuation.

XMLNS stands for “XML namespace.” A namespace is a set of element and attribute names. For example, SVG’s <title> and <rect> elements are part of its namespace. A different format based on XML might have its own <title> or <rect> elements; it’s important to declare which namespace your graphic is using, so browsers know how to interpret the code.

XLink stands for “XML Linking Language.” It’s just a set of common ways to link between things within a file (ex: connecting a gradient to the shape that uses it) or to things outside of the file (ex: creating a clickable link to another webpage).

Sources and Further Learning

The information in this article draws from extensive research through online resources, conversations with engineers who work on browsers and design tools, and my own empirical tests across browsers.

If you’d like to learn more about Namespaces and why their declarations are important, read this fantastic short article on the Mozilla Developer Network.

Some of the most helpful online sources I found were Stack Overflow conversations, like this one about XML declarations, this one about XMLNS and version, and this one which touches on XLink too. The SVGO plugin to remove DOCTYPE cites this article. This MDN piece reiterates that DOCTYPE should be excluded.

My Own Tests

My tests reinforced the other research. I tested SVGs with combinations of these declarations included and excluded—then implemented them on an HTML5 webpage as inline SVG, HTML <img> tags, CSS background-image, and background-image on CSS :after content. I tested across recent versions of Safari, iOS Safari, Firefox, Chrome, Edge (15), and Internet Explorer (9, 10, and 11).

I was surprised to find consistent results across browsers with inline SVG. When it comes to this “stuff at the top,” inline SVG appears to be hands down the most reliable and forgiving way of implementing SVG on the web.

The most notable issue I encountered overall was that independent graphics (non-inline) didn’t render without proper namespaces. Even the omission of an xmlns:xlink attribute, when it was necessary, caused this issue in all browsers. So keep those namespace declarations!

This article is part of my new course, SVG Workflows in Sketch. I wish I had resources like this when I was learning SVG, so I’m determined to provide some of those missing pieces for other designers. The course aims to bridge the gap between what you know in Sketch, and the amazing things you’ll create in SVG.

You can also sign up for my newsletter to be the first to know when I publish new design articles and resources.