How to change the WordPress Admin Favicon

Changing the WordPress admin favicon lets you use a dedicated browser-tab icon for wp-admin without necessarily changing the favicon displayed on the public website.

This is useful when:

• you manage several WordPress installations at the same time;
• you want staging and production dashboards to be visually distinguishable;
• you are creating a branded backend for a client;
• your frontend Site Icon should remain different from the administration icon;
• you want browser tabs containing wp-admin pages to be easier to identify.

The basic implementation is straightforward:

custom image
↓
admin_head
↓
<link rel="icon">
↓
browser tab icon in wp-admin

The important part is understanding where the favicon is injected.

WordPress has several separate rendering contexts:

Frontend
→ wp_head

Administration
→ admin_head

Login screen
→ login_head

If you want an icon that applies specifically to WordPress administration pages, admin_head is the appropriate scope.

This guide explains how to change the WordPress admin favicon manually, how admin_head works, how the admin favicon differs from the WordPress Site Icon, which image formats and dimensions to use, how browser favicon caching affects updates and how TheOneWP Admin Favicon provides the same type of customization through the WordPress Media Library.

What is the WordPress admin favicon?

A favicon is the small icon browsers associate with a document or website.

It commonly appears in:

• browser tabs;
• bookmarks;
• browser history;
• saved shortcuts;
• other browser interface elements.

The HTML relationship normally used is:

<link
    rel="icon"
    href="https://example.com/favicon.png"
>

The MDN documentation for the rel attribute defines icon as the linked resource representing the current document in the user interface.

WordPress does not provide a dedicated admin-favicon setting

WordPress Core provides a built-in:

Site Icon

setting.

That feature is designed around the site’s general identity rather than providing a separate native setting specifically labeled:

Admin Favicon

If you need:

frontend favicon
≠
wp-admin favicon

you need an additional admin-specific implementation.

Admin favicon vs WordPress Site Icon

The difference can be summarized as:

WordPress Site Icon
→ site-level identity

Custom admin favicon
→ wp-admin-specific identity

The Site Icon is WordPress Core functionality.

An admin-specific favicon is a customization layered onto the administration interface.

See Admin Favicon vs WordPress Site Icon for the complete comparison.

How WordPress handles the Site Icon

WordPress provides:

wp_site_icon()

to output Site Icon metadata.

The official wp_site_icon() documentation shows that WordPress can output several icon-related tags, including:

32×32 icon
192×192 icon
Apple touch icon
Microsoft tile image

This is broader than a single browser-tab favicon.

The Site Icon uses several generated sizes

For example, current Core can output:

<link
    rel="icon"
    href="..."
    sizes="32x32"
/>

<link
    rel="icon"
    href="..."
    sizes="192x192"
/>

<link
    rel="apple-touch-icon"
    href="..."
/>

The Site Icon therefore belongs to a wider identity system.

WordPress recommends a 512×512 Site Icon source

The official WordPress favicon documentation recommends a square image of at least:

512 × 512 pixels

for the built-in Site Icon.

PNG is recommended by that documentation for the Site Icon workflow.

This does not mean an admin favicon must be 512×512

An admin-only favicon inserted directly into:

admin_head

does not automatically go through WordPress’s Site Icon processing system.

You can point the browser directly to a smaller icon resource.

For example:

32 × 32 PNG

can be perfectly appropriate for a dedicated administration favicon.

TheOneWP recommends 32×32 for Admin Favicon

The current TheOneWP Admin Favicon interface recommends:

32 × 32 pixels

and supports selecting an:

ICO
PNG
SVG

resource from the WordPress Media Library.

The module does not resize or convert the selected source automatically.

The selected image should therefore already be suitable for favicon use.

Method 1: change the WordPress admin favicon with admin_head

WordPress provides the:

admin_head

action.

The official admin_head documentation states that the hook fires in the <head> section of all administration pages.

This makes it a natural place to output admin-specific favicon markup.

Basic example

add_action(
    'admin_head',
    function () {
        ?>
        <link
            rel="icon"
            href="https://example.com/wp-content/uploads/admin-favicon.png"
        >
        <?php
    }
);

This places a favicon declaration inside wp-admin pages.

A better version uses WordPress escaping

Do not insert an untrusted URL directly into HTML.

Use:

esc_url()

when outputting a URL into markup.

The official esc_url() documentation identifies it as the appropriate URL-escaping function for displayed HTML.

Example with esc_url()

function project_admin_favicon() {

    $favicon_url =
        'https://example.com/wp-content/uploads/admin-favicon.png';

    if ( empty( $favicon_url ) ) {
        return;
    }

    printf(
        '<link rel="icon" href="%s" />' . "\n",
        esc_url( $favicon_url )
    );
}

add_action(
    'admin_head',
    'project_admin_favicon'
);

Add an explicit size when appropriate

If the resource is designed specifically as a 32×32 icon:

function project_admin_favicon() {

    $favicon_url =
        'https://example.com/wp-content/uploads/admin-favicon.png';

    if ( empty( $favicon_url ) ) {
        return;
    }

    printf(
        '<link rel="icon" href="%s" sizes="32x32" />' . "\n",
        esc_url( $favicon_url )
    );
}

add_action(
    'admin_head',
    'project_admin_favicon'
);

Should you add shortcut icon too?

Older implementations commonly include:

<link rel="shortcut icon">

in addition to:

<link rel="icon">

Modern browsers understand:

rel="icon"

directly.

Some compatibility-oriented implementations still output both.

Example with both tags

function project_admin_favicon() {

    $favicon_url =
        'https://example.com/wp-content/uploads/admin-favicon.png';

    if ( empty( $favicon_url ) ) {
        return;
    }

    $favicon_url =
        esc_url( $favicon_url );

    printf(
        '<link rel="icon" href="%s" />' . "\n",
        $favicon_url
    );

    printf(
        '<link rel="shortcut icon" href="%s" />' . "\n",
        $favicon_url
    );
}

add_action(
    'admin_head',
    'project_admin_favicon'
);

TheOneWP outputs both icon declarations

The current Admin Favicon module prints:

rel="icon"

and

rel="shortcut icon"

when a valid admin favicon URL exists.

Both point to the selected Media Library resource.

Use an attachment ID when the image comes from the Media Library

Hardcoding a complete uploads URL works, but a plugin or custom settings interface can store a WordPress attachment ID instead.

WordPress provides:

wp_get_attachment_url()

to retrieve the file URL associated with an attachment.

See the official wp_get_attachment_url() documentation.

Example using an attachment ID

function project_admin_favicon() {

    $attachment_id = 123;

    $favicon_url =
        wp_get_attachment_url(
            $attachment_id
        );

    if ( ! $favicon_url ) {
        return;
    }

    printf(
        '<link rel="icon" href="%s" />' . "\n",
        esc_url( $favicon_url )
    );
}

add_action(
    'admin_head',
    'project_admin_favicon'
);

Store both ID and URL when useful

A settings interface can reasonably keep:

attachment ID
+
resolved URL

The current TheOneWP module follows this pattern.

This lets the settings interface retain the relationship with the Media Library while the runtime output can access the selected URL efficiently.

Sanitize stored URLs

When a URL is saved into plugin settings, sanitize it before storage.

WordPress provides:

esc_url_raw()

for database-oriented URL sanitization.

The official esc_url_raw() documentation explicitly notes that it is for storage rather than display.

Use different functions for storage and output

The useful pattern is:

Save setting
→ esc_url_raw()

Output HTML
→ esc_url()

For example:

$stored_url =
    esc_url_raw(
        $_POST['admin_favicon_url']
    );

update_option(
    'project_admin_favicon_url',
    $stored_url
);

Then:

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

if ( $favicon_url ) {
    printf(
        '<link rel="icon" href="%s" />',
        esc_url( $favicon_url )
    );
}

Do not output an empty favicon link

A poor implementation might output:

<link rel="icon" href="">

when no image has been selected.

A better implementation returns without printing anything.

Example

if ( empty( $favicon_url ) ) {
    return;
}

This leaves normal browser and WordPress favicon behavior untouched.

TheOneWP behaves this way

If no valid admin favicon URL is configured, the module does not print its custom favicon link elements.

That means disabling or clearing the custom icon does not insert a broken empty favicon declaration.

Why admin_head is the correct scope

The administration interface has its own document head.

The Core hook:

admin_head

runs inside that context.

This allows an implementation to change:

wp-admin browser tabs

without injecting the same markup into the public website.

Do not use wp_head for an admin-only favicon

If you attach the code to:

wp_head

you are targeting the frontend theme output.

That defeats the purpose if the requirement is:

frontend icon stays unchanged
+
wp-admin gets custom icon

Frontend and admin output should remain separate

A clear architecture is:

Frontend Site Icon
→ WordPress Site Icon

Admin favicon
→ admin_head customization

This separation is particularly useful for agencies and multi-environment setups.

The login page is separate again

The WordPress login screen is not an ordinary wp-admin page using the same complete administration header.

WordPress provides:

login_head

for login-page head output.

Therefore:

admin_head favicon
→ wp-admin

login_head favicon
→ login page

are separate customizations.

Do not assume the admin favicon automatically changes wp-login.php

If you want the login page to share the same favicon, add the corresponding login-specific implementation deliberately.

If the login experience itself is being branded, see How to Customize the WordPress Login Page.

For client-focused login branding, see Branding the WordPress Login Screen for Clients.

Example: use the same icon on wp-admin and wp-login.php

function project_backend_favicon() {

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

    if ( ! $favicon_url ) {
        return;
    }

    printf(
        '<link rel="icon" href="%s" />' . "\n",
        esc_url( $favicon_url )
    );
}

add_action(
    'admin_head',
    'project_backend_favicon'
);

add_action(
    'login_head',
    'project_backend_favicon'
);

Only do this when you intentionally want both interfaces to share the same icon.

Admin favicon and Admin Bar icon are different

An admin favicon appears in the:

browser interface

An Admin Bar icon appears inside:

WordPress Toolbar

They are completely different interface elements.

TheOneWP Admin Bar Icon controls the Toolbar-side branding layer.

Admin favicon and Admin Menu Logo are different

An Admin Menu Logo appears inside the left wp-admin navigation.

A favicon appears in the browser tab.

Conceptually:

Admin Favicon
→ browser tab

Admin Bar Icon
→ top Toolbar

Admin Menu Logo
→ left navigation

See TheOneWP Admin Menu Logo and How to Add a Custom Logo to the WordPress Admin Menu.

Use these elements together for consistent branding

A complete backend identity can include:

• admin favicon;
• admin menu logo;
• Toolbar icon;
• custom login page;
• admin color scheme;
• footer branding;
• organized navigation.

See How to Brand the WordPress Admin Dashboard for the broader strategy.

Why use a different admin favicon?

There are several practical reasons.

1. Faster tab identification

Developers and administrators frequently work with many open tabs.

For example:

Site A frontend
Site A wp-admin
Site B frontend
Site B wp-admin
Site C staging
Site C production

Distinct admin icons make the administration tabs easier to identify visually.

2. Differentiate staging from production

A very useful pattern is:

Production
→ normal brand icon

Staging
→ alternate icon

Local
→ development icon

This creates an additional visual cue before an administrator performs a potentially destructive operation.

Do not rely on the favicon as the only environment warning

A different favicon can help.

It should not replace stronger environment indicators such as:

• clear environment labels;
• different admin colors;
• deployment controls;
• staging access restrictions.

3. Client branding

An agency can use a recognizable client or agency icon inside wp-admin while preserving a different public Site Icon.

This supports a more deliberate backend identity without changing frontend branding.

4. Multisite recognition

Administrators working across several WordPress sites can use different visual identities to reduce accidental context switching.

What image size should you use?

Browser favicons are displayed very small.

Common tab rendering is often approximately:

16 × 16
or
32 × 32

depending on browser, platform and pixel density.

For an administration-specific favicon, a source designed to remain clear at:

32 × 32

is a practical choice.

Use a square image

A favicon should normally use:

1:1 aspect ratio

For example:

32 × 32
64 × 64
128 × 128

rather than:

120 × 40

Do not use a complete horizontal logo

A favicon is too small for:

• long company names;
• taglines;
• detailed wordmarks;
• thin text;
• complex illustrations.

Use a simplified mark instead.

Good favicon subjects include

• single letterforms;
• brand symbols;
• simple geometric marks;
• high-contrast monograms;
• simplified logos.

Test the icon at actual favicon size

An image can look excellent at:

512 × 512

and become unreadable at:

16 × 16

Always inspect the final asset at the size users will actually see.

PNG vs ICO vs SVG

All three formats can be useful depending on compatibility and workflow requirements.

PNG

PNG provides:

• good browser support;
• alpha transparency;
• predictable rendering;
• straightforward Media Library handling.

For many WordPress admin-favicon implementations, PNG is the simplest option.

ICO

ICO is the traditional favicon format.

An ICO file can contain multiple embedded sizes.

It remains useful when compatibility with traditional favicon workflows is important.

SVG

SVG is resolution-independent and can remain sharp across display densities.

However, SVG uploads in WordPress require additional consideration because WordPress Core does not permit unrestricted SVG uploads by default.

SVG files can also contain active or unsafe constructs if arbitrary uploads are allowed without appropriate sanitization.

Do not enable unrestricted SVG uploads merely for a favicon

If SVG support is added to WordPress, use a trusted sanitization workflow.

A favicon is not worth weakening upload security across the installation.

PNG is usually the least complicated choice

A simple:

32×32
or
64×64
transparent PNG

works well for many administration interfaces.

Transparent vs solid background

Favicons can use transparency.

But remember that browser tabs may use:

• light backgrounds;
• dark backgrounds;
• theme-dependent surfaces.

An icon that relies on:

black mark
+
transparent background

may disappear on a dark browser theme.

Design for both light and dark browser chrome

Prefer:

• strong silhouettes;
• clear boundaries;
• adequate contrast;
• limited fine detail.

Do not confuse favicon dimensions with file weight

A:

32 × 32 PNG

should generally be a very small file.

There is no reason for an administration favicon to weigh several megabytes.

Optimize the image before upload.

How browsers choose between multiple favicon declarations

A document can contain more than one:

<link rel="icon">

element.

MDN notes that browsers can consider attributes such as:

• type;
• sizes;
• media.

when selecting an appropriate icon.

Multiple favicon declarations can create confusion

Suppose wp-admin contains:

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

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

Browser selection and caching can make troubleshooting less obvious.

Inspect the final admin HTML

Open a wp-admin page and inspect the document head.

Search for:

rel="icon"

and:

rel="shortcut icon"

Determine:

• how many icon declarations exist;
• which URLs they use;
• whether another plugin adds one;
• whether your new URL is present.

Use browser DevTools

A useful workflow is:

wp-admin
↓
Developer Tools
↓
Elements
↓
<head>
↓
search "icon"

This tells you whether the WordPress output layer is correct before you start blaming caching.

If the correct URL is in the HTML, WordPress probably did its job

If you see:

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

but the browser still shows the old image, investigate:

• favicon cache;
• image cache;
• CDN caching;
• duplicate declarations;
• the image URL itself.

If the icon tag is missing, investigate WordPress output

Possible causes include:

• callback not registered;
• module disabled;
• empty saved URL;
• incorrect hook;
• PHP error;
• conditional logic returning early.

Favicon caching is unusually persistent

Browsers frequently cache favicon resources aggressively.

You can therefore change:

admin-favicon.png

on the server while the browser continues displaying its previously cached version.

Changing the filename is a useful diagnostic

Instead of replacing:

admin-favicon.png

with another image at the same URL, temporarily use:

admin-favicon-v2.png

If the new icon appears immediately, caching was probably involved.

A query string can also help diagnose caching

For example:

admin-favicon.png?v=2

can produce a distinct resource URL.

This is useful for diagnosis, although a stable properly versioned asset name is often cleaner for production.

Test in a private browser session

A private or incognito window can help distinguish:

browser-profile cache

from:

server-side output problem

although private browsing does not bypass every possible network or CDN cache.

Open the image URL directly

If wp-admin contains:

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

open that URL directly.

Check whether it displays:

• the expected image;
• the old image;
• a 404 response;
• an access-denied page;
• HTML instead of an image.

Check the network response

In browser developer tools, inspect the favicon request.

Look for:

Status
Content-Type
Cache-Control
ETag
Last-Modified

This can reveal whether the browser or an intermediate cache is retaining an older resource.

CDNs can cache favicon files too

If your uploads are delivered through:

• Cloudflare;
• a hosting CDN;
• a reverse proxy;
• an image CDN;

the cached resource may survive even after the Media Library asset changes.

Purge the specific favicon resource where possible

Targeted invalidation is preferable to clearing every cache on the website when only one small asset changed.

For complete troubleshooting, use the dedicated guide

See WordPress Admin Favicon Not Updating for a complete troubleshooting workflow.

Why can the WordPress Site Icon appear in wp-admin?

This is one of the more confusing parts of favicon debugging.

A browser can request:

/favicon.ico

when no explicit favicon declaration is available or as part of normal favicon discovery behavior.

WordPress handles favicon.ico requests

WordPress Core provides:

do_favicon()

The official do_favicon() implementation redirects a favicon request to:

get_site_icon_url(
    32,
    fallback
)

This can make the Site Icon appear to be the admin favicon

Suppose:

Site Icon
→ blue logo

No explicit admin favicon
→ browser requests /favicon.ico

WordPress may direct that request toward the Site Icon resource.

The result can look like:

WordPress automatically
uses Site Icon in wp-admin

even though the underlying mechanism is browser favicon discovery plus WordPress’s favicon endpoint.

An explicit admin favicon provides clearer control

By adding:

<link rel="icon">

inside admin_head, you create an explicit administration-scoped favicon declaration.

Do not remove the Site Icon just to change wp-admin

If the public website needs its Site Icon, keep it.

Add the administration-specific icon separately.

Current WordPress Site Icon settings

In WordPress 6.5 and later, the Site Icon is available from:

Settings
→ General

The official WordPress favicon documentation reflects this location.

Block themes also expose Site Icon through Site Editor Identity

Current WordPress block-theme installations can also expose identity settings through:

Appearance
→ Editor
→ Identity

The official Site Editor Identity documentation includes the Site Icon alongside the Site Title, Tagline and Site Logo.

Changing the Site Icon is not the same task

If the objective is:

change frontend favicon
and general site identity

use WordPress Site Icon.

If the objective is:

change only wp-admin favicon

use an admin-specific implementation.

How TheOneWP Admin Favicon works

The current TheOneWP Admin Favicon implementation uses WordPress’s native administration head rather than modifying Core files.

The runtime flow is:

Admin Favicon module enabled
↓
TOWP_Admin_Favicon loaded
↓
admin_head
priority 1
↓
saved admin favicon URL read
↓
URL escaped
↓
icon tags printed

The module runs only in admin_head

The implementation does not register the same output on:

wp_head

so the public frontend favicon remains unchanged.

TheOneWP uses priority 1

The module registers its callback on:

admin_head
priority 1

This places the icon declarations early in the administration head output.

The module reads the saved admin_favicon_url

The configured URL is stored as:

admin_favicon_url

and used by the runtime favicon output.

The output URL is escaped

Before being inserted into HTML, the current implementation uses:

esc_url()

This is the correct WordPress escaping context for a displayed URL.

The settings value is sanitized before storage

The current settings implementation uses:

esc_url_raw()

for the stored favicon URL.

This keeps the normal distinction:

storage
→ esc_url_raw()

output
→ esc_url()

The module does not resize the image

If you select:

2000 × 2000 PNG

the runtime class does not create a special 32×32 favicon file itself.

It uses the selected resource URL.

Prepare an appropriate icon beforehand.

The module uses the WordPress Media Library

The settings interface opens the native Media Library in single-image selection mode.

This makes the normal workflow:

prepare icon
↓
upload to Media Library
↓
select image
↓
save settings
↓
reload wp-admin

How to change the admin favicon with TheOneWP

The workflow is:

1. Enable Admin Favicon.

2. Open its settings.

3. Select an image from
   the WordPress Media Library.

4. Save the configuration.

5. Reload a wp-admin page.

6. Verify the new browser-tab icon.

Use a dedicated icon asset

A good practical asset would be:

admin-favicon.png

32 × 32
or
64 × 64

square
transparent or solid background
high contrast

Do not use the original 3000-pixel logo without preparation

Even if the browser can technically scale the source, a purpose-designed favicon is:

• smaller;
• clearer;
• faster to load;
• easier to maintain.

Changing the image does not affect the frontend Site Icon

Because TheOneWP attaches the output only to:

admin_head

the public website does not receive those custom link tags.

Removing the custom favicon

To restore normal behavior, remove the selected Admin Favicon image or disable the module.

When there is no active custom URL, TheOneWP stops outputting its custom favicon tags.

Normal browser and WordPress fallback behavior then resumes

Depending on the site and browser, the visible icon may then come from:

• the WordPress Site Icon;
• /favicon.ico handling;
• another plugin;
• browser cache.

Why might the old favicon remain after disabling the module?

Because browser favicon caches can survive the change in HTML.

Always inspect the document head before deciding the module is still outputting the icon.

Testing checklist after changing the favicon

After saving the new image:

1. Reload wp-admin.

2. Inspect browser tab.

3. Inspect <head>.

4. Confirm expected favicon URL.

5. Open favicon URL directly.

6. Check another wp-admin screen.

7. Open a new tab.

8. Test private browsing.

9. Verify frontend remains unchanged.

10. Verify login page separately.

Test more than the Dashboard screen

Because admin_head runs across administration pages, check:

• Dashboard;
• Posts;
• Pages;
• Media;
• Settings;
• plugin administration screens.

The favicon should be consistent throughout wp-admin.

Test frontend separately

Open:

https://example.com/

and verify that the public Site Icon remains unchanged.

Test the login screen separately

Open:

https://example.com/wp-login.php

and verify whichever favicon behavior you intend there.

Do not infer login behavior from wp-admin behavior.

Multisite considerations

WordPress Multisite can make favicon strategy more complex because administrators may navigate between several site dashboards.

A custom administration icon can be useful for identifying:

• specific sites;
• network administration;
• production vs staging networks.

Check where the favicon configuration is stored

If a plugin stores the setting at the individual-site level, each site can potentially use a different favicon.

If configuration is network-wide, one icon may apply more broadly.

Do not assume one behavior without checking the implementation you use.

Network Admin should be tested explicitly

Visit:

/wp-admin/network/

on Multisite and verify whether the same favicon behavior applies to the Network Admin context.

Use different favicons for environments

A practical agency setup can use:

PRODUCTION
→ client logo

STAGING
→ orange variant

LOCAL
→ development variant

The icon should remain recognizable at favicon size.

Environment differentiation reduces context mistakes

When several dashboards have identical:

• site names;
• content;
• menus;
• themes;

a separate favicon creates an additional visual distinction.

Combine environment favicon with other signals

Useful additional signals include:

• admin notice identifying the environment;
• different admin color scheme;
• different Toolbar label;
• environment-specific database protections.

Admin favicon performance impact

A properly implemented favicon has negligible runtime impact.

The administration page receives a small HTML element such as:

<link
    rel="icon"
    href="..."
>

and the browser requests the icon resource when necessary.

Use a small optimized file

A favicon should not become a meaningful bandwidth cost.

Prefer:

a few kilobytes

rather than:

a multi-megabyte image

Do not enqueue JavaScript just to add a favicon

The favicon belongs in the document head.

There is normally no reason to wait for:

DOMContentLoaded

and then modify the favicon through JavaScript.

A server-rendered:

<link rel="icon">

is simpler and more reliable.

Do not use CSS to set a favicon

Favicons are declared through document metadata.

CSS properties such as:

background-image

cannot configure the browser-tab icon.

Do not modify admin-header.php

WordPress Core contains:

wp-admin/admin-header.php

where the administration document head is generated.

Do not edit that Core file directly.

Use:

admin_head

instead.

Core edits disappear during updates

A direct edit would also:

• complicate upgrades;
• make debugging harder;
• create maintenance debt;
• separate behavior from normal WordPress hooks.

Where should custom favicon code live?

Suitable locations include:

• a site-specific plugin;
• a must-use plugin;
• a maintained snippets system;
• a dedicated administration customization plugin.

A theme is usually not the best location

Ask:

Should switching
the frontend theme
remove the custom
wp-admin favicon?

If the answer is no, the customization belongs more naturally to site functionality than frontend theme presentation.

Use a child theme only when the behavior truly belongs to the theme

Never modify a third-party parent theme directly for an administration customization that needs to survive updates.

Security considerations

A favicon seems harmless, but the stored URL is still user-controlled configuration in many implementations.

Use appropriate:

• capability checks;
• nonces;
• URL sanitization;
• output escaping.

Only authorized administrators should change branding settings

A configuration screen should normally require an administrative capability appropriate to the plugin.

Do not expose arbitrary favicon-URL editing to untrusted users.

Sanitize on input

For URL settings:

esc_url_raw()

is suitable for storage-oriented sanitization.

Escape on output

When rendering:

href="..."

use:

esc_url()

Do not disable escaping to support unusual URLs

If a URL is rejected by normal WordPress URL handling, investigate why.

Removing output escaping is not an appropriate compatibility fix.

Common mistake: changing the Site Icon instead of the admin favicon

If you change:

Settings
→ General
→ Site Icon

you are modifying WordPress’s site-level identity.

That is not the same as creating a dedicated admin-only icon.

Common mistake: using wp_head

wp_head targets the public frontend.

Use:

admin_head

for wp-admin.

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

The login page has its own lifecycle.

Use login-specific hooks if the login favicon should also change.

Common mistake: uploading a giant image

A 4000×4000 logo provides no meaningful advantage when displayed at favicon scale.

Common mistake: using a horizontal wordmark

Long text becomes unreadable inside a browser tab.

Common mistake: using an icon with insufficient contrast

Test against light and dark browser themes.

Common mistake: replacing the image at the same URL and assuming the browser updated it

Favicons are heavily cached.

Use a new filename during troubleshooting when necessary.

Common mistake: clearing WordPress cache before inspecting the HTML

First determine whether wp-admin contains the correct favicon URL.

If the markup is correct, the problem is probably outside the WordPress configuration layer.

Common mistake: installing several favicon plugins

Multiple plugins can produce multiple:

rel="icon"

declarations.

Use one clear source of truth.

Common mistake: forgetting the browser fallback

If no explicit admin favicon is present, WordPress’s Site Icon and /favicon.ico handling can influence what the browser displays.

Common mistake: assuming the Site Icon is automatically printed through admin_head

The fact that the browser displays the Site Icon in wp-admin does not mean WordPress Core necessarily printed the normal frontend Site Icon metadata into admin_head.

Browser fallback behavior and /favicon.ico handling can produce a similar result.

Common mistake: deleting the Site Icon to fix admin branding

Keep frontend identity and admin identity separate.

Common mistake: using SVG without considering upload security

SVG can be useful, but WordPress upload restrictions exist for a reason.

Common mistake: modifying WordPress Core

The admin_head hook already provides the required extension point.

Common mistake: forgetting staging

If the same branding configuration is copied between environments, staging and production may become visually indistinguishable again.

Common mistake: using the favicon as the only environment indicator

Use it as one visual cue, not as the complete safety system.

Common mistake: not testing after a migration

A migrated favicon URL can still reference:

old-domain.example

even when the rest of WordPress uses the new domain.

Check absolute URLs after migrations

If the configured admin favicon is stored as a full URL, verify:

scheme
hostname
path

after:

• domain changes;
• staging-to-production deployment;
• HTTP-to-HTTPS migration;
• CDN migration.

Mixed-content problems

A favicon URL beginning with:

http://

inside an HTTPS administration page can create mixed-content or security-policy problems.

Use an HTTPS resource when wp-admin runs over HTTPS.

Do not use external favicon hosting unnecessarily

Hosting the favicon inside the site’s own Media Library provides:

• simpler ownership;
• fewer external dependencies;
• consistent HTTPS configuration;
• easier migrations.

External URLs can still work

If an externally hosted icon is used, make sure:

• the URL remains stable;
• HTTPS works;
• hotlink protection does not block it;
• the resource is publicly accessible;
• the Content-Type is appropriate.

Content Security Policy can affect external images

Strict browser security policies may prevent images from unapproved origins from loading.

If an external favicon URL appears in the HTML but the resource is blocked, inspect the browser console and network panel.

WordPress admin favicon deployment checklist

• Decide whether the frontend and admin should use different icons.
• Keep WordPress Site Icon for site-level identity.
• Use admin_head for admin-specific favicon markup.
• Do not use wp_head for an admin-only icon.
• Do not assume admin_head affects the login screen.
• Use login_head separately when required.
• Prepare a square favicon asset.
• Design the icon for 16×16 and 32×32 viewing.
• Prefer a simple high-contrast symbol.
• Avoid long wordmarks.
• Optimize the file size.
• Consider PNG for a simple implementation.
• Use ICO when traditional multi-size favicon support is desired.
• Use SVG only with an appropriate secure upload workflow.
• Sanitize stored URLs.
• Use esc_url_raw() for URL storage.
• Use esc_url() for output.
• Do not print empty favicon elements.
• Use the Media Library when practical.
• Store the attachment ID if the implementation benefits from it.
• Inspect the generated wp-admin <head>.
• Check for duplicate favicon declarations.
• Open the favicon URL directly.
• Test browser caching.
• Use a different filename when diagnosing cache problems.
• Check CDN caching.
• Test in a private browsing session.
• Test Dashboard.
• Test Posts and Pages.
• Test plugin administration screens.
• Test frontend separately.
• Test the login screen separately.
• Test Network Admin on Multisite.
• Verify environment-specific branding.
• Check favicon URLs after migrations.
• Check HTTP vs HTTPS.
• Check browser console errors.
• Do not modify WordPress Core.
• Do not modify third-party plugin files.
• Keep the customization in a maintained site-level implementation.

Related guides

• Admin Favicon vs WordPress Site Icon
• WordPress Admin Favicon Not Updating
• How to Brand the WordPress Admin Dashboard
• How to Add a Custom Logo to the WordPress Admin Menu
• How to Customize the WordPress Login Page
• Branding the WordPress Login Screen for Clients

Final recommendation

The cleanest way to change only the WordPress admin favicon is to keep the frontend Site Icon and administration favicon as separate identity layers.

Use:

WordPress Site Icon
→ frontend and site identity

admin_head
→ wp-admin favicon

login_head
→ login-page favicon
when required

A minimal custom implementation can be as simple as:

function project_admin_favicon() {

    $favicon_url =
        'https://example.com/wp-content/uploads/admin-favicon.png';

    if ( ! $favicon_url ) {
        return;
    }

    printf(
        '<link rel="icon" href="%s" sizes="32x32" />' . "\n",
        esc_url( $favicon_url )
    );
}

add_action(
    'admin_head',
    'project_admin_favicon'
);

Use an optimized square image that remains recognizable at very small sizes, sanitize configuration values before storage and escape the final URL when printing it into the administration document head.

Do not change the WordPress Site Icon merely because you want a different wp-admin tab icon. Do not modify WordPress Core. Do not use CSS or JavaScript when a simple head declaration is enough. And do not assume a favicon that refuses to update means the PHP implementation is broken until you have inspected the final HTML and ruled out browser caching.

TheOneWP Admin Favicon provides this behavior through the WordPress Media Library. The current implementation stores the selected image information, sanitizes the configured URL, hooks into admin_head at priority 1, escapes the URL on output and prints both an icon and shortcut-icon declaration without modifying the public frontend favicon.

For a complete branded backend, combine the favicon with the other administration identity layers only where they provide a clear purpose. Admin Bar Icon, Admin Menu Logo and the broader WordPress admin branding workflow address different parts of the interface and should remain separate from the browser-tab icon itself.