New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 294179 link

Starred by 159 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

issue 578122

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Support SVG favicons

Reported by, Sep 18 2013

Issue description

UserAgent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.65 Safari/537.36

Steps to reproduce the problem:
This is meant to be a tracking bug.

IE: ?

"The any keyword represents that the resource contains a scalable icon, e.g. as provided by an SVG image."

<link rel="icon" href="favicon.svg" sizes="any" type="image/svg+xml">

What is the expected behavior?
It's supported.

What went wrong?
It's not supported.

Did this work before? No 

Chrome version: 29.0.1547.65  Channel: stable
OS Version: Ubuntu 13.04
Flash Version:

Comment 1 by, Sep 20 2013

Labels: Cr-Blink-SVG

Comment 2 by, Sep 20 2013

Status: Available
"This is meant to be a tracking bug." Are you working on this feature or just reporting it as a feature request?

Comment 3 by, Sep 20 2013

The latter.

Comment 4 by, Sep 20 2013

I agree that this would be useful, but it's difficult from the implementation side. Our SVG code is heavily integrated into the core rendering engine so doing this would require spinning up a full renderer. I'm not sure about the performance implications of that.

Alternatively, we could call out to a minimal SVG engine (like the one in Skia) to render these.

Comment 5 by, May 27 2014

Need to make sure @media works properly in SVG favicons so that it's possible to use the same file for the favicon and the site logo and have each be optimized for the given size (e.g. you might want thicker strokes, less detail, etc in the favicon).

Need to consider "Retina" displays so that the icon isn't rasterized as 16x16 and then upscaled and blurred.

Scripts and subresources should probably be disabled for security.

Declarative animation should probably work if animation with GIF favicon works.

Some WHATWG specs use SVG favicons, e.g.

Comment 6 by, May 27 2014

Sidenote: IE11 (maybe IE9+) can display SVG named `favicon.ico` at the root of domain as favicon.
Since SVG rendering at 16x16px can be really finicky, at the smallest resolutions pixel art might actually be preferable. But something really ought to be done to contain the bloat of multiple favicon resolutions. 15 lines of code now just for interoperability?! :

@pdr Couldn't the SVG rendering engine be called after page load, so that that performance isn't significantly affected? Is the Skia feature set significantly smaller?

Comment 8 by, Jun 19 2014

Let me please give a use case justification.  I'm running Chromium on Linux/Gentoo/XFCE.  Several webpages I run in the app mode.  There the favicon of the webpage runs becomes the icon for the program.  When shown on the panel(ie taskbar)  the icon is larger than 16x16 and thus very pixelated and blurry.  A SVG icon could be scaled by the Operating system to look good as an app icon.

Comment 9 by, Jun 23 2014

Regarding rendering svg at varying sizes, it's possible to overcome most of issues around that by using css media-queries. See e.g It would be quite neat to be able to use the same svg as app icon, favicon, banner icon and so on.
A SVG icon can be drawn so have a good rendering in 16x16: (self explanatory!)

Comment 11 by Deleted ...@, Aug 17 2014

IE bug report is here:

(since you linked to Bugzilla, and have a question mark on IE)

Comment 13 by, Aug 19 2014

Allowing media queries that are aware of the actual image size have been seen as security issue on SVG images by WebAppSec IIRC.

I think the issues was click-napping by changing the appearance of the SVG depending on the result of the media queries. Dependent on the viewport width/height/ratio, an SVG could emulate a system dialog or button and trick users into clicking it. 

Comment 15 by, Jul 28 2015

Labels: -OS-Linux OS-All
Firefox now supports this.

While the original IE bug report (mentioned in #11) got WontFix'ed, there's a new request here:

Comment 16 by, Aug 26 2015

I recently had a look at a bunch of the top sites globally (based on It seemed fairly common to have an svg favicon <link>'ed from the frontpage.

Comment 18 by, Aug 26 2015

In 2015-01-07 dataset of 87,000 pages I see only 1 page using .svg favicon with <link rel="icon"> or <link rel="shortcut icon">:

./ec/<link rel="shortcut icon" href="">

(It's possible there are more that use SVG without ".svg" in the filename or serve SVG for /favicon.ico without <link>, but I suppose it's still in the same ballpark.)

Comment 19 by, Aug 26 2015

Right, I saw quite a number of mask-icon references, but not only that. See e.g
<link rel="icon" sizes="any" mask href="">

Comment 20 by, Aug 26 2015

That has a 'mask' attribute (I think it was their original syntax, but they changed it because it caused other browsers to use it as the favicon which was not intended).

Twitter also has
<link href="//" rel="shortcut icon" type="image/x-icon">
which is what we use as the favicon.
Yep, Twitter (like lot of other sites) uses old, problematic syntax:

Despite of it I like an idea of SVG favicons and I don't see why it can't be implemented in Chromium - when 2/3 biggest browsers (currently only Firefox 41 (in beta) have full support for it and current stable still have blocking bug) provide support, then site owners provide icons. :)
Mozilla advocacy took care of the few cases where major sites hadn't followed Apple's recommendation to put their propitiatory mask line before actual favicons.

Comment 23 by, Sep 23 2015

According to this message[1] from Apple developer forums about the `mask`attribute:

> The markup changed in Developer Seed 3 and Public Beta 1 to simplify and have better backwards compatibility. Use the following markup instead:
> <link rel="mask-icon" href="website_icon.svg" color="red">  


Comment 24 by, Sep 23 2015

I forgot to add that the WHATWG has open an issue for this:
Labels: -Type-Bug Type-Feature

Comment 26 by, Feb 8 2016

In I switched the HTML spec to using <link rel=icon href=> without realizing it wasn't supported in many browsers yet. FWIW, it looks great in Firefox.

It sounds tricky indeed to support this if rel=icon handling is mostly in the browser process. SVG folks, what do you think the chances of making this work are?

Comment 27 by, Feb 8 2016


Comment 28 by, Feb 8 2016

If we consider some constraints - such as producing raster versions at various sizes and ignoring animations - it seems "chances" are pretty decent. Looking at the current favicon "service" it seems the major missing piece protocol-wise is (a list of) dimensions to use for sizing. Beyond that we might be well served with passing the 'type' along where possible. We'll also need to teach WebImage to "decode" (rasterize) SVGs.

So "chances" are good I'd say. Now for the hard part - resources to make it happen =)

Comment 29 by, Feb 8 2016

Re comment #13, does that apply to favicons? It seems to me it shouldn't.

I think it would be good to properly support media queries (see comment #5).

Comment 30 by, Feb 9 2016

OK, from #28 I'll hold out hope that this will start working some day :)

Comment 31 by, Feb 9 2016

Summary: Support SVG favicons (was: support svg favicon)
+cc chrishtr,

What team would this fall on? SVG icons are useful for several of our efforts such as our mobile focus, cross compat, offline pages, and pageload time (favicons are heavy on mobile) so I think this is important to have prioritized on someone's plate even if it's just a P3.
Labels: -Pri-2 Pri-3
Supporting SVG favicons sounds to me like it would be quite a bit of work, because
it has to work in various scenarios in which the Blink renderer is not naturally
present. Downgrading to P3.

The paint team (which owns SVG) would probably drive this if it happened.

Comment 33 by, Feb 17 2016

Similar issue: SVG icons in web manifest files can’t be used for “add to homescreen” at the moment.

Comment 34 Deleted

Comment 35 by, Nov 10 2016

Related: SVG icons for extensions in

Comment 37 by, Mar 28 2017


Comment 38 by, Mar 28 2017

Given the increasing prevalence of HiDPI displays, I think this would be a valuable feature. 

Comment 40 by, May 17 2017

Firefox is changing there toolbar icons from PNG to SVG.
1347543 - Change Toolbar Icons from PNG to SVG <>

The predictability program is reviewing the top 1% of starred developer-facing bugs this quarter, and this is #23 on that list.  We’re hoping that for each we can either close it, set an owner and target milestone, or set a NextAction date so that we know when to check back in.

Chris, is this still very low priority / no NextAction?

Is it still only Firefox who has implemented this?  If multiple browsers had support then there might be an additional interoperability reason to do this.

Comment 42 by, May 31 2017

As for other browsers status, laukstein has a good collection of links to each browsers status here:

It does appear Firefox is the only browser awesome enough to implement this commonsense greatness.
Yes it's still not a high priority. Maybe in a couple of quarters.
FWIW, Opera supports this now: I wonder if their implementation is upstreamable.

Comment 45 by, Jun 23 2017

@fs, are you able to share the code for svg favicon support (or the blink-side plumbing)? Is it something you could upstream?

Comment 46 by, Jun 23 2017

I can look into the matter, but based on my recollection I don't think it's in an "upstreamable state".

Comment 47 by, Jun 28 2017

NextAction: 2018-01-01
Adding a NextCheckin date a couple quarters out as Chris mentioned in #43
The NextAction date has arrived: 2018-01-01
We are a couple of months past the NextAction date on this, is there any news / info on whether this is coming? 
Labels: -Pri-3 Pri-2
NextAction: ----
Still not a very high priority given our current workload. Sorry.

Updating the priority to reflect the fact that we would like to do this if given the chance.
Any update on the issue?
@hirendra..., the only update I noticed Chrome 67 stopped to fallback favicon.ico when defined unsupported <link rel=icon href=icon.svg>, I managed to fix it by adding "type" attribute <link rel=icon href=icon.svg type=image/svg+xml>, otherwise doesn't identify any of icons.
Refering to Comment 44, Comment 45, Comment 46:

Why hesitate? What is the problem to get Opera's code relating this issue shared (or is the code closed source and under a close source licence)? When it was (June 2017) or to date (July 2018) still is not in an upstreamable state, why not do so *now*, over one year later, prepare it, so that it is shareable *now* to finally fix this issue, catch up with Firefox and Opera and make web authors happy, who willingly want to use svg favicons and await eagerly the widely supply by the browsers?
There are no licensing issues, but the solution Opera uses is, well... let's just says it's very "pragmatic". I haven't put it front and center to "fix" this, and thus it has ended up taking time - in part because "fixing" it "The Right Way(TM)" has seemed an arduous task.
With a bit of luck though the (current) code will make it upstream within the next month - if not I'll try to give it a bump on my own TODO list.

Any progress achieved meanwhile on this referring to your "[…] With a bit of luck though the (current) code will make it upstream within the next month - if not I'll try to give it a bump on my own TODO list."?
Sadly no, but i'll try to bump it on the TODO.
Blocking: 578122

Sign in to add a comment