Photoshop user? Why not RealFaviconGenerator?

Photoshop is a great tool. Use it and you can expect your pictures to be just perfect. Well, almost perfect.

Let’s see what Apple got when they created their own Touch icon:

$ wget -o apple-icon.png
$ ls -l
-rw-rw-r-- 1 philippe philippe 4506 Aug 12  2015 apple-icon.png

4506 bytes for a Touch icon? Sounds legit. Now let’s have a look to its metadata:

$ exiftool apple-icon.png
ExifTool Version Number         : 9.46
File Name                       : apple-icon.png
Directory                       : .
File Size                       : 4.4 kB
File Modification Date/Time     : 2015:08:12 19:51:29+02:00
File Access Date/Time           : 2016:05:17 17:00:31+02:00
File Inode Change Date/Time     : 2016:05:17 17:00:31+02:00
File Permissions                : rw-rw-r--
File Type                       : PNG
MIME Type                       : image/png
Image Width                     : 152
Image Height                    : 152
Bit Depth                       : 8
Color Type                      : RGB
Compression                     : Deflate/Inflate
Filter                          : Adaptive
Interlace                       : Adam7 Interlace
Software                        : Adobe ImageReady
XMP Toolkit                     : Adobe XMP Core 5.5-c021 79.155772, 2014/01/13-19:44:00
Original Document ID            : xmp.did:15d8a979-1097-4474-accc-90fc2b02fc58
Document ID                     : xmp.did:25F46708355311E580E8DA1A4BE6CE82
Instance ID                     : xmp.iid:25F46707355311E580E8DA1A4BE6CE82
Creator Tool                    : Adobe Photoshop CC 2014 (Macintosh)
Derived From Instance ID        : xmp.iid:d4dcd418-cd4f-4a8e-a9eb-670e43ff2ee8
Derived From Document ID        : adobe:docid:photoshop:3a0c5b59-7dbd-1178-bb27-91c7aa683e3f
Image Size                      : 152x152

Apparently, this icon was generated by Photoshop.

These are a lot of information… What happens if we remove all EXIF data?

$ exiftool -all= -o apple-icon-no-exif.png apple-icon.png
$ ls -l
-rw-rw-r-- 1 philippe philippe 3555 May 17 17:04 apple-icon-no-exif.png
-rw-rw-r-- 1 philippe philippe 4506 Aug 12  2015 apple-icon.png

We’ve just decreased the size of the Apple Touch icon by more than 20% just by removing the metadata!

Now let’s do the same of, say, the Alphabet Touch icon, wisely generated by RealFaviconGenerator:

$ wget -O alphabet-icon.png
$ exiftool -all= -o alphabet-icon-no-exif.png alphabet-icon.png
$ ls -l
-rw-rw-r-- 1 philippe philippe 3714 May 17 17:09 alphabet-icon-no-exif.png
-rw-rw-r-- 1 philippe philippe 3714 Apr 21 05:17 alphabet-icon.png

(yep, we took the 152×152 version, because this is the size of Apple’s Touch icon)

Now, the image is 3.7KB, with or without EXIF, simply because RFG does not produce verbose metadata.

Okay, it’s not entirely Photoshop’s fault. It probably has options to not be that verbose. Plus you’re responsible of post-processing your assets before deploying them. But if Apple did the mistake, others probably made it too. But at least not RFG users.

How Android Chrome scales down icons


Android Chrome behaves almost like iOS: it scales down the icons correctly when it cannot find an icon that exactly matches its screen, producing excellent results using an algorithm similar to Blackman or Lanczos. Just mind special icons, such as pixel art icons that need a particular kind of algorithm such as Nearest Neighbor. But even in that case, Android Chrome offers a decent result.

The problem

The issue all explained here. Plus it’s always a concern when you try to reduce the amount of icons.

The test

I made a test with my old Galaxy S5. When Android Chrome is given a manifest declaring all documents icons for homescreen and splashscreen (9 icons, ranging from 36×36 to 512×512), it takes the 144×144 icon for the home screen and 384×384 icon for the splashscreen. Which is a good thing: as it is suggested to declare only two 192×192 and 512×512 icons, the Galaxy S5 is a good candidate to check the scale down in a real life situation.

For this test, I used this sample 512×512 icon and declared it, alone, in a manifest:

Android Chrome original 512x512 icon
Android Chrome original 512×512 icon

Here is what my Galaxy does with it:

Added to home screen : the icon is now 144x144
Added to home screen : the icon is now 144×144
Splash screen, the image is now 384x384
Splash screen, the image is now 384×384

In both cases, we can see that the results are great (despite of my suboptimal choice of theme and background colors).

As for iOS, I couldn’t find an exact match with any of the 40 algorithms provided by ImageMagick. The closest ones are Blackman, then Lanczos.

Visually, I can’t see any difference between what Chrome creates and the 512×512 icon resized to 144×144 by ImageMagick with Blackman and Lanczos:


What about a pixel-art icon, one that shouldn’t be interpolated?

512x512, pixel art icon
512×512, pixel art icon

It’s okay, really:

A pixel art icon added to home screen
A pixel art icon added to home screen
Pixel art icon splashscreen
Pixel art icon splashscreen

As with iOS, you can spot differences between what you get and what you could expect by providing the icon with the right size (eg. 384×384 for splashscreen and my Galaxy S5) and scaled with the right algorithm (eg. Nearest Neighbor). But it’s no big deal.

How iOS scales the Apple Touch icon


When iOS Safari encounters an Apple Touch icon too large for the screen, it scales it down. Which scaling algorithm does iOS use for this task? It’s not clear. Maybe something close to Lanczos2. The main issue is when the icon requires a particular algorithm, such as Nearest Neighbor: iOS doesn’t exactly produce the expected result. But it’s no big deal.

What is the problem?

There are a lot of Apple Touch icons, ranging from 57×57 to 180×180. If you really want the full story, you can generate up to almost 20 icons! However, when an icon is missing, that’s not a blocking issue. iOS scales the icon down.

As suggested by several users and “summarized” in issue #211, it would be great to generate only one Touch icon (or only a few ones) and let the devices do the scaling. Issue solved, right?

Not so fast. There is one tiny question to answer before dropping almost redundant 20 icons: how good is iOS at resizing pictures?

Finding iOS scaling algorithm

The methodology:

  • Create a sample 180×180 icon with a diagonal line in it:
    180x180 Apple Touch icon
  • Push this image in a web site and add it to the home screen of my iPad Mini running iOS 9:
    180x180 Apple Touch icon added to home screen
    Here, iOS resizes the pic to 76×76.
  • Crop the rounded corners to remove all traces of background:
    Cropped icon
  • For each algorithm supported by ImageMagick (come on, more than 40!), repeat the same steps with Image Magick commands (ie. scale with the tested algorithm and crop the result), then compare iOS and ImageMagick.

And the result is… iOS doesn’t use any of the algorithms offered by ImageMagick. After studying the results returned by the ImageMagick’s compare command, this is apparently close to Lanczos2. But it’s not exactly the same. In other words, iOS applies a small anti-aliasing effect. Most of the times this is just fine.


Small issue with specific Apple Touch icons

Some images require a specific scaling algorithm. For example, you don’t want the classic scaling with pixel art pictures. Quite the contrary, you want to retain the pixelization. In this case, iOS doesn’t do what you want.

When we zoom the icons, there is clearly a difference:

On the left, a 180x180 icon scaled down by iOS. On the right, a 76x76 icon prepared with RFG and the Nearest Neighbor alforithm.
On the left, a 180×180 icon scaled down by iOS. On the right, a 76×76 icon prepared with RFG and the Nearest Neighbor alforithm.

Yet, at normal scale, it’s nearly not visible. I frankly can’t see the difference between the two:

On the left, a 180x180 icon scaled down by iOS. On the right, a 76x76 icon prepared with RFG and the Nearest Neighbor alforithm.
On the left, a 180×180 icon scaled down by iOS. On the right, a 76×76 icon prepared with RFG and the Nearest Neighbor alforithm.


If you are careful enough to pick a particular scaling algorithm when generating your icons (eg. Nearest Neighbor), then you might want to keep all the icons to make sure your visitors really get the icon you want. Else, you can safely drop smaller icons. iOS will do just well.

Your favicon with Gulp plugin for RealFaviconGenerator

After Grunt, here is the Gulp plugin for RealFaviconGenerator and also the dedicated page to generate your favicon with Gulp.

Creating a favicon should always be a quick and easy task. This is the promise of the Gulp plugin for RealFaviconGenerator. When using this plugin, you don’t have to learn RealFaviconGenerator’s API. Instead, go to and create your favicon as usual. In the result page, click the Gulp tab.

Instructions for Gulp

Here, you find step-by-step instructions to setup your favicon in your Gulpfile. A few minutes later, your favicon is fully integrated to your Gulp build!

You have three Gulp tasks at hand:

  • generate-favicon: the task you run once and each time there is an update on RealFaviconGenerator.
  • inject-favicon-markups: the task you run constantly, each time you modify one of your pages.
  • check-for-favicon-update: the task you run from time to time to make sure your favicon is up-to-date.

I’m eager to get your feedback!

GruntJS plugin for RealFaviconGenerator is back, simpler than ever

A year ago, the GruntJS plugin for RealFaviconGenerator was released. The plugin itself was usable, but it missed one important feature: the ability to be used easily, without reading RealFaviconGenerator’s API and testing.

Want to handle favicon with Grunt? Here is how to do it:

  1. Go to RealFaviconGenerator to create your icons for Grunt: iOS, Android and friends.
    Favicon editor
  2. On the next page, follow the instructions. A copy/paste later, your Grunt project is ready.
    Grunt tab

I’m confident this feature will have success, at least in the long run, because:

  • It is about Grunt, which is one of the tools that make web development more professional. For years, manual, error prone deployment has been the norm, and this is still a common practice. In a few years, these bad habits will be over, at least among professionals.
  • It is about serious asset management. A few years ago, the regular way of adding jQuery to a project was to download it manually and putting its files right in the middle of the homemade material. Now more ad more people use Bower or other tools to manage these resources. It should be the same for the favicon and related icons: getting a favicon.ico and dropping it somewhere in the website project is (should be) a practice from the past.
  • As a mundane task, favicon should be done quickly. We spend hours crafting HTML pages, tailoring CSS and writing unit tests. But how much time would you dedicate to the favicon? Only a few minutes. This is a small task by nature. Anything that excess 5/10 minutes is flawed.

RFG addresses all this points.


Right now, you can use this new feature for free. However, this won’t last. As I announced it in January, I want to make money with RealFaviconGenerator. I have run ads for months and the conclusion is: ads don’t even pay for the hosting costs. I actually makes more money from donations (thank you all!!), which are greatly appreciated but not very significant in total.

So I want to offer additional, paid options. What I told a few months ago still apply: what was free will remain free. We are only talking about new stuff.

Right now, I don’t know which model is the best: a classic subscription or pay-as-you-go? This is the purpose of the feedback form showed just after the instructions for Grunt:

Feedback Form

Your feedback would be very appreciated!

RFG needs your feedback (2/2)

A few days ago RFG started to collect user’s feedback in three areas.

170 visitors filled one of the forms. THANK YOU!!


The first question was about the platforms you would like RFG to support. The winner is… the Open Graph image, used by Facebook when you share a page.


Beyond the raw results, the social networks are the undisputed winners. Most votes for Coast and Yandex were from people who voted for everything. Whereas many feedbacks were only for OG and Twitter, or OG alone.


Three options were proposed:

  • Small pictures: RFG resizes pictures as needed to generate the icons. Regarding small icons (16×16 and 32×32), it is sometimes better to edit them manually, or to draw them pixel-by-pixel. RFG would allow you to upload your very own custom 16×16 and/or 32×32 icon(s).
  • Smaller package: RFG generates 20-something icons and about 15 lines of HTML. Many people don’t want to clutter their HTML with so much code. RFG could create much less with very few side effects.
  • Embedded instructions: The instructions to setup your favicon (and the HTML) are given by RFG web site. The Zip file itself contains only the images and related files. In other words, the package is not standalone: if you leave RFG too soon, you end up with a useless archive. The package could contain a text file to remind the instructions.


Embedded instructions is the most wanted option. I thought most people would want a smaller package, while I considered the embedded instructions as a nice-to-have. I was wrong, and that’s the point of asking for opinions.

Tools and framework

This is my favorite part. There were less votes here, only 17. I was not surprised: the form was in the result page, where the user is presented the material he came for: the package and HTML code. Most people probably didn’t want to hear about anything else. But I could feel the interest is real. Unlike the platform and options forms, where several users selected everything, all votes here were for one tool or framework. So I could really hear a visitor asking for his favorite solution.

Tools and platforms

The winner is Grunt, by a short advance. Gulp and Ruby on Rails were nearly as popular. Symfony got no vote, but that’s okay. The test was run for only 3 days (1st day was a Sunday) and the question was asked to people who didn’t come for this.

Thank you again for all this feedback!!

Alright, time to get back to work!

RFG needs your feedback (1/2)

Until now, RFG didn’t explicitly asked for feedback. Users have done it via:

I’ve just started something I should have done long ago: survey users for direct feedback.

During a few days, you will find three forms right in the interface of RealFaviconGenerator. The first one is about the supported platforms.

Which platform to support next?

The second one is about options. Here you will find usual suspects (at least from my point of view).

Which options to support next?

The third one is for integration. RFG generate HTML, but this is not the only way. What do you use? Build tools such as Gulp? Framework like Ruby on Rails?

Which framework or tool to support next?

Next episode: the results!

Safari’s pinned tabs support (Mac OS X El Capitan)

Apple released Mac OS X “El Capitan” a few days ago. Safari comes with pinned tabs, a cool feature to keep some sites around. The feature itself is not new, but Safari makes it really neat (at 0:48). Guess what? There is a new icon. RealFaviconGenerator lets you design yours in seconds. Time to generate your favicon again!!

The new icon for Safari’s pinned tabs

No, Apple didn’t recycle one of the numerous existing icons, such as its famous Touch icon for iOS. It specifies a new, proprietary icon. The big news is its format: SVG. For (arguably) the first time in favicon (and derivatives) history, a vector format is used instead of a classic bitmap format, usually PNG. I’m not sure Apple chose it for its scaling ability. Tabs icons are small. But it is probably easier to play with colors with a vector image. Which Safari does when a tab is rolled over or selected.

Unlike most favicon-related images, this new icon comes with design requirements. Well, one requirement. The icon must be monochromatic. Black with a transparent background. The icon is completed by a “theme color”. When the tab is not selected, Safari renders the icon in grey. When the tab is active, Safari uses the theme color. So it should probably be the dominant color of your original icon or logo to make it consistent with your site.

Support in RealFaviconGenerator

Creating this icon can be more challenging than usual. Many times, icon design takes place in the bitmap world. Gimp in my case. Creating an SVG picture out of a flat bitmap can be a daunting task. As always, RealFaviconGenerator’s mission is to provide no-brainer settings to get the job done in seconds.

Transparent favicon? Use Silhouette

If your icon has a transparent background, using its silhouette can be a winner. Take the demo icon:

Demo icon

Its silhouette fits the pinned tab just nicely:


But what if the original picture is not transparent, or if its silhouette is not relevant? Hum… We need something else. Take RFG’s logo:

Favicon master picture

Its silhouette is quite useless:



Yep, “monochromatization” brings results when you google it, although it has nothing to do with graphics. Sorry.

The other option is to first turn the picture into a black-and-white version. You can test various thresholds in order to find the perfect setting for your particular case. Although the results vary from an image to another, there is normally a threshold that works well. During my tests, no picture was left behind.

What I get with RFG’s logo:

Very low threshold
Very low threshold
Low threshold
Low threshold
Medium threshold
Medium threshold
High threshold
High threshold

Whatever the settings, RealFaviconGenerator uses potrace to produce a genuine SVG picture. This tool is impressive.

In order for the editor to be as reliable as possible, the images used as previews are first vectorized with potrace, then converted to PNG again. This way, you know that what you see in not a mere promise but the actual outcome.

Enough talking, time to refresh you favicon!

WordPress users: your favicon up-to-date. Automatically.

With 60,000 active installs, Favicon by RealFaviconGenerator WordPress plugin is the most favicon-related WordPress plugin. Since a few months, the plugin looks for updates and notifies you whenever the favicon should be refreshed.

There is new stuff. The plugin is now able to update the favicon automatically. Next time Apple introduces a new Touch icon resolution for its latest iPhone, your favicon will be regenerated overnight.

Automatic update notice

This feature relies on the non_interactive_request parameter of the interactive request API. Each time you use the plugin to create a favicon, it not only installs the generated package. It also saves all settings: the iOS design, the compression rate… So whenever an update is available, the plugin is autonomous and can create your favicon update, yet taking advantage of the improvements of RealFaviconGenerator.

Is it the end of manual updates? Nope. Some updates require human interactions. For example, RealFaviconGenerator will someday supports Coast by Opera. This update does not make sense in an automated fashion. It requires you to pick the design that matches your icon and site. So still expect to work on your favicon again from time to time.

Web site, interactive API and non-interactive API now work together

Until now, RealFaviconGenerator consisted in two universes:

  • The interactive API, aka “User interacts with the UI to create a favicon”
  • The non-interactive API. Post a favicon generation request to the web service and get your package a second later

Although similar, these two domains used to never speak to each other.

This time is over. Now, when you use either the interactive API of simply RealFaviconGenerator as a web site, the non-interactive request is never far.

RealFaviconGenerator, the web site

The regular way to use RealFaviconGenerator is accessing it via the web browser. A few clicks later, you are ready to download the favicon package. Until today, that was the end of the story. But you can now get the equivalent non-interactive API request:

Generated non-interactive API request

Follow the instructions and you get a working API request.

Interactive API

The interactive API is not different of the classic web site: you get the same favicon editor and same options. When the client is back in control (for example the Favicon by RealFaviconGenerator WordPress plugin), the transaction is over.

But there is more: the API client receives the equivalent non-interactive API request. It can reissue the request as is to create the favicon again.

What’s next?

Expect some updates in the WordPress plugin in the next few weeks! Grunt and Gulp plugins are also on the TODO list.