logoredraws.com

SVG image href and xlink:href

How the SVG image element's href and xlink:href attributes differ, which one to use, and why it matters for SVG favicons and vector logo files.

Published

Contents
  1. The short answer
  2. What the image element actually does
  3. How href and xlink:href differ
  4. Writing the attribute
  5. Why this matters for SVG favicons
  6. An embedded image is not vector artwork
  7. Checking an SVG logo file
  8. Setting the attribute from script
  9. What this overview does not cover

The short answer

In SVG, the image element uses an attribute to point at the file it should display. SVG 1.1 defined that attribute as xlink:href, which borrows from the separate XLink namespace. SVG 2 replaced it with a plain href attribute and deprecated xlink:href. Current browsers accept plain href, so it is the attribute to write in new work. Some older browsers, editors and processing tools only recognise xlink:href, so files meant for wide compatibility sometimes carry both.

What the image element actually does

The SVG image element places an external picture inside the drawing. That picture is usually a raster file such as PNG or JPEG, though it can also be another SVG document. The href or xlink:href value tells the renderer where that picture comes from. It can be a relative file path, a full web address, or a data URI that holds the encoded file inside the SVG itself.

Aspect | href | xlink:href
Defined in | SVG 2 | SVG 1.1 (deprecated in SVG 2)
Namespace declaration needed | No | Yes, the xlink namespace must be declared on an ancestor element, usually the root svg element
Support in current browsers | Supported | Still supported for backward compatibility
Support in older browsers and tools | May be ignored | Generally recognised
If both are present | Used | Ignored by SVG 2 renderers

The same change applies to the other SVG elements that reference something by address, such as use, pattern, gradients and textPath. An SVG logo that reuses a symbol through use is subject to the same compatibility consideration as one that embeds an image.

Writing the attribute

The modern form needs nothing beyond the attribute itself:

<svg viewBox="0 0 64 64">
  <image href="mark.png" x="0" y="0" width="64" height="64" />
</svg>

For older consumers, both attributes can be written on the same element. In a standalone SVG file, xlink:href only works if the xlink namespace is declared on the root svg element; that declaration is omitted from the snippet below. Because SVG 2 renderers give href priority when both are present, the two values should always be identical.

<image href="mark.png" xlink:href="mark.png"
       x="0" y="0" width="64" height="64" />

Setting width and height explicitly is also a compatibility measure. SVG 1.1 treats missing dimensions on image as zero, which hides the image, while SVG 2 lets the image size itself from its own dimensions.

Why this matters for SVG favicons

When a browser loads an SVG as an image rather than as an inline or standalone document, it does not fetch external resources referenced from inside that SVG. Favicons, img tags and CSS background images all load SVG this way. An image element whose href points to a separate PNG will therefore render as blank in a favicon, regardless of whether href or xlink:href is used. The attribute choice decides whether the reference is recognised. The loading context decides whether the referenced file is fetched at all.

  • Prefer drawing the favicon with SVG shapes and paths instead of embedding a picture.
  • If a raster element is unavoidable, embed it as a data URI so the SVG is self-contained.
  • Test the file in the context where it will be used, as a favicon or img source, not only by opening it directly. Direct opening can load external files that the favicon context will block.
  • Keep a separate raster favicon for browsers and platforms that do not use SVG icons.

An embedded image is not vector artwork

Finding an image element in an SVG logo means at least part of the artwork is a picture wrapped in an SVG container, not editable vector paths. That part will blur or pixelate when scaled beyond its native resolution. It cannot be recoloured or reshaped point by point in a vector editor. Some exported files, and some logo downloads, are an entire raster image embedded this way. The .svg extension alone does not establish that a logo is true vector artwork.

Checking an SVG logo file

  • Open the file in a text editor and search for image elements and for href or xlink:href attributes.
  • If an href value begins with a data URI declaring a raster type such as PNG or JPEG, that content is an embedded bitmap.
  • If an href points to a separate file, the SVG depends on that file being present and loadable, which will not hold for favicon or img use.
  • If the artwork is built from path, circle, rect, polygon and similar elements with no image elements, it is drawn as vector shapes.
  • If xlink:href appears, confirm the xlink namespace is declared; a missing declaration makes a standalone file invalid as XML.

Setting the attribute from script

Code that builds or updates SVG on the fly follows the same split. Plain href is set like any ordinary attribute. The legacy attribute has to be set with its namespace, using the namespace-aware attribute method.

// SVG 2
img.setAttribute('href', 'mark.png');

// Legacy: setAttributeNS with the xlink namespace and the name 'xlink:href'

What this overview does not cover

No source material was supplied for this article. The explanation above therefore rests on the general behaviour of the SVG 1.1 and SVG 2 specifications and of current browsers. It does not list specific browser versions that first accepted plain href, and it does not describe how particular design applications export either attribute. Anyone supporting a defined set of older browsers or a specific export pipeline should check those targets directly before dropping xlink:href.