If you want your site to look polished when someone saves it to an iPhone or iPad home screen, you need more than a standard favicon. Apple touch icons have their own sizing, placement, and implementation habits, and they are easy to get almost right while still ending up with a blurry, cropped, or missing result. This guide gives you a practical reference for choosing an apple touch icon size, naming files sensibly, adding the right apple touch icon HTML, and avoiding the common mistakes that make an iPhone home screen icon look off-brand.
Overview
This section gives you the short version first: what an Apple touch icon is, how it differs from a favicon, and what matters most in day-to-day implementation.
An apple touch icon is the image iOS may use when a user adds a website to the home screen. It is separate from the small favicon used in browser tabs, bookmarks, and address bars. In practice, many sites need both: a favicon set for browsers and platform support, and a larger touch icon for iPhone and iPad home screen use.
The key difference is context. A favicon is often tiny and optimized for 16x16, 32x32, or browser-specific use. An iPhone home screen icon is much larger and is viewed as an app-like tile. That means your design priorities change. Fine details that work in a tab icon may fail badly on a home screen. Small text, thin outlines, and crowded logos are the usual problems.
If you only remember five rules, use these:
- Provide a dedicated PNG touch icon instead of relying on your regular favicon files.
- Start with a large square source image so the asset stays useful if recommendations change.
- Use simple, centered artwork with generous padding.
- Add an explicit
<link rel="apple-touch-icon" ...>tag in the document head. - Test on a real iPhone or iPad after deployment, because icon caching can hide mistakes.
For teams already maintaining a broader icon stack, it helps to treat touch icons as one part of a complete site asset system. If you need a wider reference beyond Apple-specific implementation, the broader favicon size guide is the right companion page.
One more useful framing: Apple touch icons sit at the intersection of usability and visual identity. They are small brand assets, but they are also functional UI elements. The best result is usually not your full logo pasted into a square. It is a version of your brand mark designed to survive being seen at a glance.
Core framework
This section gives you a durable framework you can reuse whenever iOS behavior, recommended sizes, or HTML conventions shift.
1) Understand the job of the icon
An ios web clip icon should behave more like an app icon than a browser tab icon. That means it needs:
- A square composition
- Clear subject separation
- Strong contrast
- Minimal detail
- No dependence on tiny text
If your current favicon is a wordmark, a complex mascot, or a full badge, it may not be the right source for the home screen. A simplified monogram, symbol, or isolated brand mark is usually a better choice.
2) Choose a practical source size
Because platform conventions can evolve, the safest workflow is to design from a larger master file and export down. Many teams keep a 1024x1024 or similarly high-resolution square source asset for this purpose. You may not serve that exact file directly, but it gives you room to generate crisp outputs without redesigning every time.
When people search for apple touch icon size, what they usually want is a single reliable answer. The evergreen answer is this: provide at least one high-quality square PNG specifically intended for Apple home screen use, and generate it from a large source. If your workflow supports multiple exports, keeping a dedicated 180x180 PNG is a common practical choice, but the larger design source matters more than memorizing one dimension in isolation.
For a site already maintaining a full cross-platform set, pair touch icon work with your standard favicon outputs. If you need help deciding file formats elsewhere in the stack, see SVG vs PNG vs ICO favicons.
3) Use PNG for the touch icon
For Apple touch icons, PNG is the straightforward default. It is predictable, broadly supported for raster imagery, and easy to export cleanly. Unlike a traditional .ico file, a PNG is simple to inspect and easier to manage in modern design and build workflows.
This also keeps your implementation clean: use ICO where it makes sense for traditional favicon compatibility, and use PNG for the Apple touch icon.
4) Name files clearly, not creatively
File naming does not need to be clever. It needs to be maintainable. A strong convention looks like this:
apple-touch-icon.pngapple-touch-icon-180x180.png
If your site only ships one Apple touch icon file, apple-touch-icon.png is simple and readable. If your build process exports multiple variants, including size in the filename can reduce confusion.
The useful rule is consistency. Your designers, developers, CMS users, and deployment scripts should all be able to identify the intended file without opening it.
5) Add explicit apple touch icon HTML
Do not assume discovery will happen the way you expect. Add the HTML link tag directly in the page head:
<link rel="apple-touch-icon" href="/apple-touch-icon.png">If you are serving a specific dimensioned file, that can be equally clear:
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon-180x180.png">This is the simplest and most readable form of apple touch icon html for most sites. Keep the path absolute from the site root when possible, especially if your templates, subdirectories, or framework routes make relative paths unreliable.
6) Design for safe edges
Even when the source image is technically correct, visual cropping can still make an icon feel cramped. A practical design rule is to keep the main mark away from the outer edge. Think in terms of a safe zone. Leave enough padding that rounded masking, scaling, or visual compression does not damage the logo.
This matters especially for:
- Circular logos placed inside a square
- Lettermarks with tall ascenders or descenders
- Thin strokes near the border
- Icons with shadows or glows that disappear on light backgrounds
If you have already worked through simplifying a small icon from a complex logo, the design thinking is similar to what is covered in how to create a favicon from a logo, just at a larger home screen scale.
7) Test the full path, not just the file
A valid PNG on your local machine does not guarantee a working result on iOS. Test these points together:
- The file loads directly in the browser
- The HTML head contains the expected tag
- The deployed page source matches your template changes
- Your CDN or cache is not serving an old asset
- The icon appears correctly when added to the home screen
If the image refuses to update, you may be dealing with a cache issue rather than an image problem. In those cases, the workflow in Favicon Not Showing? A Troubleshooting Checklist is useful even though the symptom is on mobile.
Practical examples
This section shows what good implementation looks like in common real-world situations.
Example 1: Personal site or portfolio
A developer portfolio often uses a full name wordmark in the header and a tiny initial-based favicon in browser tabs. For the Apple touch icon, the strongest option is usually a simplified monogram on a solid background.
A clean setup might be:
- Source asset: 1024x1024 square design file
- Exported file:
/apple-touch-icon.png - Markup:
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
This approach works well because it decouples the home screen icon from the full site logo. The result is more legible and feels intentional rather than auto-generated.
Example 2: SaaS or internal tool dashboard
A software product often already has a full icon system managed by design or front-end teams. In that case, treat the touch icon as part of your standard brand asset export process.
A practical pattern is:
- Maintain a master icon source in the design system
- Export touch icon PNGs during the build or release process
- Reference the asset from the root path in the app shell or HTML template
This is especially helpful when the site spans marketing pages, app routes, and documentation. One canonical touch icon file reduces drift across environments.
Example 3: CMS-based site
On WordPress, Shopify, Wix, Squarespace, or Webflow, the challenge is often less about design and more about where to place the file and how the platform injects head tags. If the CMS has a dedicated site icon setting, verify whether it covers Apple home screen behavior the way you need. If it does not, add a custom head tag or theme-level asset reference where supported.
If you are handling platform-specific implementation, this companion guide is useful: How to Add a Favicon in WordPress, Shopify, Wix, Squarespace, and Webflow.
Example 4: Static site or framework app
For a static site, Next.js app, Astro build, or similar framework project, keep the touch icon in the public or static asset directory and reference it from the head template. The simpler the path, the easier it is to reason about in deployment.
For example:
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon-180x180.png">Then verify after deployment that the file is accessible at that exact URL, not rewritten behind a hashed asset path unless your framework manages it predictably.
Example 5: Brand refresh or redesign
When a visual identity changes, teams often update logos, favicons, and social assets but forget the touch icon. Users who save your site to the home screen can keep seeing an outdated symbol for longer than expected because of caching and old homescreen entries.
A sensible refresh process includes:
- Export a new touch icon from the updated brand source
- Replace the file or version the filename intentionally
- Update the head tag if the filename changed
- Test on a real iPhone after cache propagation
If you are regenerating your full icon stack at the same time, a dedicated favicon generator can save time, but always inspect the touch icon output manually. Generator convenience should not replace design review.
Common mistakes
This section highlights the issues that cause most poor results, even on otherwise well-built sites.
Using the favicon as the touch icon
A browser favicon and an iOS home screen icon solve different problems. Reusing the exact same tiny artwork usually leads to soft edges, cramped composition, or visual noise. The touch icon deserves its own design pass, even if it is based on the same core mark.
Including too much detail
Small internal lines, full wordmarks, and subtle gradients often disappear or become muddy. If the icon needs explanation, it is too complicated. A touch icon should be instantly recognizable from shape and color alone.
Forgetting padding
Logos pushed too close to the border can look amateurish once displayed on a home screen. Build in breathing room around the main mark. In many cases, adding more empty space improves perceived sharpness.
Using the wrong file path
Many broken implementations come down to a file path issue, especially on framework sites, CMS themes, or CDN-backed deployments. Always open the image URL directly in the browser to verify it resolves where the HTML says it does.
Trusting defaults without checking output
Some site builders and plugins generate icons automatically. Sometimes that is enough, and sometimes it produces an awkward crop or low-quality export. The safe approach is to inspect the generated file and then test the saved home screen icon on a device.
Ignoring caching during troubleshooting
Icons often appear to be “stuck” after you upload a replacement. Before redesigning the asset from scratch, check browser caching, device caching, CMS theme caching, and CDN propagation. The image may be correct while the old one is still being served.
Not aligning the icon with the rest of the brand system
Your touch icon should feel related to your favicon, app icon, social avatar, and general visual identity. It does not need to be identical, but it should not look like a separate brand. Consistency matters, especially for creators, products, and developer tools that appear across multiple contexts.
When to revisit
This section helps you decide when your Apple touch icon setup should be reviewed, updated, or regenerated.
The best time to revisit your touch icon is not only when something breaks. It is whenever the surrounding system changes. A good maintenance rhythm is to review it during any update to branding, platform support, or deployment workflow.
Revisit your setup when:
- You redesign your logo or simplify your visual identity
- You change site generators, CMS themes, or front-end frameworks
- You rebuild your favicon stack or adopt a new favicon generator
- You notice mismatch between tab favicon, touch icon, and app-like branding
- Users report a missing or outdated icon on iPhone or iPad
- Apple device behavior, recommended sizes, or web app conventions appear to shift
A practical review checklist looks like this:
- Open your current touch icon file and assess legibility at a glance.
- Confirm the HTML head still includes the intended
apple-touch-iconlink. - Verify the live file path works in production.
- Test add-to-home-screen behavior on at least one current iPhone or iPad.
- Compare the icon against your current favicon and brand assets for consistency.
- Regenerate the file from the master design if it feels dated or cramped.
If you are doing a broader icon maintenance pass, keep this guide next to your general references for favicon formats, sizes, and platform behavior. The most useful mindset is to treat your apple touch icon as a maintained asset, not a one-time upload.
For many teams, that means keeping a small internal note with three items: the master source file location, the exported production filename, and the exact head tag used in templates. That tiny bit of documentation prevents the usual confusion six months later.
Final recommendation: if you only make one improvement today, create a dedicated square PNG touch icon from a large source file, give it a clear root-level filename, add an explicit HTML tag, and test it on a real device. That covers most of what actually matters and gives you a clean baseline to update whenever iOS behavior or your brand system changes.