apple-touch-icon: The Size, the Safe Area, and What iOS Does

Someone adds your site to their iPhone home screen and sends you a screenshot. Your logo is sitting inside a black box, the corners look wrong, and the label underneath says something like “Acme | Project Management Software for Teams” truncated to eleven characters.

Every part of that is fixable and none of it is obvious from the markup, because iOS does not render your icon so much as process it. It takes the square PNG you gave it, flattens transparency onto black, applies its own corner mask, and caches the result so thoroughly that replacing the file on your server changes nothing for anyone who already added the shortcut.

The good news on apple touch icon size: the answer is one file. Not eight, not the ten-line block a 2014 generator handed you. One 180 by 180 pixel PNG named apple-touch-icon.png, sitting at your site root.

What follows is about what happens to that file after you ship it.

The short answer

Put a single 180 by 180 PNG at your site root, named apple-touch-icon.png, and add one link tag:

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

180 pixels covers the largest current iPhone requirement, and iOS downscales it cleanly for iPad and every smaller slot. Give it an opaque background, because iOS composites transparency onto black and a logo on a transparent canvas will look like it fell into a hole. Leave the corners square: iOS applies its own rounded mask, and pre-rounding leaves gaps that go black. Keep meaningful artwork inside roughly the central 80 percent of the square, which is 144 pixels of your 180, so nothing important sits where the mask cuts.

Skip apple-touch-icon-precomposed entirely. It exists to opt out of a glossy overlay that iOS stopped applying in iOS 7.

Why 180, and why one file

iOS asks for icons in points, not pixels, and multiplies by the device’s scale factor. The iPhone home screen slot is 60 points, and on a 3x display that is 180 pixels. iPad works in 76 and 83.5 point slots at 2x, giving 152 and 167 pixels.

You could ship all three. The old generators shipped ten, covering devices going back to the original iPhone at 57 pixels. I would not do either, and here is the reasoning rather than just the recommendation.

iOS downscales a larger icon to fill a smaller slot, and it does so with decent resampling. The visual difference between a purpose-built 152 pixel export and a 180 pixel file scaled down to 152 is, at the size a home screen icon is actually viewed, close to nothing. The cost of shipping ten files is ten things to regenerate at the next rebrand, ten opportunities for one of them to go stale, and ten lines of head markup that nobody will ever audit.

If you have a specific reason to control the iPad rendering precisely, add 152 and 167 with sizes attributes and accept the maintenance. For almost every site, one file is the correct engineering trade.

Design the source larger than 180 regardless. Start from a 1024 pixel square, because you will want that same source for the manifest’s 512 pixel icon anyway, and downscale once at export. Image Resizer will do the 1024 to 180 step in your browser if you do not want to open a design app for it.

The transparency trap

This is the single most common apple-touch-icon defect, and it produces the black box in the screenshot at the top of this article.

iOS does not preserve alpha in a home screen icon. Transparent pixels get composited onto black. A logotype exported with a transparent background, which is how most brand assets are stored, becomes white-on-black or, worse, dark-navy-on-black, which reads as an empty tile.

So flatten it. Not onto white by default: onto a colour you chose. A brand-coloured tile with a white mark on it usually looks better on a home screen than a white tile, because home screens are busy and a white square disappears against light wallpaper while a saturated one holds its position. Pull the exact hex from your brand sheet with Color Picker rather than eyeballing it.

One nuance worth knowing: this behaviour is specific to the apple-touch-icon path. Your rel="icon" favicons keep their transparency fine, and Android’s manifest icons keep theirs too, subject to masking. So the same source PNG can be correct in one place and broken in another, which is why “it looks fine in my tab” is not evidence about the home screen.

The mask, the corners, and the safe area

iOS applies a rounded-square mask to every home screen icon, native or web. The shape is a continuous curve rather than a simple rounded rectangle, and the corner radius is a meaningful fraction of the icon width, in the region of 22 percent.

Two consequences.

Do not pre-round your own corners. If you supply an image that is already rounded, with transparency in the corner gaps, iOS composites those gaps onto black and then applies its own mask on top. You get a dark halo tracing the outside of your shape. Supply a full square, edge to edge, with square corners.

Keep meaningful content inside a central safe zone. The working number is about 80 percent of the width. On a 180 pixel icon that is a 144 pixel square, leaving an 18 pixel margin on every side. Anything in that margin is at risk: the corners are certainly cut, and the edges sit close enough to the boundary that they read as cramped even when they survive.

That 80 percent figure is the same rule Android uses for maskable icons, for the same underlying reason, which is that the platform picks the shape and your artwork has to be agnostic to it. Android’s version of this is stricter and better documented, and it is worth reading the manifest and maskable icons breakdown alongside this, because if you get the Android safe zone right you have automatically got the iOS one right.

Apple’s own interface guidance changes between OS releases. Check Apple’s current developer documentation before you build anything that depends on the exact radius, and treat the 80 percent safe zone as the durable rule rather than the geometry.

The head block worth shipping

Here is the whole iOS-relevant set, in context:

<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="icon" href="/icon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">

<meta name="apple-mobile-web-app-title" content="Acme">
<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">

apple-mobile-web-app-title is the label under the icon. Without it, iOS uses your page title, which is why home screens end up showing truncated SEO titles. Keep it short. Twelve characters or fewer survives without an ellipsis on most devices, and you should test rather than trust that number.

apple-mobile-web-app-capable makes the shortcut open without Safari chrome. Newer Safari versions also read display from the web app manifest for this, and the two overlap, so declaring both is the pragmatic move.

apple-mobile-web-app-status-bar-style takes default, black or black-translucent. The translucent option lets your content run under the status bar, which looks good and requires you to handle the safe area insets in CSS or your header will sit under the clock.

One more thing about the href. iOS will look for /apple-touch-icon.png and /apple-touch-icon-precomposed.png at your site root by convention even with no link tag at all, which is a genuinely useful property. It means putting the file at the root is worth doing even when you also declare it explicitly, and it means a stale file at that path can override the tag you thought was in charge. If your icon is wrong and you cannot work out why, check what is at the root path.

apple-touch-icon-precomposed and its dead history

Before iOS 7, iOS applied a glossy highlight to home screen icons automatically: a curved shine across the top half that made everything look like a jelly sweet. Designers hated it. The -precomposed filename was the opt-out, telling iOS the icon was already composed and to leave it alone.

iOS 7 flattened the whole visual language and dropped the gloss for everyone. Since then, apple-touch-icon.png and apple-touch-icon-precomposed.png do the same thing.

Generators still emit both. You can safely ship only the plain one. If you inherit a codebase with both, deleting the precomposed file and its tag is a free cleanup, with the small caveat that anyone running a device old enough to care is running a device old enough that your site probably does not render anyway.

Why iOS will not update your icon

You changed the file, purged the CDN, verified the new PNG loads at the URL, and the icon on your test iPhone has not moved. This is the second most common support question in this whole area and the answer is unsatisfying.

An iOS home screen shortcut stores the icon it was created with. It is a snapshot, not a live reference. Replacing the file on your server does not reach back into shortcuts that already exist. Every user who added your site before the change keeps the old icon until they remove and re-add it, and there is no mechanism for you to push an update.

For your own testing, the reliable sequence is: delete the shortcut, clear Safari website data for your domain in Settings, force-quit Safari, reload the page, then add to home screen again. Skipping the website data step is why people conclude the fix did not work.

Because the icon cannot be updated in place, the practical advice is to get it right before you promote the feature, and to accept that a rebrand will leave old icons on some devices indefinitely. That is not a bug you can fix. It is a property of the platform.

Building the file from a single clean source is the way to avoid needing a second attempt. The Favicon Generator takes one square image, flattens it onto a background colour you pick, exports the 180 pixel PNG along with the ICO, the SVG and the manifest icons, and writes out the head block. Everything runs in your browser, so an unannounced logo never leaves your laptop, and the whole set stays consistent instead of drifting file by file.

What each surface actually reads

The confusion in this area comes from treating “the icon” as one thing. It is at least five things, each read by a different consumer.

Android is the interesting contrast. It reads the manifest, applies an adaptive icon mask to entries marked maskable, and for non-maskable icons it will typically place your artwork on a generated background rather than composite it onto black. Different rule, same design constraint: keep the important part in the middle.

Older Chrome on Android would fall back to apple-touch-icon when no manifest icon was available, which is a nice safety net and not something to rely on.

Building and testing it, step by step

1. Start from a square source at 1024 by 1024, in whatever tool your logo lives in. Vector source is better if you have it.
2. Flatten onto an opaque background. Choose the colour deliberately; brand colour usually beats white.
3. Scale the artwork so everything meaningful sits within the central 80 percent. At 1024 that is an 819 pixel square, leaving a 102 pixel margin on each side.
4. Leave the outer corners square. No rounding, no border, no drop shadow.
5. Export at 180 by 180 as PNG. If the file lands above roughly 20 KB, run it through Image Compressor; a flat-colour icon should compress hard.
6. Name it apple-touch-icon.png and put it at the site root, then add the link tag anyway.
7. Confirm it is served: curl -sI https://example.com/apple-touch-icon.png should return 200 and Content-Type: image/png.
8. On an iPhone, open the site in Safari, tap Share, then Add to Home Screen. Check the preview in that sheet before you confirm, because it shows you the masked result.
9. Look at the label. If it is your full SEO title, add apple-mobile-web-app-title.
10. To test a change, delete the shortcut, clear Safari website data for the domain, then repeat from step 8.

Step 8 is not optional and cannot be simulated properly. The iOS Simulator gets you close, browser device emulation does not get you close at all, and neither shows you the real rendering against a real wallpaper.

What goes wrong

Say Tomas ships a recipe site. His logo is a horizontal wordmark, “SALT”, set in a heavy sans, dark charcoal on transparent. He exports it at 180 by 180 with the wordmark spanning 168 pixels of the width, adds the tag, and adds the site to his home screen.

What he sees: the wordmark’s outer letters clipped, sitting on black, with the charcoal type nearly invisible against it.

Three separate faults, and it is worth separating them because each has its own fix.

Transparency is fault one. Charcoal on transparent becomes charcoal on black, which computes to almost no contrast. He flattens onto his brand’s warm off-white.

Fault two is the safe area. At 168 pixels wide on a 180 pixel canvas, the wordmark leaves 6 pixels of margin per side. The safe zone allows 18. With a mask corner radius around 22 percent of 180, roughly 40 pixels, the corners are cut well inside where his letterforms sit, so the S and the final T lose their outer edges. He rebuilds with the mark at 132 pixels wide, centred, which sits comfortably inside the 144 pixel safe square.

The third fault is the concept, not the execution. A four-letter wordmark at 180 pixels is legible, but on a home screen it is competing with app icons that are almost universally a single symbol. He drops to a single “S” in the same weight, at about 96 pixels tall, on the warm off-white tile. It reads from arm’s length, which is the only test that matters.

Then he deletes the shortcut, clears website data, re-adds, and it is right.

The thing I would flag beyond that example: check your icon against a photographic wallpaper, not against the default gradient. A pale tile that looks clean on Apple’s stock background can vanish over a bright photo, and roughly nobody uses the stock background.

How this fits with the rest of your icon set

Your touch icon is one file in a set of four, and shipping it alone leaves gaps. A root favicon.ico covers browser tabs and the requests browsers make by convention with no tag at all. An SVG covers modern desktop browsers and can flip colours with the system theme. The manifest covers Android install prompts. Each surface reads a different declaration and none of them substitutes for another, which is the argument laid out in full in what to actually ship in 2026.

Two of those files can share a source image with the touch icon, and two cannot. The 192 and 512 pixel manifest PNGs come from the same 1024 square, usually with the same opaque background if you are marking them maskable. The 16 and 32 pixel raster sizes generally should not: at that scale a design that works at 180 pixels is too detailed, and you are better off with a simplified variant. Building both from one generator run keeps them visually related without pretending they are the same drawing.

If you would rather not manage four exports by hand, ToolFiddle’s icon builder produces the whole set from one upload and writes the matching head block, all client-side.

Frequently asked questions

What size should an apple-touch-icon be?

Ship one 180 by 180 pixel PNG. That matches the largest current iPhone requirement, 60 points at a 3x scale factor, and iOS downscales it cleanly for every smaller slot including iPad’s 152 and 167 pixel sizes. The old matrix of eight or ten sizes existed for devices that are long retired and is not worth the extra files or the extra link tags today.

Why does my iOS home screen icon have a black background?

iOS composites transparent areas of an apple-touch-icon onto black rather than preserving them. A logo exported on a transparent canvas therefore appears trapped in a dark square, and a dark logo on transparent becomes almost invisible. Flatten the PNG onto an opaque background colour before you export, and pick that colour deliberately rather than defaulting to white.

Do I need apple-touch-icon-precomposed?

No. Before iOS 7, iOS added a glossy highlight overlay to home screen icons, and the precomposed variant existed to opt out of it. iOS 7 removed the gloss entirely, so both filenames now behave identically on every supported device. Shipping the precomposed file adds a request and a tag for no benefit, and deleting it from an old codebase is a free cleanup.

Why will my apple-touch-icon not update on iPhone?

iOS caches home screen icons very aggressively, and an existing shortcut keeps the icon it was created with even after you replace the file on the server. The only reliable refresh is deleting the shortcut and adding it again. Clearing Safari website data for the domain first helps if the new icon still does not appear, and there is no way to push an update to other people’s devices.

Does iOS use my web app manifest icons?

Historically iOS preferred apple-touch-icon and ignored the manifest icons array for home screen shortcuts. Safari has gained more manifest support over time and the exact behaviour varies by iOS version, so declare both and do not assume one covers the other. The apple-touch-icon link is the one that has worked consistently across the widest range of releases.

Should I round the corners of my apple-touch-icon myself?

No. iOS applies its own rounded mask to whatever square image you supply, so pre-rounded corners leave transparent gaps that get composited onto black and produce a dark halo around your shape. Supply a full square with square corners, edge to edge, and keep meaningful artwork inside roughly the central 80 percent so the mask never cuts anything you care about.

The part worth remembering

One file, 180 by 180, opaque, square corners, artwork inside the middle 144 pixels. That is the whole specification, and it took several sections of platform behaviour to explain why each of those four constraints exists.

The part to internalise is that iOS is doing the compositing and the masking, not you. Every instinct that says “I will handle the rounding myself” or “I will keep the background transparent for flexibility” produces a worse result, because you are fighting a process that runs after your file leaves your hands.

Get it right before you tell anyone to add the site to their home screen. Shortcuts keep the icon they were created with, permanently, with no mechanism for you to push an update. That is unusual on the web and it is the one detail here with a cost you cannot claw back.