WordPress Admin Favicon not updating

WordPress admin favicon not updating is usually caused by one of a few very different problems: browser caching, an incorrect favicon URL, missing admin-head output, competing favicon tags or confusion between the admin favicon and the WordPress Site Icon.

The difficult part is that all of these problems can produce almost the same visible result:

You select a new favicon
↓
reload wp-admin
↓
the old icon is still there

That does not automatically mean WordPress failed to save the setting.

It also does not automatically mean the plugin or custom code responsible for the favicon is broken.

Favicons sit at the intersection of:

• WordPress settings;
• HTML head markup;
• Media Library URLs;
• browser caching;
• HTTP caching;
• WordPress Site Icon behavior;
• plugins and themes that may output additional icon tags.

The correct troubleshooting process is therefore to identify which layer is stale or incorrect before changing anything.

This guide explains how to diagnose a WordPress admin favicon that is not updating, how to inspect the actual favicon markup, how to separate browser caching from WordPress configuration problems and how to avoid unnecessary changes to the public Site Icon while debugging an admin-only icon.

Quick answer: why is my WordPress admin favicon not updating?

The most common causes are:

• the browser is still displaying a cached favicon;
• the admin favicon setting is empty or was not saved;
• the saved image URL no longer points to a valid file;
• the favicon markup is not being printed in admin_head;
• another plugin or custom snippet is outputting a different favicon;
• the browser is falling back to /favicon.ico;
• the WordPress Site Icon is being mistaken for the admin favicon;
• the favicon file was replaced without changing its URL;
• the selected format is not being handled as expected by the browser;
• a CDN or proxy is serving an older resource.

The fastest troubleshooting order is:

1. Inspect the admin HTML head

2. Find the favicon URL

3. Open that URL directly

4. Verify the image is correct

5. Check for duplicate icon tags

6. Test browser caching

7. Inspect WordPress Site Icon fallback

8. Check plugin or CDN caching

First understand what should be updating

Before troubleshooting, determine which icon you actually changed.

WordPress can involve several visually similar assets:

WordPress Site Icon
→ public site identity

Admin favicon
→ wp-admin browser tab

Admin Bar icon
→ Toolbar inside WordPress

Admin menu logo
→ left administration navigation

Login logo
→ authentication screen

Changing one does not automatically change the others.

For the exact distinction between the two favicon systems, see Admin Favicon vs WordPress Site Icon.

Changing the Site Icon is not the same as changing the admin favicon

WordPress includes a built-in Site Icon system.

For current WordPress versions, the icon can be configured through:

Settings
↓
General
↓
Site Icon

The official WordPress favicon documentation describes the Site Icon workflow and recommends a square source image of at least 512 × 512 pixels.

The Site Icon is stored as the:

site_icon

option and can be retrieved through:

get_site_icon_url()

The official get_site_icon_url() documentation covers that API.

An admin favicon can be independent

A backend-specific favicon can instead be printed only inside:

wp-admin

through:

admin_head

The official admin_head reference confirms that the action runs in the head section of administration pages.

This allows the architecture:

Public website
→ Site Icon

WordPress administration
→ Admin Favicon

without requiring both to use the same image.

If you changed the admin favicon, the frontend should remain unchanged

This is expected behavior.

If your public website still shows the original Site Icon after changing the admin favicon, that does not indicate a problem.

An admin-scoped implementation should leave the frontend untouched.

For the installation workflow itself, see How to Change the WordPress Admin Favicon.

Step 1: inspect the wp-admin HTML head

Do not begin by clearing every cache available to humanity.

First determine what the server is actually sending to the browser.

Open a WordPress administration page and inspect the document source or browser developer tools.

Search for:

rel="icon"

and:

rel="shortcut icon"

A custom admin favicon may appear as:

<link
    rel="icon"
    href="https://example.com/wp-content/uploads/admin-icon.png"
>

<link
    rel="shortcut icon"
    href="https://example.com/wp-content/uploads/admin-icon.png"
>

If the new favicon URL appears in the HTML

If the generated markup already contains the new image URL, WordPress or the responsible plugin has probably done its job.

The problem is now more likely to involve:

• browser favicon cache;
• HTTP cache;
• CDN cache;
• an old image served from the same URL;
• another icon tag competing with it.

This distinction saves time.

Correct URL in HTML
→ investigate browser/resource layer

Wrong or missing URL in HTML
→ investigate WordPress/output layer

If no custom favicon tag appears

If there is no expected:

<link rel="icon">

inside the administration document head, browser caching is not the first problem to solve.

Instead, check:

• whether the favicon setting is enabled;
• whether an image was actually selected;
• whether the setting was saved;
• whether the responsible plugin or code is active;
• whether the output callback is attached to admin_head;
• whether another condition causes the callback to return early.

Step 2: open the favicon URL directly

Copy the favicon URL from the HTML and open it directly in a new browser tab.

For example:

https://example.com/wp-content/uploads/2026/09/admin-favicon.png

Check whether the URL:

• returns the expected image;
• returns the old image;
• returns a 404 page;
• redirects elsewhere;
• requires authentication;
• returns HTML instead of an image;
• uses the expected HTTPS scheme.

A valid setting can still point to an invalid resource

A WordPress option can contain a perfectly valid-looking URL such as:

https://example.com/wp-content/uploads/admin-favicon.png

while the file itself no longer exists.

This can happen after:

• media cleanup;
• a migration;
• domain replacement;
• moving uploads;
• restoring an older database;
• deleting and recreating the attachment;
• changing CDN configuration.

Check the Media Library attachment

If the favicon was selected from the WordPress Media Library, verify that the attachment still exists.

WordPress provides:

wp_get_attachment_image_url()

for retrieving image attachment URLs.

The official wp_get_attachment_image_url() reference states that the function returns the image URL or false when an image is unavailable.

Example attachment check

$favicon_id = 123;

$favicon_url = wp_get_attachment_image_url(
    $favicon_id,
    'full'
);

if ( ! $favicon_url ) {
    // The attachment could not be resolved.
}

If an implementation stores both:

attachment ID
+
image URL

inspect both values when debugging.

Attachment ID and URL can become inconsistent

Imagine a plugin stores:

Attachment ID:
123

Saved URL:
https://old-domain.test/wp-content/uploads/admin-icon.png

after the website has migrated to:

https://new-domain.com/

The attachment may still be valid while the separately stored URL is stale.

This is one reason migrations can expose favicon problems even when normal Media Library images appear to work.

Step 3: verify the saved admin favicon setting

If the icon is controlled by a plugin or custom option, confirm that the value was actually stored.

WordPress provides:

get_option()

for retrieving options.

The official get_option() documentation explains that the function returns the stored value or a supplied default when the option does not exist.

Example debugging check

$favicon_url = get_option(
    'my_admin_favicon_url',
    ''
);

error_log(
    'Admin favicon: ' . $favicon_url
);

Use temporary logging only in an appropriate development or debugging environment.

Do not leave unnecessary diagnostic output permanently enabled on production websites.

Empty setting means no custom favicon output

A well-designed admin favicon callback should normally stop when no valid icon has been configured.

For example:

function project_admin_favicon() {

    $favicon_url = get_option(
        'project_admin_favicon_url',
        ''
    );

    if ( ! $favicon_url ) {
        return;
    }

    // Output favicon markup.
}

If the option is empty, refreshing the browser forever is unlikely to improve the situation.

Step 4: verify the admin_head callback

An admin-specific favicon usually depends on:

admin_head

If custom code is responsible, confirm that the callback is actually registered:

add_action(
    'admin_head',
    'project_admin_favicon'
);

The callback then needs to output the favicon markup.

A minimal working implementation

add_action(
    'admin_head',
    'project_admin_favicon',
    1
);

function project_admin_favicon() {

    $favicon_url = plugin_dir_url( __FILE__ )
        . 'assets/admin-favicon.png';

    ?>

    <link
        rel="icon"
        href="<?php echo esc_url( $favicon_url ); ?>"
    >

    <?php
}

If this markup does not appear in the administration source, investigate:

• whether the plugin is active;
• whether the PHP file is loaded;
• whether an earlier error prevents execution;
• whether a conditional check is excluding the current page;
• whether the callback name is correct.

Use admin_head, not wp_head, for an admin-only favicon

This:

add_action(
    'wp_head',
    'project_admin_favicon'
);

targets normal frontend rendering.

It does not represent a clean administration-only implementation.

The correct context is:

Frontend
→ wp_head

Administration
→ admin_head

Login
→ login_head

The login page is not a normal wp-admin page

This causes another common false alarm.

You may see your new icon throughout:

/wp-admin/

but still see another favicon on:

/wp-login.php

That does not necessarily mean the admin favicon failed.

The login page has its own:

login_head

action.

The official login_head documentation covers that separate lifecycle.

For broader login customization, see How to Customize the WordPress Login Page.

Step 5: look for duplicate favicon tags

A WordPress administration page can potentially contain more than one favicon declaration.

Search the entire document head for:

rel="icon"

You might discover:

<link
    rel="icon"
    href="new-admin-icon.png"
>

<link
    rel="icon"
    href="old-admin-icon.png"
>

Now the problem is no longer:

favicon missing

but:

multiple favicon owners

Browsers can choose between multiple icons

The HTML rel="icon" relationship represents an icon for the current document.

The MDN documentation for the rel attribute notes that when multiple icon links are present, browsers can consider properties such as:

• media;
• type;
• sizes.

Do not assume that simply adding another icon tag guarantees which resource will be displayed.

Find every favicon owner

Possible sources include:

• the WordPress Site Icon;
• an admin customization plugin;
• a white-label plugin;
• a custom MU plugin;
• theme code;
• a snippet manager;
• an agency management plugin;
• custom PHP in functions.php.

Choose one system to own the admin favicon.

Do not solve duplicate markup with CSS

Favicon declarations live in the HTML head.

CSS cannot reliably decide which:

<link rel="icon">

the browser should use.

Remove or disable the competing output instead.

Step 6: understand browser favicon caching

Favicons are unusually persistent in browser caches.

A normal page reload may update:

• HTML;
• CSS;
• JavaScript;
• images inside the page;

while the browser tab continues to show the previous favicon.

That behavior can make a correct server-side implementation appear broken.

The first question is not “did I clear cache?”

The first question should be:

Does the current HTML
reference the correct file?

If the answer is yes, the debugging path becomes much more focused.

Use a private browsing window as one test

Open the administration page in a new private or incognito session.

If the new favicon appears there while the normal profile still shows the old icon, browser state becomes a strong suspect.

This is useful evidence, but it is not the only test you should perform.

Close and reopen the tab

Some browsers retain favicon state at the tab level.

Try:

close wp-admin tab
↓
open a completely new tab
↓
navigate back to wp-admin

rather than only pressing reload repeatedly.

Use a new favicon URL when testing

If the old icon lived at:

/uploads/admin-favicon.png

and you replaced the file contents while keeping exactly the same URL, the browser or CDN may continue using the cached object.

Test with a new filename:

/uploads/admin-favicon-v2.png

If the new icon immediately appears, the problem was probably tied to resource caching rather than WordPress configuration.

Query strings can help diagnose resource caching

During debugging, another test is to temporarily use a versioned URL such as:

admin-favicon.png?v=2

This changes the requested URL.

However, for a configurable Media Library favicon, selecting a new attachment or changing the filename usually produces a cleaner persistent setup than depending on arbitrary query strings.

Do not keep incrementing version numbers without understanding the cause

If every update requires:

?v=17
?v=18
?v=19

you have stopped debugging and started negotiating with the cache.

Determine which caching layer is serving the old resource.

Step 7: inspect HTTP caching

The favicon image is an HTTP resource.

It may be cached according to response headers such as:

Cache-Control
Expires
ETag
Last-Modified

The MDN HTTP caching guide explains how browser and intermediary caches can reuse stored responses.

Inspect the favicon request in the browser Network panel.

Check whether the request actually happens

After reloading wp-admin, search the Network panel for:

favicon
icon
.png
.ico
.svg

If the browser does not request the expected resource at all, the issue may be favicon-specific browser state rather than the server serving old bytes.

Check the response status

A healthy favicon request normally returns a successful response.

Investigate responses such as:

404
403
500

or unexpected redirects.

A favicon link pointing to a 404 cannot update correctly no matter how many times the WordPress option is saved.

Check the response Content-Type

Verify that the server is returning an appropriate image response rather than:

text/html

containing an error page or authentication form.

This is particularly relevant when:

• uploads are protected;
• a security plugin rewrites file requests;
• a staging site requires authentication;
• a CDN has an invalid origin response.

Step 8: check CDN caching

A CDN can continue serving the previous image even when the origin file has changed.

This is particularly likely when:

same URL
+
long cache lifetime
+
new file contents

are combined.

Possible tests include:

• open the favicon URL directly;
• inspect response headers;
• compare the response with the origin if possible;
• use a new filename;
• purge the specific CDN asset when appropriate.

Do not purge the entire site blindly

If one favicon resource is stale, clearing every cache layer across the complete website may be unnecessary.

Prefer targeted diagnosis:

Which URL is stale?

Which layer owns it?

Which cache needs invalidation?

Step 9: check page cache and HTML cache

Although wp-admin pages are normally not cached like public pages, unusual proxy or infrastructure configurations can still interfere.

If the administration HTML itself is stale, you may continue receiving old:

<link rel="icon">

markup.

Compare the document source with the currently saved configuration.

Do not assume every caching plugin affects wp-admin

Many WordPress page-cache systems intentionally exclude authenticated administration pages.

Therefore:

favicon stale
≠
page cache plugin definitely responsible

Check evidence before disabling unrelated caching systems.

Step 10: distinguish favicon markup from /favicon.ico fallback

Browsers have historically looked for:

/favicon.ico

when no explicit icon is available.

WordPress includes a:

do_favicon()

handler for favicon requests.

The official do_favicon() reference shows that current WordPress redirects the favicon request using:

get_site_icon_url( 32, fallback )

This explains some “wrong favicon” cases

Imagine your custom admin favicon output disappears because its setting is empty.

The browser can then fall back to:

/favicon.ico

which WordPress may resolve to:

WordPress Site Icon

You may therefore see the public Site Icon and conclude:

the old admin favicon
is still cached

when the actual situation is:

custom admin favicon absent
↓
browser fallback
↓
WordPress Site Icon

Inspect the head before deciding which case you have

This is why source inspection comes first.

If the custom favicon link exists:

custom favicon output exists

If it does not:

browser may be using fallback behavior

These require different fixes.

The Site Icon can therefore confuse admin favicon debugging

The WordPress Site Icon is not simply another name for the admin favicon.

It is part of WordPress’s wider site-identity system.

The function:

wp_site_icon()

generates Site Icon metadata.

The official wp_site_icon() documentation shows that WordPress can output multiple icon sizes and an Apple touch icon.

For the full architecture, see Admin Favicon vs WordPress Site Icon.

Step 11: inspect mixed HTTP and HTTPS URLs

A favicon selected before a site migration to HTTPS might still use:

http://example.com/...

while wp-admin now runs on:

https://example.com/...

Modern browsers may reject or upgrade insecure resource requests depending on context and security policy.

Check the exact URL being generated.

Do not manually concatenate upload URLs when WordPress can resolve them

Prefer WordPress media APIs such as:

wp_get_attachment_image_url()

or:

wp_get_attachment_url()

when appropriate.

The official wp_get_attachment_url() reference documents the attachment URL API.

Step 12: check domain migration problems

A favicon can stop updating after migration when the stored setting still contains:

https://staging.example.com/...

instead of:

https://www.example.com/...

Inspect the saved favicon URL rather than assuming the Media Library automatically corrected every custom option.

Custom plugin options may not follow normal content replacements automatically

Migration tools commonly replace URLs inside:

• posts;
• post meta;
• options;
• serialized data.

But behavior depends on the migration process and how the custom setting is stored.

Always inspect the final value.

Step 13: check deleted Media Library items

A favicon setting can retain an old URL after the underlying attachment has been deleted.

This produces:

setting exists
+
file does not

If the image was removed, select a new attachment and save the configuration again.

Step 14: check image format

Common favicon formats include:

ICO
PNG
SVG

Browser support and behavior can differ between formats and contexts.

For the widest straightforward compatibility, a simple PNG or ICO is usually easier to troubleshoot than an unusually complex SVG.

SVG can introduce additional variables

If the favicon works when replaced with PNG but not with SVG, inspect:

• the SVG response MIME type;
• whether the file itself is valid;
• security or upload restrictions;
• browser support in the environment being tested;
• whether a CDN changes the response headers.

Do not conclude that the WordPress setting is broken until the actual SVG resource has been tested directly.

Step 15: use a simple test icon

When debugging a complex brand asset, temporarily switch to a very obvious test image.

For example:

bright red square
with white letter T

If the simple icon updates immediately, the infrastructure probably works and the problem is specific to the original asset or its URL.

This can be more informative than repeatedly replacing one visually similar logo with another.

Step 16: confirm the icon is actually different

This sounds trivial, but browser-tab favicons are tiny.

Two versions of a logo may look virtually identical at:

16 × 16
or
32 × 32

even if the source files differ substantially.

Use a visibly different temporary test icon when confirming whether an update is working.

Step 17: check filename collisions

Imagine uploading:

favicon.png

several times.

Depending on the Media Library and storage system, WordPress may create:

favicon.png
favicon-1.png
favicon-2.png

Verify which file the saved setting references.

Do not assume the newest upload automatically owns the original URL.

Step 18: inspect redirects

Open the favicon URL and check whether it redirects.

Possible chains include:

old domain
↓
new domain

HTTP
↓
HTTPS

local uploads
↓
CDN

missing file
↓
generic page

A redirect is not automatically wrong, but unexpected chains make favicon behavior more difficult to diagnose.

Step 19: check authentication-protected staging sites

A staging environment may be protected with:

• HTTP Basic Authentication;
• site-wide password protection;
• network access rules;
• security middleware.

If the favicon URL requires authentication or returns a login page instead of the image, browser behavior can become inconsistent.

Open the exact resource URL directly while testing.

Step 20: check Content Security Policy

Strict security headers can restrict where browser resources may be loaded from.

If the favicon is hosted on another domain or CDN and the browser console reports a content-security error, the problem is not WordPress’s Media Library setting.

Use the browser Console and Network panels instead of guessing.

Step 21: check whether a security plugin rewrites uploads

Some environments protect uploaded files or rewrite access rules.

A favicon resource that works publicly may behave differently while authenticated, or vice versa.

Again, verify the actual HTTP request.

Step 22: verify URL sanitization and output escaping

A configurable favicon URL should be sanitized when stored and escaped when output.

WordPress provides:

sanitize_url()

for URL sanitization in database or redirect contexts.

The official sanitize_url() documentation describes that behavior.

For HTML output, use:

esc_url()

The official esc_url() reference covers URL escaping for displayed markup.

A malformed value can disappear after escaping

If a saved favicon value contains an invalid or unsupported URL scheme, proper escaping may return an empty result.

This can produce:

setting appears populated
↓
escaped output empty
↓
no useful favicon URL

Inspect the sanitized value rather than removing escaping to make the icon appear.

Never “fix” a favicon by removing security escaping

If:

esc_url( $favicon_url )

produces an unexpected result, determine why the stored URL is invalid.

Do not replace it with raw output merely to get the browser to accept something.

Step 23: test another admin page

If the favicon appears on:

Dashboard

but not:

Posts
Media
Settings
plugin pages

the output may have been attached to a screen-specific hook instead of the general:

admin_head

WordPress also exposes dynamic hooks such as:

admin_head-{$hook_suffix}

The official screen-specific admin head documentation explains that pattern.

Use general admin_head when the favicon should appear everywhere

For a global administration favicon:

add_action(
    'admin_head',
    'project_admin_favicon'
);

is conceptually simpler than registering separate callbacks for every administration screen.

Step 24: inspect Multisite behavior separately

WordPress Multisite introduces additional site context.

The native:

get_site_icon_url()

function accepts a blog ID, allowing Site Icons to differ between sites.

An admin favicon solution must similarly decide whether its configuration is:

per site
or
network-wide

Do not assume one Multisite admin context represents all of them

Test:

• individual site dashboards;
• Network Admin;
• different sites in the network;
• different user capabilities.

A favicon loaded correctly in one context may not be configured for another.

Step 25: check Network Admin specifically

The Network Admin lives in a different administration context from a normal individual site.

If your implementation depends on site-specific settings, decide what Network Admin should display.

Possible policies include:

Network icon
or
default WordPress icon
or
shared agency icon

Make the behavior intentional.

TheOneWP Admin Favicon troubleshooting model

TheOneWP Admin Favicon is designed around an admin-only favicon configuration.

The practical troubleshooting path is:

Module enabled?
↓
Image selected?
↓
Saved URL valid?
↓
admin_head output present?
↓
correct favicon link generated?
↓
resource URL accessible?
↓
browser displaying correct resource?

Debugging in this order separates plugin configuration from browser behavior.

The module does not replace the public Site Icon

That means changing the admin favicon should not be expected to modify:

Settings → General → Site Icon

or the public favicon generated by WordPress.

This separation is intentional.

The module does not need to regenerate image files

If a selected favicon URL already points to a suitable asset, an admin favicon feature can use that resource directly.

Therefore, if you replace the contents behind the exact same URL, caching can become more visible than when selecting a completely new Media Library asset.

When reselecting the image can help

If the saved configuration appears inconsistent, a useful test is:

remove current admin favicon
↓
save
↓
select new image
↓
save again
↓
inspect generated admin head

The important part is not merely reselecting it.

Verify that the resulting HTML actually points to the new resource.

Do not repeatedly toggle the module without inspecting output

Turning a feature:

off
on
off
on

may make you feel productively occupied, but it provides little diagnostic information.

Inspect the configuration and generated markup after each meaningful change.

Admin favicon vs Admin Bar icon

Do not troubleshoot the favicon when the actual problem is the icon displayed inside the top WordPress Toolbar.

These are separate:

Browser tab
→ Admin Favicon

Toolbar
→ Admin Bar Icon

TheOneWP Admin Bar Icon controls the latter.

Admin favicon vs admin menu logo

The same applies to the branding shown inside the left sidebar.

Browser favicon
≠
sidebar logo

TheOneWP Admin Menu Logo handles that separate component.

Admin favicon vs login branding

The login page belongs to another interface lifecycle.

If the browser icon is correct after login but not on the authentication page, investigate login-page branding separately.

See Branding the WordPress Login Screen for Clients.

TheOneWP Custom Login Page addresses the broader login presentation layer.

Use different favicons for production and staging carefully

A distinct administration favicon can help identify environments.

For example:

Production
→ normal client icon

Staging
→ orange variant

Local
→ development mark

However, confirm that migration or deployment processes do not overwrite the environment-specific configuration unexpectedly.

A database copy can overwrite admin branding

If staging receives a full database copy from production, its saved admin favicon option may become identical to production.

Likewise, copying staging back to production can accidentally move development-specific branding in the other direction.

Document which settings are environment-specific.

Standardize the troubleshooting process across a team

When several developers maintain WordPress sites, use the same sequence:

1. Verify setting

2. Verify generated markup

3. Verify resource

4. Verify duplicate tags

5. Verify cache

6. Verify environment

This produces much more useful bug reports than:

favicon doesn't work

For wider backend consistency, see Standardizing the WordPress Admin for Teams.

A useful bug report contains evidence

When reporting an admin favicon problem, record:

Expected icon:
new-admin.png

Actual icon:
old-admin.png

Generated rel="icon":
new-admin.png

Direct URL:
loads correctly

Private window:
works

Normal profile:
old icon

That report already strongly points toward browser state.

Another example

Expected icon:
new-admin.png

Generated rel="icon":
none

Saved setting:
empty

Direct URL:
works

That points toward configuration rather than browser cache.

A third example

Expected icon:
new-admin.png

Generated rel="icon":
new-admin.png

Direct URL:
404

Browser:
old Site Icon

Now the main issue is the invalid resource URL.

Do not treat every old favicon as browser cache

This is the biggest troubleshooting mistake.

An old-looking favicon might actually be:

• the WordPress Site Icon fallback;
• a second explicit icon tag;
• a CDN-cached file;
• a different favicon selected by the browser;
• the login-page favicon rather than the admin favicon.

Identify the source before clearing anything.

Do not treat every missing favicon as a WordPress bug

A missing icon can result from:

• 404 resource;
• invalid URL;
• unsupported or malformed file;
• security restriction;
• authentication requirement;
• missing output callback;
• disabled plugin;
• empty option.

Common mistake: replacing the file but keeping the same URL

This is one of the easiest ways to create a cache illusion.

Instead of replacing:

admin-favicon.png

with a new file using the same path, test with:

admin-favicon-v2.png

to immediately determine whether the resource URL itself is part of the problem.

Common mistake: clearing only WordPress cache

The stale object may live in:

• browser cache;
• CDN cache;
• proxy cache;
• operating-system or browser favicon state.

A WordPress cache purge does not necessarily touch those layers.

Common mistake: clearing only browser cache

The opposite is also possible.

If the HTML still contains:

old-admin-favicon.png

clearing the browser cache simply makes the browser request the wrong file again.

Common mistake: confusing the public favicon with the admin favicon

If:

frontend changed
admin did not

you may have updated the Site Icon rather than the admin-specific setting.

If:

admin changed
frontend did not

that may be exactly the intended behavior.

Common mistake: expecting admin_head to affect wp-login.php

The login page has a separate head hook.

Treat it independently.

Common mistake: outputting raw URLs

Do not write:

echo '<link rel="icon" href="' .
    $favicon_url .
    '">';

when the value can be escaped correctly:

echo '<link rel="icon" href="' .
    esc_url( $favicon_url ) .
    '">';

Common mistake: debugging by removing escaping

If the escaped URL becomes empty, the saved value may be invalid.

Fix the value.

Do not weaken output handling.

Common mistake: testing with two nearly identical icons

Use an obviously different temporary image during diagnosis.

At favicon dimensions, subtle color or typography changes are difficult to distinguish.

Common mistake: ignoring redirects

A favicon can technically resolve while passing through:

old domain
→ redirect
→ CDN
→ another redirect
→ final file

Simplify the path where possible.

Common mistake: using a giant source unnecessarily

A backend favicon does not need a multi-megabyte print-quality image.

Use a compact asset designed for browser-tab display.

Common mistake: forcing a complicated SVG during initial debugging

When troubleshooting, reduce variables.

Test a simple PNG first.

Once the output path is confirmed, return to the preferred production format.

Common mistake: forgetting other browser profiles

A favicon can appear differently between:

• normal profile;
• private session;
• another browser;
• another device.

Cross-checking another clean environment helps isolate client-side state.

Common mistake: editing WordPress Core

Do not modify:

wp-admin/admin-header.php

to force a favicon into the page.

The:

admin_head

hook already exists for administration-head output.

Common mistake: solving one favicon with several plugins

Installing multiple favicon or white-label plugins can create:

duplicate tags
+
unclear configuration ownership
+
harder troubleshooting

Use one clear owner for the admin favicon.

Common mistake: assuming a plugin deactivation removes browser cache

Deactivating the plugin may remove:

favicon markup

but the browser may continue displaying an icon it already associated with the site.

Inspect the new source to confirm the plugin output is actually gone.

Common mistake: assuming the browser tab proves the current HTML

The favicon visible in the tab is not a trustworthy source-code inspector.

It is a rendered browser decision that may involve cached state.

The HTML source and Network response are stronger diagnostic evidence.

A reliable troubleshooting workflow

Admin favicon appears wrong
↓
Inspect page source
↓
Is correct rel="icon" present?

NO
→ check setting
→ check module/plugin
→ check admin_head
→ check saved URL

YES
↓
Open favicon URL directly
↓
Does it show correct image?

NO
→ fix file/URL/CDN/migration

YES
↓
Check duplicate icon tags
↓
Duplicates?

YES
→ remove conflicting owner

NO
↓
Test private session/new browser
↓
Works there?

YES
→ browser/favicon cache issue

NO
↓
Inspect Network response
↓
check HTTP cache/CDN/security
↓
inspect Site Icon fallback

Production troubleshooting checklist

• Confirm you are changing the admin favicon rather than only the WordPress Site Icon.
• Confirm the admin favicon feature or custom implementation is active.
• Confirm an image has actually been selected.
• Save the configuration again if necessary.
• Inspect the wp-admin document head.
• Search for every rel="icon" declaration.
• Search for every rel="shortcut icon" declaration.
• Verify that the expected admin favicon URL appears.
• Open the favicon URL directly.
• Confirm the response is the expected image.
• Check for 404 and 403 responses.
• Check for unexpected redirects.
• Check HTTP versus HTTPS.
• Check whether the image attachment still exists.
• Check whether a migration left an old domain in the saved option.
• Check duplicate favicon output from other plugins or custom code.
• Check whether the browser is falling back to /favicon.ico.
• Remember that WordPress can resolve /favicon.ico through the Site Icon.
• Test in a private browsing session.
• Close the old tab and open a completely new one.
• Test with another browser.
• Temporarily use a clearly different icon.
• Test with a new favicon filename.
• Inspect Network requests.
• Inspect response caching headers.
• Check CDN caching.
• Check security or authentication rules affecting the image URL.
• Test a simple PNG if an SVG behaves unexpectedly.
• Check wp-admin separately from wp-login.php.
• Check Network Admin separately on Multisite.
• Do not edit WordPress Core files.
• Do not remove URL sanitization or output escaping while debugging.
• Document environment-specific favicon settings.

How TheOneWP fits into the troubleshooting process

TheOneWP Admin Favicon provides the admin-specific configuration layer.

The browser still remains responsible for displaying the favicon, so troubleshooting must distinguish between:

TheOneWP setting
→ configuration

admin_head
→ generated markup

Media Library
→ image resource

HTTP/CDN
→ resource delivery

browser
→ favicon display and caching

That separation makes diagnosis much easier.

Keep other backend branding layers separate

A complete branded WordPress administration area may also use:

Admin Bar Icon for the top Toolbar and Admin Menu Logo for the left administration sidebar.

Those settings should not be treated as alternative methods of changing the browser favicon.

For the broader design system, see How to Brand the WordPress Admin Dashboard.

Admin branding should remain maintainable

For agencies managing many installations, define one owner for each component:

Site Icon
→ public website

Admin Favicon
→ browser tab in wp-admin

Admin Bar Icon
→ Toolbar

Admin Menu Logo
→ sidebar

Custom Login Page
→ authentication

This prevents one setting from accidentally being used as a workaround for another.

See Standardizing the WordPress Admin for Teams for the wider administration strategy.

Related guides

• How to Change the WordPress Admin Favicon
• Admin Favicon vs WordPress Site Icon
• How to Brand the WordPress Admin Dashboard
• Branding the WordPress Login Screen for Clients
• How to Customize the WordPress Login Page
• Standardizing the WordPress Admin for Teams

Final recommendation

When a WordPress admin favicon is not updating, do not start by changing code.

Start by identifying which layer is wrong.

The most reliable process is:

Inspect generated HTML
↓
verify favicon URL
↓
open resource directly
↓
check duplicate icon tags
↓
check browser caching
↓
check HTTP/CDN caching
↓
check Site Icon fallback
↓
check environment-specific configuration

If the new favicon URL is already present in the administration HTML and that URL serves the correct image, the WordPress configuration is probably working. Focus on browser state, duplicate icon declarations or resource caching.

If the expected favicon URL is missing from the HTML, focus instead on the saved setting, plugin activation, custom callback and admin_head output.

If the URL exists but returns the wrong file, a 404 or an old domain, fix the resource before touching browser caches.

Remember that the WordPress Site Icon and an admin-specific favicon are separate systems. When the custom admin favicon is absent, the browser may still display an icon through conventional /favicon.ico behavior, which WordPress can resolve using the Site Icon. That can make an old-looking icon appear to be a cache problem when the real issue is missing admin-specific markup.

For an admin-only implementation, keep the favicon scoped to admin_head, keep its URL valid and properly escaped, and use one clear system to own the backend favicon.

TheOneWP Admin Favicon provides that dedicated admin layer while leaving the public WordPress Site Icon unchanged, making the troubleshooting boundary clear: first verify the setting and generated markup, then investigate the browser and delivery layers only if the server-side output is already correct.