BrowserUX Blog

Front-End Development

HTML JSON 📱 PWA 🧩 UX

Web Icons in 2025: Touch Icons, Adaptive Icons & manifest.json

Theme Light/Dark

In a web ecosystem that’s primarily accessed on mobile, the icons displayed when a site is added to the home screen take on major importance. Whether on iOS or Android, proper icon management helps maintain visual consistency, brand identity, and perceived quality. This guide is aimed at front-end developers, PWA creators, and designers focused on the mobile user experience.

I. Definitions

With the rise of smartphones and web apps, new types of icons have emerged to suit specific use cases: home screen shortcuts, fullscreen display, adaptive masking, and more. As a result, terms like Touch Icon, Adaptive Icon, and manifest.json can be confusing. Yet each plays a well-defined role in the modern mobile experience. Before we dive into formats and best practices, let’s clarify what these terms mean.

1. Touch Icon (Apple)

Touch Icons are the icons used when a user adds a website to their home screen from Safari on iOS. If no icon is specified, iOS attempts to generate one automatically, often with mediocre results.

2. Adaptive Icon (Android)

Adaptive Icons are Android app icons that can adapt to different mask shapes (round, square, teardrop) depending on the device model and launcher. They’re used when a site is added to the home screen from Chrome or another PWA-compatible browser.

3. Web App Manifest

The *.webmanifest file is a JSON file that describes the properties of a Progressive Web App (name, colors, display mode, icons, etc.). It’s essential for PWAs and controls which icons are used on Android.

II. Formats, Sizes, and Guidelines

1. Apple (iOS)

On iOS devices (iPhone, iPad), the Touch Icon is used when a user selects “Add to Home Screen” from Safari. It becomes the visual icon of your site, displayed alongside native apps, with similar behavior (label below, full-screen launch if configured).

This icon is also used in certain system views like Siri Suggestions, Spotlight search, or shortcut previews. It directly contributes to perceived quality and visual consistency on iOS. A missing, blurry, or poorly formatted icon can make your site seem neglected, while a crisp, well-designed Touch Icon gives your site a native app-like appearance.

  • Format: PNG
  • Recommended size: 180×180 px
  • Transparency: should be avoided, if the icon is transparent, iOS automatically adds a black background (unless the image already has a solid background)
  • Number of sizes: One is enough, unlike old practices specifying multiple sizes (76x76, 120x120, 152x152, etc.), iOS now automatically resizes a 180×180 px icon for all devices (iPhone, iPad, Retina…)

2. Android & Windows (Chrome, Edge, PWA)

On Android, a site’s icon is used when a user adds it to the home screen via Chrome, Edge, or another PWA-compatible browser. On Windows, it's used when a user installs the PWA via a browser (typically Edge); the icon then represents the app in the Start menu, taskbar, or system search results.

In both cases, the icon plays a crucial role in helping users recognize the app, just like a native app.

On Android, modern launchers often apply a mask (circular, teardrop, square), making a centered and well-prepared “maskable” icon essential. On Windows, no transformation is applied, but a properly sized icon is still key to sharp display.

  • Format: PNG
  • Recommended sizes: Minimum 192×192 px, 512×512 px for high-resolution icon
  • Transparency: supported, but include a background or respect a safe zone to avoid clipping on Android
  • Purpose: provide two versions, one “any” (universal fallback), and one “maskable” (for Android)
  • Declaration: via the *.webmanifest file, supported by Android and Windows (via Edge)

3. Classic vs. Maskable Icons

Android supports two types of icons in the *.webmanifest file: classic icons (purpose: "any") and maskable icons (purpose: "maskable"). These two variants serve complementary roles but are used differently depending on the Android version and the launcher.

Classic icon (any)

  • Used by default if no purpose is specified.
  • Displayed as-is, without any applied mask.
  • May be cropped or distorted if the launcher enforces a specific shape (circle, teardrop, etc.).
  • Compatible with older Android versions or non-standard launchers.

Maskable icon (maskable)

Since Android Oreo (8.0), Google introduced the concept of adaptive icons through the maskable format. This evolution addresses the diversity of Android devices and user interfaces. With this format, a single icon can adapt to various shapes imposed by launchers (circle, square, teardrop, etc.) while maintaining a clean and professional appearance.

This system ensures your web app appears correctly across all Android variations, avoiding unwanted visual cropping or inconsistent rendering. It complements classic icons (“any”), which are still useful for universal fallback.

  • Specifically designed to be used with shape masks applied by the system.
  • Only the safe central area (~72% of the image) is guaranteed to be visible; the rest may be masked.
  • Ensures a clean, controlled appearance on modern devices (Android 8+).
  • Recommended by Google for all PWAs.

Best practices

  • Provide both: “any” for compatibility, “maskable” for polished rendering on modern Android devices.
  • Design the maskable icon with centered content and a solid background to avoid unwanted cropping.
  • Test real-world display on various Android launchers, some apply more aggressive masking than others.

4. Legibility and Visual Hierarchy at Different Sizes

Not all icons scale well. A simple icon with a clear shape, few details, and good contrast will adapt easily to any size, from small 48×48 px shortcuts to large 512×512 px tiles.

But as soon as an icon includes more visual details, fine elements, embedded text, or multiple graphic layers, it can become difficult to read at small sizes. In such cases, it’s wise to provide different versions of the icon optimized for each size:

  • A simplified version for small sizes (e.g., 48×48 or 72×72 px), with secondary details removed or stylized.
  • A full version for larger sizes (192×192, 512×512 px), more faithful to the original design.

This “multi-level” approach is common in native app design, especially on Android. While it slightly increases the number of files to manage, it ensures readability and maintains visual consistency across devices.

Tip: If you follow this logic, make sure to name your files clearly (e.g., icon-simple-48.png, icon-detailed-512.png) and declare them properly in the manifest.webmanifest file with their respective sizes.

III. Icon Declaration: *.webmanifest File and <link> Tags

Proper icon management requires not only choosing the right formats and sizes but also integrating them correctly into your site’s code. This process relies on two complementary mechanisms:

  • The <link> tags in the HTML <head>, mainly used for iOS (and as a general fallback),
  • And the *.webmanifest file, which defines metadata for Progressive Web Apps, especially on Android and Windows.

In this section, we’ll look at how to properly structure the *.webmanifest file and how to declare icons in your HTML to ensure optimal compatibility across all platforms.

1. Structure of the *.webmanifest File

The manifest.webmanifest file is a JSON file placed at the root of your project (or in a publicly accessible folder) and linked within your HTML. It declares key properties of a PWA, such as its name, theme color, launch behavior, and, of course, its icons.

Android browsers (and Windows via Edge) use this file to determine which icon to display when a user installs or adds the site to their home screen. A clear and complete structure is therefore essential.

The *.webmanifest file can be named freely. Example: app.webmanifest.


{
    "name": "",
    "short_name": "",
    "description": "",
    "start_url": "/?utm_source=homescreen",
    "display": "standalone",
    "background_color": "",
    "theme_color": "",
    "icons": [
        {
            "src": "assets/icons/icon-192.png",
            "type": "image/png",
            "sizes": "192x192",
            "purpose": "any"
        },
        {
            "src": "assets/icons/icon-maskable-192.png",
            "type": "image/png",
            "sizes": "192x192",
            "purpose": "maskable"
        },
        {
            "src": "assets/icons/icon-512.png",
            "type": "image/png",
            "sizes": "512x512",
            "purpose": "any"
        },
        {
            "src": "assets/icons/icon-maskable-512.png",
            "type": "image/png",
            "sizes": "512x512",
            "purpose": "maskable"
        }
    ]
}
Key Description
"name" Full name of the application, shown in system menus or the multitasking screen. Example: “Blog BrowserUX”.
"short_name" Abbreviated name displayed under the icon on the home screen. Should remain short (max 10–12 characters).
"description" Optional description of the app. Useful for certain browsers or app stores.
"start_url" URL launched when the app is opened from the home screen. The utm_source parameter can be used to track this origin.
"display" Display mode of the PWA. "standalone" simulates a native app. Other options: "fullscreen", "minimal-ui", "browser".
"background_color" Background color shown at launch (splash screen). Should match the initial look of the site.
"theme_color" UI theme color. May affect the Android status bar and other system interfaces.

icons key (icon array)

Defines the icons used on Android and Windows home screens, as well as in some launchers. In this example, four icons are defined at 192×192 and 512×512 px, in two versions: any and maskable.

Key Description
src Relative or absolute path to the image file (e.g., assets/icons/icon-192.png).
type MIME type of the image. The most common is "image/png".
sizes Exact dimensions of the image, expressed in pixels in the format "192x192", "512x512", etc.
purpose Indicates the intended use of the icon. Possible values are:
  • - any: classic icon (default fallback).
  • - maskable: adaptive icon compatible with Android masks.

2. Inserting <link> Tags in the HTML <head>

For browsers to correctly detect and use a website's icons, they must be declared in the HTML header using <link> tags. These tags explicitly define which icons should be used in various contexts: home screen, bookmarks, Apple systems, and more.


<!-- Touch Icon for iOS -->
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

<!-- Manifest for Android and Windows -->
<link rel="manifest" href="/app.webmanifest">

Important notes:

  • For iOS, the apple-touch-icon tag is the only recognized way to specify the home screen icon. If it’s missing, Safari will attempt to generate one automatically, often with poor visual results.
  • For Android and Edge (Windows), the manifest.webmanifest file is required to define the PWA’s behavior (icons, colors, name, etc.).

Best practices:

  • Use a single apple-touch-icon tag with a 180×180 px image. There’s no need to define multiple sizes as in the past (unless you use multi-level icon versions).
  • Ensure the paths point to publicly accessible files (not blocked by cache rules or security settings).
  • Test the behavior on both iOS and Android after adding the icons.

IV. Conclusion

Mobile icons play an essential role in the perceived quality of your site on smartphones and tablets. In 2025, good icon management involves properly sized images, correctly placed, and adapted to the constraints of each platform. With a well-structured manifest.json and a few key <link> tags, you can deliver a consistent and professional experience on any device.

The Complete Guide

Logo browserux.css

browserux.css is a base CSS file designed as a modern alternative to classic resets and Normalize.css, focused on user experience and accessibility. It lays accessible, consistent foundations adapted to today's web usage: browserux.css

Logo BrowserUX Theme Switcher

BrowserUX Theme Switcher is a lightweight, accessible, and customizable Web Component designed to easily add a theme switcher button to any website or application: BrowserUX Theme Switcher

About

This blog was designed as a natural extension of the BrowserUX ecosystem projects.

Its goal is to provide complementary resources, focused tips, and detailed explanations around the technical choices, best practices, and accessibility principles that structure these tools.

Each article or tip sheds light on a specific aspect of modern front-end (CSS, accessibility, UX, performance…), with a clear intention: to explain the “why” behind each rule to encourage more thoughtful and sustainable integration in your projects.