June 25, 2026 · 6 min read

Configuración de favicon para React y Next.js que realmente funciona en 2026 | genfavicon.org

Last month I onboarded a junior dev who'd been working on a Next.js dashboard for three weeks. The app was polished — dark mode, i18n, Server Components. But the favicon was still the Vercel triangle. He'd added a favicon.ico to the /public folder and called it done. Chrome showed it. Safari didn't. Firefox showed it on some pages but not others. The PWA manifest was pointing to a 404.

This happens in roughly two-thirds of the React projects I review. Favicons are deceptively simple — drop a file in a folder, right? — but the combination of browser caching, manifest files, and Apple's specific requirements creates a minefield of silent failures. After fixing this pattern for the dozenth time, I built a checklist. Here it is.

Why favicon.ico Alone Isn't Enough Anymore

In 2012, one favicon.ico in the root folder covered every browser. That world is gone. Today you need at minimum: a 32px ICO for legacy browsers, a 180px PNG for Apple Touch, a 192px and 512px PNG for the Web App Manifest, and an SVG for modern browsers that support it. That's five files minimum.

The Chrome team announced SVG favicon support in Chrome 80, and it's been the default recommendation ever since. But Safari took years to follow, and plenty of enterprise environments still lock users to older versions. You can't ship SVG-only yet.

The Three Silent Failures I See in Every Other PR

I keep a running tally of favicon bugs I encounter in code reviews. These three account for maybe 80% of all issues:

1. The Apple Touch Icon 404. iOS Safari doesn't fall back to favicon.ico when adding a site to the home screen. It specifically looks for apple-touch-icon.png. If that file is missing, the user gets a gray placeholder — and most developers never test on a real iPhone, so they never see it.

2. Cache-invincible old favicons. Browsers cache favicons aggressively — sometimes for months. Update your favicon and deploy? Half your users still see the old one. The fix is cache-busting via a query string in the <link> tag: href="/favicon.ico?v=2". I bump this version on every deploy that touches static assets.

3. Manifest mismatch. The manifest.json specifies icons at specific sizes (usually 192x192 and 512x512). If those files don't exist at exactly those dimensions, the PWA install prompt silently degrades on Android. Chrome DevTools won't flag it unless you open the Application panel and check the Manifest tab manually.

The Next.js-Specific Traps

Next.js 14 and 15 introduced the Metadata API, which is genuinely great — but it has sharp edges for favicons specifically:

My rule for Next.js projects: pick one approach and commit. Either use the Metadata API and delete favicon.ico from /public, or skip the Metadata icons config entirely and use a <link>-based setup in layout.tsx. Mixing the two is where bugs breed.

My Production Checklist (Copy This Into Your PR Template)

I pasted this into our team's Notion after the third time I caught a favicon bug in production:

  1. favicon.ico exists at /public/favicon.ico (32x32, literal .ico format, not renamed .png)
  2. favicon.svg exists at /public/favicon.svg (for Chrome/Firefox modern)
  3. apple-touch-icon.png exists at /public/apple-touch-icon.png (180x180)
  4. manifest.json references both 192x192 and 512x512 PNGs that actually exist
  5. Cache-bust query string on every favicon <link> href
  6. Test on a real iPhone — add to home screen, verify the icon appears (Simulator counts)
  7. Chrome DevTools → Application → Manifest — zero red errors

I've found genfavicon's generator outputs all six sizes in one click, which replaced the ImageMagick one-liner I used to keep in my bash history. But regardless of how you generate them, the checklist is the part that matters.

David Kim Written by David Kim — Frontend Developer & WordPress Specialist. I've built and audited favicons for 40+ production sites. More about me →