Mathias Bynens

Everything you always wanted to know about touch icons

Published · tagged with HTML, iOS, performance

“Touch icons” are the favicons of mobile devices and tablets. Adding them to your web page is easy, and I’m sure you already know how this works using HTML:

<!-- In its simplest form: -->
<link rel="apple-touch-icon" href="apple-touch-icon.png">

It’s a shame Apple didn’t just implement the standard <link rel=icon> and chose to come up with a more verbose proprietary link relation instead. Chrome v31+ for Android does support this syntax, though! Use it as follows:

<link rel="icon" sizes="196x196" href="apple-touch-icon.png">

If no such HTML is found, Chrome for Android falls back to the Apple touch icons instead. Update: As of Chrome 30+, this is no longer true: apple-touch-icon-* is no longer fetched automatically, since the 404 pages that are usually returned were consuming 3-4% of all mobile bandwidth usage. For the time being it is still downloaded when the appropriate <link> HTML is present, though.

Apple iOS has supported touch icons since iOS 1.1.3. What’s weird is that Android 2.1+ also has apple-touch-icon support (with a few quirks).

For web pages that don’t specify a custom touch icon, a thumbnail screenshot of the page is used instead. Android has a default icon, and some systems fall back to the favicon if it’s available.

Fancy effects

iOS automatically adds some visual effects to your icon so that it coordinates with the built-in icons on the Home screen (as it does with application icons). Specifically, iOS adds:

  • Rounded corners
  • Drop shadow
  • Reflective shine

As of iOS 2.0, you can prevent the addition of these effects by using the precomposed keyword:

<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-precomposed.png">

Since the rel attribute accepts a space-separated list of values in HTML, theoretically it should be possible to fall back to the regular icon with added effects for iOS 1 without requiring an extra <link> element:

<link rel="apple-touch-icon-precomposed apple-touch-icon" href="apple-touch-icon-precomposed.png">

In practice, however, it doesn’t work that way. iOS 4.2 seems to ignore the entire declaration if you’re using the space-separated value technique.

I’d recommend to always use precomposed icons. It gives you full control over your icon, and it’s the only kind of icon Android 2.1 supports. As of iOS 7, no special effects are applied to touch icons anymore, so if you only care about iOS 7 and up you don’t have to use precomposed anymore.

Different icon sizes

The Icon and Image Sizes section in the iOS HIG states that you should create the following icons:

  • one that measures 76 × 76 pixels for iPad and iPad Mini models with a 1× display;
  • one that measures 120 × 120 pixels for iPhone 4s, iPhone 5, iPhone 6 (which have a 2× display);
  • one that measures 152 × 152 pixels for iPad and iPad Mini models with a 2× display;
  • one that measures 180 × 180 pixels for iPhone 6 Plus (which has a 3× display).

Update (June 2013): As of iOS 7, the recommended touch icon size for Retina-display iPhones went up from 114 × 114 pixels to 120 × 120 pixels. The icon size for Retina-display iPads went up from 144 × 144 pixels to 152 × 152 pixels. This post has been updated to reflect that.

Update (September 2014): This post has been updated once again now that iOS 8 and the iPhone 6 Plus have been released.

It’s perfectly possible to just create one high-resolution icon and use that for all devices. In fact, this is how Apple does it. Devices with smaller screens or lower display resolutions automatically resize the icon. The downside is that these devices load the large high-quality image, while a much smaller file would have worked just as well. This wastes bandwidth and affects performance negatively for the end user whenever the site is added to the home screen.

Luckily, as of iOS 4.2 it’s possible to specify multiple icons for different device resolutions by using the sizes attribute:

<!-- For non-Retina (@1× display) iPhone, iPod Touch, and Android 2.1+ devices: -->
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-precomposed.png"><!-- 57×57px -->
<!-- For the iPad mini and the first- and second-generation iPad (@1× display) on iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="apple-touch-icon-72x72-precomposed.png">
<!-- For the iPad mini and the first- and second-generation iPad (@1× display) on iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="76x76" href="apple-touch-icon-76x76-precomposed.png">
<!-- For iPhone with @2× display running iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="apple-touch-icon-114x114-precomposed.png">
<!-- For iPhone with @2× display running iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="120x120" href="apple-touch-icon-120x120-precomposed.png">
<!-- For iPad with @2× display running iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="144x144" href="apple-touch-icon-144x144-precomposed.png">
<!-- For iPad with @2× display running iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="152x152" href="apple-touch-icon-152x152-precomposed.png">
<!-- For iPhone 6 Plus with @3× display: -->
<link rel="apple-touch-icon-precomposed" sizes="180x180" href="apple-touch-icon-180x180-precomposed.png">
<!-- For Chrome for Android: -->
<link rel="icon" sizes="192x192" href="touch-icon-192x192.png">

A few simple rules apply here:

  • If there is no icon that matches the recommended size for the device, the smallest icon larger than the recommended size is used.
  • If there are no icons larger than the recommended size, the largest icon is used.
  • If multiple icons are suitable, the icon that has the precomposed keyword is used.

But it gets more complicated. Pre-4.2 versions of iOS simply ignore the sizes attribute, so the above code snippet would be interpreted as:

<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-precomposed.png"><!-- 57×57px -->
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-72x72-precomposed.png">
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-76x76-precomposed.png">
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-114x114-precomposed.png">
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-120x120-precomposed.png">
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-144x144-precomposed.png">
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-152x152-precomposed.png">
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-180x180-precomposed.png">

Only the last value in the document will be used on those systems. In this case, that’s the largest icon. Depending on how you look at it, it might be better to reverse the order of icons:

<!-- For Chrome for Android: -->
<link rel="icon" sizes="192x192" href="touch-icon-192x192.png">
<!-- For iPhone 6 Plus with @3× display: -->
<link rel="apple-touch-icon-precomposed" sizes="180x180" href="apple-touch-icon-180x180-precomposed.png">
<!-- For iPad with @2× display running iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="152x152" href="apple-touch-icon-152x152-precomposed.png">
<!-- For iPad with @2× display running iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="144x144" href="apple-touch-icon-144x144-precomposed.png">
<!-- For iPhone with @2× display running iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="120x120" href="apple-touch-icon-120x120-precomposed.png">
<!-- For iPhone with @2× display running iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="apple-touch-icon-114x114-precomposed.png">
<!-- For the iPad mini and the first- and second-generation iPad (@1× display) on iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="76x76" href="apple-touch-icon-76x76-precomposed.png">
<!-- For the iPad mini and the first- and second-generation iPad (@1× display) on iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="apple-touch-icon-72x72-precomposed.png">
<!-- For non-Retina iPhone, iPod Touch, and Android 2.1+ devices: -->
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-precomposed.png"><!-- 57×57px -->

This way, older iOS versions download the smallest icon instead of the largest one. So, instead of forcing the largest icon to all devices unless they support the sizes attribute (iOS 4.2+), we now serve the smallest icon unless @sizes is supported. In other words, we’re now using progressive enhancement instead of graceful degradation :)

When in doubt, always use this snippet. With support for nearly all iOS versions and devices, and as many different Android versions as possible, it’s the most robust way to add touch icons to your site.

I’ve had several people test this on a Nexus One running Android 2.3 (Gingerbread), and it seems @sizes is not supported there either. However, it behaves differently than old iOS versions: instead of using the last <link> element’s @href value, it will use that of the first <link> element with rel="apple-touch-icon" or rel="apple-touch-icon-precomposed". In the case of the above code snippet, that’s the largest icon available.

Update (March 2013): I crowdsourced some more tests on Android devices. Using the suggested snippet, Android 4.1.x and 4.2.x on Galaxy Nexus both get the 57×57px icon as long as the default Android browser is used to add the bookmark. Bookmarking from within Chrome causes the touch icons to be ignored. This is fixed in Chrome 27. The bug is also present on Samsung I9100 Galaxy S II devices running Android 4.0.x.

Update (July 2013): As of this commit, Chrome for Android no longer requests apple-touch-icon(-precomposed).png by default (i.e., if such an icon isn’t referred to from the HTML source).

Look ma, no HTML!

If no icons are specified in the HTML, iOS Safari will search the website’s root directory for icons with the apple-touch-icon or apple-touch-icon-precomposed prefix. For example, if the appropriate icon size for the device is 57 × 57 pixels, iOS searches for filenames in the following order:

  1. apple-touch-icon-57x57-precomposed.png
  2. apple-touch-icon-57x57.png
  3. apple-touch-icon-precomposed.png
  4. apple-touch-icon.png

That’s right — for iOS, it’s not necessary to use HTML to add touch icons to your site, even if you want to use multiple resolution-specific icons. Say adiós to the boatload of proprietary <link rel="apple-touch-icon"> elements on every single HTML page. Just create different versions of the icon, use the correct file names and place them in the root. (favicon.ico, anyone?)

So, what do we need?

  • apple-touch-icon-57x57-precomposed.png or apple-touch-icon-57x57.png for non-Retina iPhone and iPod Touch (@1× display);
  • apple-touch-icon-72x72-precomposed.png or apple-touch-icon-72x72.png for the iPad mini and the first- and second-generation iPad (@1× display) on iOS ≤ 6;
  • apple-touch-icon-76x76-precomposed.png or apple-touch-icon-76x76.png for the iPad mini and the first- and second-generation iPad (@1× display) on iOS ≥ 7;
  • apple-touch-icon-114x114-precomposed.png or apple-touch-icon-114x114.png for iPhone 4+ (with @2× display) on iOS ≤ 6;
  • apple-touch-icon-120x120-precomposed.png or apple-touch-icon-120x120.png for iPhone 4+ (with @2× display) on iOS ≥ 7;
  • apple-touch-icon-144x144-precomposed.png or apple-touch-icon-144x144.png for iPad 3+ (with @2× display);
  • apple-touch-icon-152x152-precomposed.png or apple-touch-icon-152x152.png for iPad 3+ (with @2× display);
  • apple-touch-icon-180x180-precomposed.png or apple-touch-icon-180x180.png for iPhone 6 Plus (with @3× display);
  • touch-icon-192x192.png for Chrome for Android;
  • apple-touch-icon-precomposed.png and apple-touch-icon.png as a fallback for everything else (possibly including non-Apple devices).

It’s a good idea to include both apple-touch-icon.png and apple-touch-icon-precomposed.png for maximum compatibility: iOS 1 and BlackBerry OS6 don’t support precomposed icons. (Note that Android 2.1 only supports precomposed icons.) You could use rewrite rules to avoid having to duplicate the file.

Sadly, the no-HTML approach doesn’t work on the native Android browser (tested in 2.3 Gingerbread, 3 Honeycomb, 4.1 Jelly Bean), although I’ve had reports saying it does work in and 4.2 Jelly Bean’s default browser. I haven’t been able to test BlackBerry OS6 yet. If you want, you can test this technique on my website. Save a bookmark to this page to your home screen, and see if you get a custom touch icon or not. Please let me know what you find out!

Summary

So, which technique to use? It all depends, really.

  • If Android support is a must, you’ll have to use HTML, and I’d recommend using the last code snippet under the “Different icon sizes” section.
  • If iOS is all you care about, I strongly suggest using the no-HTML approach.
  • If you’re lazy and don’t really care about Android, legacy iOS versions, or performance, I suppose you could just use a single 180×180px icon, name it apple-touch-icon-precomposed.png and place it in the root of your website.

About me

Hi there! I’m Mathias. I work on Chrome DevTools and the V8 JavaScript engine at Google. HTML, CSS, JavaScript, Unicode, performance, and security get me excited. Follow me on Twitter, Mastodon, and GitHub.

Comments

wrote on :

I should probably add that I researched the use of media queries to serve different touch icons based on the device’s screen resolution. The code looks like this:

<link rel="apple-touch-icon-precomposed" media="screen and (resolution: 163dpi)" href="apple-touch-icon-57x57-precomposed.png">
<link rel="apple-touch-icon-precomposed" media="screen and (resolution: 132dpi)" href="apple-touch-icon-72x72-precomposed.png">
<link rel="apple-touch-icon-precomposed" media="screen and (resolution: 326dpi)" href="apple-touch-icon-114x114-precomposed.png">

Based on my tests, this doesn’t work correctly. The iOS devices I tested on — iPad, iPhone 3G S and iPhone 4 — were all running iOS 4.2, and they all just used the first touch icon referenced in the HTML. The media queries didn’t seem to matter; the order of <link> elements in the source did. Really weird.

Update: Looks like this has finally been fixed in iOS 5. It also works for startup images now:

<!-- 320x460 for iPhone 3GS -->
<link rel="apple-touch-startup-image" media="(max-device-width: 480px) and not (-webkit-min-device-pixel-ratio: 2)" href="startup-iphone.png">
<!-- 640x920 for retina display -->
<link rel="apple-touch-startup-image" media="(max-device-width: 480px) and (-webkit-min-device-pixel-ratio: 2)" href="startup-iphone4.png">
<!-- iPad Portrait 768x1004 -->
<link rel="apple-touch-startup-image" media="(min-device-width: 768px) and (orientation: portrait)" href="startup-iPad-portrait.png">
<!-- iPad Landscape 1024x748 -->
<link rel="apple-touch-startup-image" media="(min-device-width: 768px) and (orientation: landscape)" href="startup-iPad-landscape.png">

Björn wrote on :

Thanks for the great article. In my project I have been using JavaScript and user agent detection (ugh!), to build the link rel="apple-touch-icon" dynamically.

I will rip it out and replace it with this.

Ric wrote on :

Looks like a bit of a messy system to me, I guess scanning the root is okay. But if we add these link tags, the IE9 meta tags etc etc we'll soon have a 1000 line head block!

Kroc Camen wrote on :

Using rel="apple-touch-icon apple-touch-icon-precomposed" (or vice-versa) does not work in iOS 4.2 (and likely before), it ignores the whole declaration, so you must put composed and precomposed on separate LINKs.

David wrote on :

Great article. One thing I’m trying to find is if it’s possible to change the URL associated with the icon? For instance, if an icon is added from my homepage can I control what page the icon opens?

Steve wrote on :

I got nothing on my Nexus S running 2.3.4... But I'm not sure I set the link up right. I might have another play later.

Anselm H. wrote on :

Hi, what about behavior of devices if these icons are in root directory (and don't need to be linked)? Is it the same? Or do they choose the right then?

Thanks a lot for answering… -A.

wrote on :

Zev: apple-touch-icon never was a registered rel value; it was never really valid. The only thing that changed is the validator, which now explicitly marks invalid link relations as validation errors.

The same goes for shortcut; however, that one quickly was registered after the recent validator.nu update.

Anyhow, I think we can all agree that it sucks having to use invalid markup just to get touch icons to work on most devices. I’ll repeat what I wrote in the article:

(It’s a shame Apple didn’t just implement the standard <link rel=icon> and chose to come up with a more verbose proprietary link relation instead.)

Zev Goldberg wrote on :

Arrgh. I see that now.

Of course, I'm not even an Apple person, and I don't wish them to write the spec with their non-semantic name all over it. But I am a firm believer in the spec being written to follow the cowpaths. If they (and also Android) have the browsers to support it, shouldn't we push to have apple-touch-icon registered as well?

wrote on :

Zev:

If they (and also Android) have the browsers to support it, shouldn't we push to have apple-touch-icon registered as well?

It seems weird to standardize anything that has a vendor name in it (at least to me). But then again, shortcut got registered as well, so why not.

I’ve registered rel=apple-touch-icon now.

Henri Sivonen wrote on :

Mathias:

Why only apple-touch-icon why not apple-touch-icon-precomposed, too? I don’t have an iOS device here, so I can’t tell if it actually works as a rel value or if it only works as a magic file name. Apple’s docs kinda suggest it works as both. (Why did they make file names magic anyway?)

wrote on :

Henri: In my excitement I had simply forgotten to register apple-touch-icon-precomposed as well. Fixed now. Thanks for the reminder!

George wrote on :

I started seeing queries in my server logs for these PNG files even though I don’t have them on my system, nor do I have any links to them in any of my HTML files. LOL. So I added a soft link for apple-touch-icon.png to some 50 MB file on my system. Anythying that does a GET on a web server without first finding that filename in a parent HTML file deserves whatever it gets.

Ajay wrote on :

Is there any way to define custom text for the Home Screen icon? At the moment, it uses the page title and truncates it. My page title has a bit of descriptive text in it too for SEO purposes, but i'd like that to be removed for the Home icon.

I cant find any answers that say this is possible.. yet..

Luke wrote on :

Hi, great post. Is it possible to have a different web page title for Add to Home Screen, so it’s shorter? Without using some JavaScript to check. Thanks.

On browsers I’d like the proper webpage title, and a shorter version if they add to home screen on iOS device.

Brian French wrote on :

I tested your no-HTML approach in Android 3.2.1: Home screen bookmark to this page is a custom touch icon.

David Calhoun wrote on :

Just a heads up — it looks like touch icons in a password-protected directory aren’t accessible (tested on iOS5). This make sense, as the icons are requested by the system, not the browser (where a user may have typed in a user/pass).

Kristen Grote wrote on :

Hey Mathias,

Great writeup! Just thought I should let you know that I saved this page on my HTC Thunderbolt running Android 2.2.1 and I only got Android’s default bookmark icon.

Before reading this article, I was messing around on another site of mine, and I placed my apple-touch-icon.png file at the root, and removed the link to it from the site’s <head>. This caused the site icon to appear inside Android’s default bookmark icon. Whether it was the favicon or the apple-touch-icon being used, I don’t know. I’ll do some further testing if I have time and let you know.

Harri Hälikkä wrote on :

Ah, what a great mess this relatively simple thing is. Thanks for the excellent writeup!

One additional note: the default browser of the recently announced MeeGo-based Nokia N9 (and N950) device is able to add sites to application grid as well, but doesn’t support the -precomposed version. So, apple-touch-icon.png is needed to make the site play nicely together with this device. the icon can be just placed to the root of the site, no need to add a link to it in the <head>.

And to confirm, yes, this current page works well with N9, the icon is shown as it should be.

Apparently even sites such as mobile.twitter.com or touch.linkedin.com can’t get this right — it’s a bit frustrating.

Mike Cowles wrote on :

Hey,

I'm running into a brick wall with this.

I have a HTC EVO and put an icon at http://mikecowles.com/apple-touch-icon-precomposed.png in the root and in the folder of the mobile version I’m working on at http://mikecowles.com/mobile/apple-touch-icon-precomposed.png. I made it the lazy 114px size and have tried bookmarking the site and always get the default red ribbon with the star, icon.

Can you offer any help?

Thanks very much! =]
Mike. <><

betovarg wrote on :

By far, the best touch icon tutorial I've found. Saved my life with the reverse order, thats a must tweet tip.

thanx!

Kevin wrote on :

George: That’s an awesome idea. If my personal site kept on getting those requests I’d totally do it too. Sadly I don’t think it would go over well if I did that on a customer’s site.

Red Feet wrote on :

Ajay: Yes, a shorter title, different from your descriptive/long SEO title is possible:

<title>Long SEO title</title>
<script>
document.title = 'Short display title';
</script>

Luke: No, without JavaScript it’s not possible, but how many iOS users disable JavaScript?

Dries wrote on :

Mike: I’m having the same issue on my website when testing with my HTC Sensation. The fact that it works for Mathias makes me think that HTC Sense ignores apple-touch_icon.png while stock Android does recognize it.

iDGS wrote on :

Red Feet: Oo! Thank you! That’s exactly what I was looking for! Namely, a way to control the name given to the Apple Touch Icon that gets saved to the iOS desktop, while keeping my longer, carefully crafted title for SEO! Yes, I still wish I could set the ATI name directly, and thus keep and show my homepage title of choice. However, in the meantime, this is a compromise I can live with.

@Mathias: Maybe put a mention of this title-trickery gem up in the main text? I confess I was about to skip the comments and continue searching elsewhere. Glad I kept reading!

Sascha Hendel wrote on :

A note about transparency: if you use PNG images with alpha channel (transparency) iOS will make them opaque and use a black background instead. This happens even if you use the precomposed option!

Android supports (as far as I tested) transparency on precomposed icons (maybe on normal icons, too). You can create really nice icons with transparency on Android, because the OS does not insist on this boring rounded edge button style.

Right now I’m trying to set up a line of <link> tags with different parameters, to provide iOS with an opaque version (because I don’t want black background) and a transparent version for Android…

Sonya: A note about changing the page title with JavaScript — be careful with manipulating the page title this way. Google and other search engines could interpret this as bad SEO.

James wrote on :

No matter what I've tried I cannot get these icons to show on my HTC Sensation. I always get the red ribbon bookmark icon. Has anyone been able to get past this on this phone?

iDGS wrote on :

Sonya: Ooo! Lovely script refinement! And that Unicode-escape demo is a nice touch. Many thanks! (For a few additional usage notes, see comments "over yonder." )

rstuppi wrote on :

I just downloaded HTML5 Boilerplate, unzipped it and copied it up to my website without any modifications, and favicon did not show. I tried it in IE9, FF, Opera, and Safari. Nothing. Granted, I am in a shared environment at Network Solutions and maybe they are doing some caching but this was a brand new website. I was very disheartened after watching 2 1/2 hours of HTML5 Boilerplate videos only to find that what seems to be basic web functionality (favicon?) did not work. What am I not understanding, what am I missing?

Christian wrote on :

It’s worth pointing out that Reeder, a popular Google Reader client, takes apple-touch-icons even further: its non-Retina icons are 157×157px, so its Retina icons are 314×314; that’s the size I serve up, and it scales down fine.

Joshua wrote on :

Does anyone know how to control the title when a person adds the icon to their screen?

wrote on :

Joshua: The <title> element is used for that. There’s no event that fires when the user adds the icon to the homescreen, so there’s no way to change it only when needed. You might be interested in comment #41, though.

Rob wrote on :

Saving this page to the home screen on Android 4.0 (on Asus Transformer TF101) produces a nice custom icon (white ‘m’ on the green squares).

And unfortunately a title truncated part way through the second word.

So no real need to use the rel= links soon (maybe now), the older Androids that use them will fade away.

Guillaume wrote on :

Hi @Mathias, nice post.

I haven’t found all I was looking for. I added two <link> tags in my <head>:

<link rel="apple-touch-startup-image" href="/images/Apple/apple-touch-startup-image.png" />
<link rel="apple-touch-icon" href="/images/Apple/apple-touch-icon.png" />

And that’s just working great client-side. But in my server log I’ve got several 404 not found errors that are very resource-consuming for me: looking for /apple-touch-icon-72x72-precomposed.png, /apple-touch-icon.png, etc… All you described in you “No HTML” section. Is there a way to avoid Apple to look for all versions if I do not want to provide them and reduce the 404 errors?

Thanks a lot for your answer :)

Drew wrote on :

Is it possible to use a combination of the link method and WebKit implementations at the same time? It appears the wrong size image is being picked up on my Samsung Galaxy SII using the link method.

You can see it here: http://www.whatsitworth.net/

Jack wrote on :

I am trying to create a custom icon for an imbedded web server. Think the web server may serve up the pages slightly differently than a traditional server and the pages don’t live on the server as a traditional html file. They are created on the fly when they are requested. I have spent all weekend trying to get this to work and would just give up and say it wasn’t possible except for the fact I can get it to work on an iPhone 1 (IOS 4.2.1).

I can not get it to work on and iPhone 4, or iPad 1 or iPad2 (IOS 5.1 and OS 5.1.1).

To get the iPhone 1 to work I had to place the apple-touch-icon.png file in the images folder (it did not work in the root or any other folder). In an attempt to get it to work on the other devices I have tried the file in every folder on the server. I also modified the file that generates the html on the fly to include in the <head> tag:

<link rel="apple-touch-icon" href="apple-touch-icon-iphone.png" >
<link rel="apple-touch-icon" sizes="72x72" href="apple-touch-icon-ipad.png">
<link rel"apple-touch-icon" sizes="114x114" href="apple-touch-icon-iphone4.png">
<link rel="apple-touch-icon" sizes="144x144" href="apple-touch-icon-ipad3.png">

I created the different size png files and tried them in a bunch of directories. I have also tried it with an absolute path to the .png files.

I can put the code and files on a traditional server and get them to work on all devices. I cant figure out why it work on the iPhine 1 and not the other devices Is it the IOS version, screen resolution, etc.

Any ideas?

Ryan wrote on :

All this SEO mythology is bunk anyway. Just optimize for humans and let Google do its job.

SlavD wrote on :

Great post. I wish they made it more standard. I’m currently trying to set it up on my site, however I’m still getting wrong sizes and sometimes I’m getting requests to / root of the website even though all my pages reference .png images from relative path.

I wonder if it is caused by someone bookmarking it on the device?

Anyway thanks for the post.

Mogens Beltoft wrote on :

Is it possible to use data URLs to have the apple-touch-icon encoded as text?

Chris Surtees wrote on :

Is it possible to have different iOS icons for different domains?

i.e.

yourwebsite.com/domain1 = iOS icon 1

yourwebsite.com/domain2 = iOS icon 2

yourwebsite.com/domain3 = iOS icon 1

wrote on :

Chris: I think you mean “paths” instead of domains. Anyway, yes it’s possible to define different icons for different resources on the same host, by using the HTML snippet mentioned in this post.

Loiseau2nuit wrote on :

Thanks a lot for that useful tip.

I was wondering if it was ever possible to replace all those PNG files by a single one .svg which would then be called by all the declaration as well.

I.e.

<!-- For third-generation iPad with high-resolution Retina display: -->
<link rel="apple-touch-icon-precomposed" sizes="144x144" href="apple-touch-icon-precomposed.svg">
<!-- For iPhone with high-resolution Retina display: -->
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="apple-touch-icon-precomposed.svg">
<!-- For first- and second-generation iPad: -->
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="apple-touch-icon-precomposed.svg">
<!-- For non-Retina iPhone, iPod Touch, and Android 2.1+ devices: -->
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-precomposed.svg">

I must admit that I’m still not familiar enough with all those devices (and with Raphael.js either ^^) to answer this today?

Thanks again and gr33tz from one of your downstairs french neighbour ;)

Saeid wrote on :

I noticed that Apple link in your article takes us to an icon that is 129×129px. That’s not the recommended dimension, is it? How come?

wrote on :

Saeid: Apple has had that 129×129px icon there since the first version of iOS that supported adding websites to your home screen. That was on the first-generation iPhone.

Back then it was probably forward-thinking to offer a higher-resolution icon. I guess they never got around to updating it afterwards, or they didn’t feel the need.

Paul wrote on :

Thank you/ Dank je wel/Danke/ Merci, for the informative details.

It seems bonkers that once again, just like Micro$oft always does, another software organisation has broken world standards, and most people have not objected.

wrote on :

Adam: Windows 8 tile images aren’t exactly “touch icons”, in the same way touch icons aren’t favicons. (It would be nice though if browser vendors could just decide on a single format!)

But since you asked: you’re probably looking for Microsoft’s Build My Pinned Site tool. The generated code looks something like this:

<meta name="application-name" content="Your website title">
<meta name="msapplication-TileColor" content="#000000">
<meta name="msapplication-TileImage" content="e9060f3d-e554-42c0-8ada-e614687fcdac.png">

Michael wrote on :

Android browser testing with HTC Thunderbolt on Android 4.0.4:

  • Dolphin = failure
  • Firefox = success
  • Chrome = failure, uses modified favicon
  • Default Android browser = failure

Tom wrote on :

Just tried it with a Samsung Galaxy SIII (4.0.4) and default browser. It just shows the favicon inside the red ribbon. Tried it for this site and some other sites like apple, bbd, etc. Anything we can do about that?

Joel_MMCC wrote on :

On the matter of shorter vs. longer web page titles, it looks like the HTML spec itself allows for this already, without needing anything new added to the spec, and requiring absolutely no proprietary vendor metatags (e.g. Mathias’s <meta name="apple-mobile-web-app-title" content="Short title for home screen"> above).

It’s so simple! According to the HTML 5 spec (and I believe HTML 4 as well), the title="…" attribute is a global attribute that can be used with any HTML tag! That includes the <title> tag itself!

So, hypothetically, you could do this:

<title title="Long SEO-friendly overly verbose page title goes here">Short title here.</title>

Voila! This should even validate nicely, as-is!

Now all that’s needed is for user agents (browsers and spiders) to decide what to do with that. I recommend a “smart” approach: For touch icon titles and the like, always use the shorter title that is the inner content of the <title> tag.

For browser window titles, likewise display the inner content of the <title> tag if the browser window is too narrow to display the longer one in the title="…" attribute (e.g. portrait orientation, manually reduced in size, etc.).

Search engines can simply use both as they see fit for their metadata and rankings.

There’d also be no reason that the two couldn’t be swapped (longer title as the tag’s inner content, shorter as the title="…" attribute, instead of vice versa) and have the user agent simply react intelligently based on which is longer and which is shorter, but traditionally the title="…" attribute is used to provide longer descriptive text for some usually shorter or smaller element via a ToolTip (e.g. for <img>, <a>, <abbr>, <acronym>, etc. tags), so that should be the preferred usage.

Steven Reid wrote on :

Good and revealing writeup — I was interested as sizes was causing my page to be invalid — I’m somewhat picky. It’s interesting to note that there’s no real advantage to having the various icon sizes other than what the user has to download and I have to ask — are we really that bothered about a few KB? The difference between my largest and smallest icons is 5 KB. So I don’t think it’s fair to call resorting to one icon on the server with no HTML as being ‘lazy’; I think it’s extraordinarily practical and certainly the route I’ll be taking from now on!

Joel C. Salomon wrote on :

Does anyone know whether Android or iOS care about the file name (if I’m not using the “Look ma, no HTML!” method)? I.e., can I have something like this

<link rel="apple-touch-icon-precomposed" sizes="144x144" href="/toy_rocket-144x144.png">
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="/toy_rocket-114x114.png">
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="/toy_rocket-72x72.png">
<link rel="apple-touch-icon-precomposed" href="/toy_rocket-57x57.png">

and expect it to produce the correct icons?

KM wrote on :

Does anyone know of any site which can preview what a touch icon would look like when displayed on iOS — don’t have access to any iOS/Android device, but want to see what the icon would look like after it has the rounded corners, shadow and reflection added to it by iOS.

KM wrote on :

Mathias: Thanks. Guess I’ll have to see if I can get the Android Emulator working, but that seems a lot of hoops to jump through just to look at an icon! I’m just wanted to add a simple icon to a website, as I’m getting “404 not found” errors in my log files from devices requesting these icons. Just wanted something quick and easy to be able to see what the end results would look like.

I’m using a Windows system, so can’t use iOS Simulator (unless I also want to start trying to build a virtual system with a hacked version of OS X on it etc).

There are a lot of sites that say they help you create these images, but none seem to offer a preview of what the results would actually look like when viewed on an iPhone etc.

Neil Robertson wrote on :

According to the Apple document, the new high resolution sizes are 120×120 for iPhone and 152×152 for iPad with advice about dividing by 2 for the standard resolutions. I assume this means that 60×60, 76×76, 120×120 and 152×152 will all have to be added?

Also, it looks like you are saying that apple-touch-icon-114x114.png has been superseded but shouldn’t this icon size still be provided for older devices that can’t be updated to iOS7 etc?

Thanks for keeping up to date with this stuff as it is very hard to find anything official on the Apple website.

wrote on :

Neil: Thanks for the heads up about the new 152×152px size for iPad touch icons. I’ve updated the article accordingly.

As for dividing by two for the standard resolutions, you could do that, but iOS automatically downscales larger icons when needed, and IMHO things are complicated enough already with the various icon formats. You already need 57×57px, 72×72px, 120×120px, and 152×152px icons; I’d rather not add separate 60×60px and 76×76px icons to that. Also, I seriously doubt iOS 7 will be made available on non-Retina iPhones and iPads (given their age) — in that case, there’s no reason at all to have those extra icons there.

Neil Robertson wrote on :

Mathias:

I’d rather not add separate 60×60px and 76×76px icons to that. Also, I seriously doubt iOS 7 will be made available on non-Retina iPhones and iPads (given their age) — in that case, there’s no reason at all to have those extra icons there.

Excellent point! I'm all in favour of keeing things simple! :)

Alhadis wrote on :

Thanks for the excellent write-up. :-)

However, one question: just how much of a performance hit does serving one high-resolution icon have, exactly? At a guess, iOS should logically cache the scaled version of an icon if it exceeds the ideal dimensions for the device’s screen resolution. As for bandwidth, well, if you’re careful with image compression (using crisp-quality PNGs, thereby reducing the colour palette), it wouldn’t be too taxing.

Nicholas Shanks wrote on :

There are various <DEL> elements which are not actually incorrect, but still apply to users running iOS < 7 (I for one won’t be upgrading). You should merely add the OS constraints and new sizes, and leave the old sizes as they were.

Calley Nye wrote on :

Thanks for the amazing write up! I'm a big fan :)

I have one question though. You explained the fancy effects that were added to touch icons in iOS 6, how have those effects changed in iOS 7? What does iOS 7 add to non-precomposed icons?

Ram Ram wrote on :

Calley: It just doesn’t do anything, but rounding corners with the new design curves (not precisely rounded).

See Safari Web Content Guide states:

Note: Safari on iOS 7 doesn’t add effects to icons. Older versions of Safari will not add effects for icon files named with the -precomposed.png suffix. See “App Store Icons” in the iTunes Connect Developer Guide for details.

And this blog post for the corners explanation.

Sandy Campbell wrote on :

Since Retina displays came out I’ve been making all my webclip icons a single size, 512×512px. They look great at all sizes and I’ve never had a problem with them loading slowly. And I suspect that Apple is probably hard at work on SuperRetina displays since they’re already making their icons 1024×1024. IconSlate is the best tool I’ve found for creating webclip icons and favicons. Favicons are a little easier to work with because you can embed several sizes (up to 256×256) in a single .ico file.

khoailang wrote on :

Should we put all of four links into the website or just one of them accordingly to iPhone or iPad…?

I put all four and test it in iPhone 5s, it looks like the latest icon is always used (152×152px).

<link href="apple-touch-icon.png" rel="apple-touch-icon">
<link href="apple-touch-icon-precomposed.png" rel="apple-touch-icon-precomposed">
<link href="apple-touch-icon-76x76.png" rel="apple-touch-icon" sizes="76x76">
<link href="apple-touch-icon-120x120.png" rel="apple-touch-icon" sizes="120x120">
<link href="apple-touch-icon-152x152.png" rel="apple-touch-icon" sizes="152x152">

For Android, when I ‘add bookmark’ and ‘add to home screen’, the favicon is used instead of the apple-touch-icon-precomposed.png as I was expecting, like this:

Am I missing something?

Kevin Suttle wrote on :

I’ve made a gist with the (what I think is) the latest syntax. Let me know if it needs updating.

<!-- For non-Retina iPhone, iPod Touch, and Android 2.1+ devices: -->
<link rel="apple-touch-icon-precomposed" href="apple-touch-icon-precomposed.png">

<!-- For the iPad mini and the first- and second-generation iPad on iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="apple-touch-icon-72x72-precomposed.png">

<!-- For the iPad mini and the first- and second-generation iPad on iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="76x76" href="apple-touch-icon-76x76-precomposed.png">

<!-- For iPhone with high-resolution Retina display running iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="apple-touch-icon-114x114-precomposed.png">

<!-- For iPhone with high-resolution Retina display running iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="120x120" href="apple-touch-icon-120x120-precomposed.png">

<!-- For iPad with high-resolution Retina display running iOS ≤ 6: -->
<link rel="apple-touch-icon-precomposed" sizes="144x144" href="apple-touch-icon-144x144-precomposed.png">

<!-- For iPad with high-resolution Retina display running iOS ≥ 7: -->
<link rel="apple-touch-icon-precomposed" sizes="152x152" href="apple-touch-icon-152x152-precomposed.png">

<!-- Chrome v31+ for Android -->
<link rel="icon" sizes="196x196" href="apple-touch-icon.png">

Benedikt wrote on :

@Kevin/Mathias: Shouldn't the last Android Icon be 192x192 and not 196x196? (XXXHDPI = 4x MDPI, so 4x48=192) See http://developer.android.com/design/style/iconography.html and http://iconhandbook.co.uk/reference/chart/android/

Xirux Nefer wrote on :

Even if only one icon will be used, aren’t all of them downloaded? I think that’s the reason why people just add the bigger one: it’s true that then also the less powerful devices will download it, but that’s better than downloading ALL of them to just use one. At least it happens with stylesheets they are all downloaded even if you use media queries in the media attribute, even if only one of them will be used. Would love to hear your opinion.

Mike wrote on :

Should we be using the <!-- Chrome v31+ for Android --> line in our sites? Can you add that line to your version, Mathias?

Paul Irish wrote on :

With the robust image selection tools now in sizes/srcset it feels like a great opportunity for Apple to clean up this mess. We could use a single <link> element.

Ken Casey wrote on :

Since updating to iOS 8 my icons are no longer working - anyone else seeing this issue?

Nem wrote on :

Ken: Same here. iOS 8 on iPhone 6 and the icons aren’t working for me, although I don’t have all the options described on this page defined in my document. Will try/test tonight.

dave wrote on :

Same here: they failed on my iPhone 5 running iOS 8. Then I got an iPhone 6 and they worked ’til the first reboot and now they’re gone again, it’s a real pain. Does anyone know what change in the code caused this?

This is the code I use, I don’t understand it by the way, it just worked :)

<link rel=apple-touch-icon href=http://www.weebly.com/uploads/1/2/6/3/12633714/9093919_orig.png>

SE wrote on :

I find this proprietary mess so lame. It would be easier to use one icon file and size, 192×192 now? Just add a few lines in .htaccess or httpd.conf as suggested in the article:

RewriteRule ^apple-touch-icon-144x144-precomposed.png$ icon-192x192.png [L]

RewriteRule ^touch-icon-192x192.png$ icon-192x192.png [L]

I use these just to clean my logs from the multiple requests for multiple sizes, no html tags, and can’t tell how it looks in smaller sizes, can someone try that and tell us?

Jeff wrote on :

Has anyone here had issues with their old icon being added to home screen after you have updated it? I am about to rename my image files to see if it clears the old ones out.

Kees wrote on :

But what should you do when the page is requested once and the icon is requested 5 times?

xx.xx.xx.xx - - [11/Dec/2014:13:42:52 +0000] "POST /pagename/ HTTP/1.1" 200 3281 "http://www.website.url/pagename/" "Mozilla/5.0
xx.xx.xx.xx - - [11/Dec/2014:13:42:57 +0000] "GET /img/icon/apple-touch-icon.png HTTP/1.1" 200 5441 "-" "Mozilla/5.0
xx.xx.xx.xx - - [11/Dec/2014:13:42:57 +0000] "GET /img/icon/apple-touch-icon.png HTTP/1.1" 200 5441 "-" "Mozilla/5.0
xx.xx.xx.xx - - [11/Dec/2014:13:42:57 +0000] "GET /img/icon/apple-touch-icon.png HTTP/1.1" 200 5441 "-" "Mozilla/5.0
xx.xx.xx.xx - - [11/Dec/2014:13:42:57 +0000] "GET /img/icon/apple-touch-icon.png HTTP/1.1" 200 5441 "-" "Mozilla/5.0
xx.xx.xx.xx - - [11/Dec/2014:13:42:57 +0000] "GET /img/icon/apple-touch-icon.png HTTP/1.1" 200 5441 "-" "Mozilla/5.0

The icon is on the correct path.

Tony Payne wrote on :

Thanks for this information, it’s very detailed and useful.

I have been wondering for ages why we keep getting all these apple-touch-icon messages in our server logs (hundreds most days) especially when our sites don’t define any.

I do have to wonder why Apple can’t just be happy with the good old favicon.ico like everything else and has to cause people a lot of extra work.

Joy McClanahan wrote on :

Mathias,

You appear to have a more general idea about how things should work so I hope you can help me. Suddenly the icons on my iPad Mini changed to black and white they have some type of geometric symbol on them — this is the best way I can describe them. Have you run across anything like this some of them remained with the original icon pics on them but mostly all black and white. They are very hard to work with. My screen is not black and white; everything else is fine.

Thanks, Joy

Luca wrote on :

I find it crazy to impose to desktop browser to make 20 extra HTTP requests to download these useless images!

Hence I leave them in the root without linking them in the HTML, iOS should be fine and hopefully Android (in 2015!) has also smartened up about this!

meesteridle wrote on :

I just do this:

cd /var/www
touch favicon.png
cd /var/www/example.com
ln -sf ../favicon.png apple-touch-icon.png
ln -sf ../favicon.png apple-touch-icon-precomposed.png
ln -sf ../favicon.png favicon.ico
ln -sf ../favicon.png favicon.png

Leave a comment

Comment on “Everything you always wanted to know about touch icons”

Your input will be parsed as Markdown.