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

Issue 29683 link

Starred by 93 users

Issue metadata

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

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Extension icons should support SVG

Reported by, Dec 8 2009

Issue description

Chrome Version       : From about:config:
Chromium (Developer Build Ubuntu build 33819)
WebKit	532.6
V8	2.0.3
User Agent	Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.6 
(KHTML, like Gecko) Chrome/ Safari/532.6

What steps will reproduce the problem?
1. Add an SVG file as an icon to a Chrome extension
2. Load the extension (unpacked)
3. Navigate to chrome://extensions/

What is the expected result?

The icon should appear.

What happens instead?

The icon is broken, with a "broken picture" icon. Additionally, "open image 
in new tab" yields a URL to: data:image/png;base64, followed by a long 
string. I know what a Data URL is, and it might even make sense here, but 
why does it think my SVG file is a PNG?

Please provide any additional information below. Attach a screenshot if

According to

"One or more icons that represent the extension. We recommend that you 
provide icons in four sizes — 16x16, 32x32, 48x48, and 128x128 pixels. The 
icons can be in any format supported by WebKit, such as BMP, GIF, ICO, 
JPEG, or PNG."

Now, I know WebKit supports SVG. Maybe it just doesn't support SVG for 

Since I already have the icon as SVG, it seems a waste to convert it to PNG 
before publishing. It's especially sad when you consider the recommendation 
to provide icons in multiple sizes -- I have an icon that is infinitely 

A suggestion: Allow an SVG to be used instead of a bitmap altogether. I can 
think of two obvious ways of doing this:

  "icon": "foo.svg"

  "icons": {
    "16": "icon16.png",
    "32": "icon32.png",
    "64": "icon64.png",
    "128": "icon128.png",
    "scalable": "icon.svg"

The first form is the simplest -- if an "icon" property exists, use it, and 
ignore any "icons" properties. In the second form, the specific bitmaps are 
considered cached copies of the scalable icon, and the scalable icon is 
used to generate (and cache) new images when needed -- thus, no bitmaps 
actually need to be provided:

  "icons": {
    "scalable": "icon.svg"

All of this is just speculation on my part. I have absolutely no idea how 
the Chromium internals are built.

But it seems to me that if I can have my extension draw on a canvas, then 
take that canvas and use it as a PageAction or BrowserAction icon, I should 
be able to do something as simple as use an SVG as an icon for the plugin 
itself. And if I do that, it seems cumbersome to have to specify a 
resolution, especially when it's already assumed to be a square.
Labels: -OS-All OS-Linux
Labels: -OS-Linux -Area-Misc OS-All Feature-Extensions
what about this is linux specific?

Comment 3 by, Dec 9 2009

Nothing that I know of. I'm guessing it was made Linux-specific as I was on the Linux 
developer build. I was too lazy to confirm this on another OS.

But I'm going to guess it's the same on all OSes.

Also, is this the right place to submit a feature request? This is either a feature 
request or a documentation bug; that is, either this should work (and be better 
documented), or the documentation should explicitly list supported formats (or just 
say, "It has to be raster.")

Comment 4 by, Dec 9 2009

Labels: -Type-Bug -Pri-2 Type-Feature Area-BrowserUI
Status: Untriaged
Good idea.

Comment 5 by, Dec 12 2009

Labels: Mstone-X

Comment 6 by, Dec 18 2009

Labels: -Area-BrowserUI Area-UI-Features
Area-UI-Features label replaces Area-BrowserUI label
Labels: -Area-UI-Features Area-UI

Comment 8 by, Feb 19 2010

Labels: SVG
Status: Available

Comment 10 by, May 29 2010

I recommend using the HTML5 method of icon link elements' sizes attribute (ex. <link 
rel="icon" sizes="32x32">), where SVG is sizes="all", so an SVG icon would be under 
icons as "all" instead of "scalable".

Comment 11 by, May 29 2010

Good idea...

I realize I'm probably a bit late to comment on that change, but this is both a bug 
and a feature request (so it should still be Type-Bug). The feature being requested 
is the option to specify a scalable format (like SVG) without specifying its 

The bug is that the current behavior does not match the documentation. I just checked 
the documentation again, and the docs still claim that icons can be in ANY format 
supported by Webkit. I also see Webkit still works with SVG, anywhere other than 
The icon sizes has a good meaning even if the icons were scalable.

I could imagine doing *two* scalable icons, one for big resolutions and one for smaller.

Because of this if browser requests 16x16 icon, and closest scalable icon is 32x32 it should use that etc.

Comment 13 by, Sep 10 2010

Labels: Pri-2
Labels: -mstone-x
Are we planning on doing anything related for higher-res displays or as part of the NTP redesign?

Comment 16 by, Nov 3 2011

Labels: -SVG Webkit-SVG

Comment 17 by, Jun 28 2012

This might be a bit of an adventure.

We don't want to evaluate extension-provided svg in the browser process, and we don't want to startup a process each time we need to display an icon.

So I suppose that means we need to process the svg icon into whatever icon sizes we need at install time? We already so something similar for simpler images types using the utility process.

I am not sure how much more complex it is to render svg to a bitmap in a utility process.

Comment 18 by, Jun 29 2012

could also (if it helped) capture the SVG by drawing it once into a picture. Then you can tear down the webkit/svg context for good (if it helped) and just draw the picture (or a bitmap cache of it at various resolutions).

Comment 19 by, Jun 29 2012

Labels: CalPoly
#18: Yeah that's what I meant to describe in #17.
Project Member

Comment 20 by, Mar 10 2013

Labels: -Feature-Extensions -Area-UI -Webkit-SVG Cr-Platform-Extensions Cr-UI Cr-Content-SVG
I've researched into how we would load a svg.

Currently Skia does not support loading SVGs (its on their 'roadmap' though).

WebKit doesn't give us support for loading SVGs into bitmaps. We could try to load a fake page with the svg and somehow get the bitmap out of it, but currently the WebImage object they expose to us only takes certain formats, and only ones with less flexible file headers.

If WebKit gave us a way to get bitmap data out of SVGs, then it wouldn't be hard to load them into bitmaps on install.

Any thoughts?

Comment 22 by, Mar 23 2013

It's easy to coax webkit into rendering the SVG content as a bitmap. In the same way that you might use canvas to draw extension icons, you can use canvas.context.drawImage([svg image]).

aa@chromium: I can write a quick script that takes an SVG image and output rasterized bitmaps at various resolutions. If I whipped that up, is it feasible to wire it into the extension install process? Your right, we could call javascript from the utility process. If you can write a script that can get the pixel data out of a svg, then it would certainly be feasible to call it from the install process. 

You'd have to find a way around chrome's security policy on using getImageData from a canvas with a svg drawn on it from a file though, and without using --allow-file-access-from-files. I think finding a way around that on the C++ side of the utility wouldn't be that simple.

Comment 24 by, Mar 26 2013

patrickriordan177: Since this is being spun up from C++, can't the svg file be passed in directly, without any file loads? True I overlooked putting the data directly into the script with data:image/svg+xml. Although when trying it out with an test page I encounter another problem. The svg still seems to be tainted with cross origin data. This might be because they always contain xmlns="".

Project Member

Comment 26 by, Apr 6 2013

Labels: Cr-Blink
Project Member

Comment 27 by, Apr 6 2013

Labels: -Cr-Content-SVG Cr-Blink-SVG
I hope I am not breaking any rule (newbie), but I would like to know the status of this. It has a year since last comment and almost 5 years since report.

Comment 29 Deleted

Comment 30 by, Sep 30 2014

There has been no progress on this feature request.

Comment 31 Deleted

Comment 32 Deleted

Comment 33 Deleted

Comment 34 by, Sep 30 2014

FYI it is possible to use SVG when you set the icon programatically (from the background page), e.g. using

chrome.browserAction.setIcon({ path: 'icon.svg' });
chrome.pageAction.setIcon({ path: 'icon.svg' });

SVG doesn't work for anything declared in the manifest file though.
Since it is semi-functional, think we should keep track of it this way:

 - Market: yes/no
 - Browser [
    page actio yes/no
    browser action yes/no
    info bar yes/no
- chrome://extensions yes/no
- anywhere else?

Please include how you set it (manifest, programatically,..) and OS and Chrome version maybe?
If you are looking to change icons in a way that is compatible with both high-DPI and regular displays I found a workaround for my own extension. You can draw on a canvas of size 76x76 for high-DPI and 19x19 for regular. Then when you do setImageData you claim the 76x76 is actually 38. Keep 19 as 19.

Here's my code that handles this:
#36 and #34: Does this change the icon everywhere (extension page?) or just the buttons?
@#37 -- Just the buttons. The extension page is handled through the manifest. I haven't tested every scenario with that particular page.

Comment 40 by, Jun 24 2015

Labels: -Cr-Blink -Cr-Blink-SVG
The standard spec might probably be defined as "any" instead of "scalable"

    "icons": {
        "any": "icon.svg"

See Manifest spec proposal

Comment 42 by, Sep 22 2016

Any news on that features ?
I suspect the same solution could be used for favicons and extension icons.

This makes a great deal of sense!
8y later it still makes sense ;)

Comment 46 by, Mar 24 2018

Now 9 years.
Yes. That a so trivial need is ignored by one of the major web browsers
proves the seriousness of the Open Source situation.

2018-03-24 2:21 GMT+01:00 nyet… via monorail <>:

Comment 48 by, Mar 24 2018

Chromium is not truly open source. 

Mozilla, at least, you can submit a patch, and if they do not accept it, you can fork the project.

All modern linux distributions have minor forks of mozilla.

Comment 49 by, Mar 24 2018

Anyone can submit a patch to Chromium, and they do. 
It takes just a few seconds to find this:
Labels: Hotlist-PopularIssue

Sign in to add a comment