Artifacts: viewer page no longer serves the per-artifact emoji favicon (regression) — every artifact tab shows claude.ai/favicon.ico

Status Open
Maintainer reply None cached
Activity 1 comment · opened Sep 10, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

This is a claude.ai Artifacts (web product) bug, not a Claude Code CLI bug. Filing here as there is no separate public tracker.

The artifact viewer page at https://claude.ai/code/artifact/<id> used to emit a per-artifact favicon rendered from the artifact's emoji, giving each artifact a distinct browser-tab icon. It now emits no <link rel="icon"> at all, so Chrome falls back to https://claude.ai/favicon.ico and every artifact tab is visually identical. Users with several artifacts open or pinned can no longer tell them apart.

The emoji itself is still stored and still correct — it renders on the gallery card. Only the viewer page's favicon is missing. Republishing does not help; clearing the browser cache does not help (correctly, since the page genuinely serves no icon).

What Should Happen?

Opening an artifact whose favicon is 🔎 should give that tab a 🔎-derived icon, as it previously did. Two artifacts published with different emoji should have visibly different tab icons.

Error Messages/Logs

No errors — the icon link is simply absent. Evidence from a signed-in session:

1) No icon link in the SERVER-RENDERED HTML:

    const raw = await fetch(location.pathname).then(r => r.text());
    raw.match(/<link[^>]*icon[^>]*>/gi)      // -> null
    raw.match(/<title[^>]*>([^<]*)</i)[1]    // -> "Claude Artifact"

2) No icon link in the HYDRATED DOM either, sampled at +3.5s, +7s and +9.5s after load:

    [...document.querySelectorAll('link')]
      .filter(l => /icon/i.test(l.getAttribute('rel')||'')).length   // -> 0
    document.title                                                    // -> "Account Lookup"

   Note the SPA DOES set document.title per artifact. It just never sets an icon.
   That asymmetry may point at where it broke.

3) IT USED TO WORK — Chrome's own favicon database still holds the old icons.
   From ~/Library/Application Support/Google/Chrome/<Profile>/Favicons:

     icon recorded for the page URL          | distinct artifact URLs
     ----------------------------------------|-----------------------
     per-artifact data:image/png;base64,...  |  6
     https://claude.ai/favicon.ico           |  8

   The six data: icons decode to RENDERED EMOJI PNGs (16px and 32px) — confirmed
   visually as 📐, 🛡️📊 and 🛡️, matching the emoji those artifacts were published
   with. The eight generic ones are all artifacts loaded recently. So the platform
   previously served an emoji-derived data:image/png favicon and stopped; Chrome has
   both eras stored side by side.

Steps to Reproduce

  1. Publish two artifacts with different emoji favicons, e.g. 🔎 and 🔳.
  2. Open both at https://claude.ai/code/artifact/<id> in Chrome.
  3. Observe both tabs show the generic Claude icon rather than icons derived from 🔎 and 🔳.
  4. View source / inspect: there is no <link rel="icon"> in either the server HTML or the hydrated DOM.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

n/a — claude.ai web product (Artifacts), reported from Claude Code in the desktop app

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Why the artifact itself cannot work around this: the artifact renders inside an <iframe> pointing at https://<artifact-id>.frame.claudeusercontent.com/_f/<token>, and a browser takes the tab icon from the top-level document only — the iframe's own <link rel="icon"> is inert. That frame origin is not a usable workaround either: requesting it without the token path returns not found, and the tokenised URL carries session data, so it cannot be bookmarked or pinned.

Environment: Chrome 153.0.8010.37 on macOS 26.6.2, signed in, reproduced across multiple Chrome profiles. Two artifacts owned by the reporter, favicons 🔎 and 🔳.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗