Opens in a new tab
  1. Home
  2. Guides
  3. Backend
Backend guide

How to Change the WordPress Admin Footer Text

Learn how to replace the default WordPress admin footer text, add support or agency links, customize content by capability and modify the separate version footer safely.

  • Updated September 15, 2026
  • 20 min read
  • WordPress guide

The WordPress admin footer appears at the bottom of administration screens and normally contains a WordPress attribution message together with version or update information.

For many websites, there is no reason to change it. But agencies, developers, internal platforms and heavily customized WordPress installations may want to replace the default text with something more useful.

You might display:

  • your agency name;
  • a client support link;
  • internal documentation;
  • a maintenance message;
  • the name of the organization managing the website;
  • a link to a support portal;
  • different information depending on the current user’s capabilities.

WordPress provides a dedicated filter for this purpose, so there is no need to edit Core files, manipulate the footer with JavaScript or hide the existing content with CSS.

The basic implementation is:

add_filter( 'admin_footer_text', function( $text ) {
    return 'Your custom footer text';
} );

That small filter is enough for a simple replacement, but production implementations should also consider HTML output, escaping, links, user capabilities, translation, the separate WordPress version area and where the customization should live.

This guide explains how to change the WordPress admin footer text correctly, from a basic text replacement to reusable agency and client implementations.

How the WordPress admin footer works

The administration footer is generated by WordPress Core in wp-admin/admin-footer.php.

WordPress exposes the left-side footer content through the admin_footer_text filter.

The filter receives the footer content and allows a plugin or customization to return a different value before WordPress prints it.

Conceptually, WordPress does this:

$text = apply_filters(
    'admin_footer_text',
    $text
);

Your callback receives that value:

function my_admin_footer_text( $text ) {

    return 'Custom footer';

}

add_filter(
    'admin_footer_text',
    'my_admin_footer_text'
);

WordPress then displays the returned content instead of the original footer message.

This is an important architectural distinction. You are not covering the existing footer or changing how it looks. You are modifying the actual value WordPress outputs through an API specifically provided for that purpose.

The footer contains two separate pieces of information

The administration footer is commonly treated as one element, but WordPress exposes its main text and version/update area separately.

The left-side attribution text uses:

admin_footer_text

The version and update information uses:

update_footer

The official update_footer documentation describes it as the filter for the version and update text displayed in the administration footer.

This means changing the normal footer message does not automatically remove or replace the WordPress version information.

Change the WordPress admin footer with a simple filter

The simplest implementation can be added to a custom plugin or another controlled PHP customization layer:

function my_custom_admin_footer_text( $text ) {

    return 'Website managed by Example Agency';

}

add_filter(
    'admin_footer_text',
    'my_custom_admin_footer_text'
);

After the filter runs, the left side of the administration footer displays:

Website managed by Example Agency

instead of the normal WordPress attribution.

You can also use an anonymous function

For a small site-specific customization:

add_filter( 'admin_footer_text', function( $text ) {

    return 'Website managed by Example Agency';

} );

Both approaches use the same WordPress filter.

A named function is often easier to remove, test or reuse later, while an anonymous function can be convenient for very small isolated customizations.

You do not need the original value if you are replacing it completely

The callback receives the existing footer text as its argument:

function my_custom_admin_footer_text( $text ) {
    // $text contains the current footer content.
}

If your objective is a complete replacement, you can simply return the new content.

If you want to preserve the existing value and append something to it, you can use the original argument instead:

function my_custom_admin_footer_text( $text ) {

    return $text . ' · Website managed by Example Agency';

}

add_filter(
    'admin_footer_text',
    'my_custom_admin_footer_text'
);

Whether replacement or augmentation is preferable depends on the purpose of the customization.

For a client-facing white-label interface, replacement may be cleaner. For a development environment where WordPress attribution should remain visible, appending information may make more sense.

Adding links and safe HTML to the admin footer

The footer can contain HTML, which makes it possible to add useful links instead of displaying plain text only.

For example:

function my_custom_admin_footer_text( $text ) {

    return 'Website managed by <a href="https://example.com/" target="_blank" rel="noopener">Example Agency</a>';

}

add_filter(
    'admin_footer_text',
    'my_custom_admin_footer_text'
);

The agency name now becomes clickable.

A more useful client implementation might link directly to support:

function my_custom_admin_footer_text( $text ) {

    return 'Need help? <a href="https://example.com/support/" target="_blank" rel="noopener">Contact Support</a>';

}

add_filter(
    'admin_footer_text',
    'my_custom_admin_footer_text'
);

For external-link behavior, see Why External Links Should Open in a New Tab. Whether another browsing context is appropriate should be an intentional UX decision rather than something added mechanically to every link.

Escape dynamic values according to context

Hard-coded trusted HTML and dynamically generated footer content are different situations.

If the agency name, URL or support destination comes from settings, database values or another configurable source, those values should be escaped appropriately when rendered.

The official WordPress escaping documentation recommends escaping output according to its context and doing so as late as practical.

For example:

function my_custom_admin_footer_text( $text ) {

    $agency_name = 'Example Agency';
    $agency_url  = 'https://example.com/';

    $footer = sprintf(
        'Website managed by <a href="%1$s" target="_blank" rel="noopener">%2$s</a>',
        esc_url( $agency_url ),
        esc_html( $agency_name )
    );

    return wp_kses_post( $footer );
}

add_filter(
    'admin_footer_text',
    'my_custom_admin_footer_text'
);

esc_url() handles the URL being placed in the href attribute, while esc_html() escapes the displayed text.

wp_kses_post() can then allow HTML supported in normal WordPress post content while removing disallowed markup.

Use a narrower allowlist when appropriate

If your footer should contain only links, you can define exactly which HTML is allowed instead of permitting the broader post-content set.

function my_custom_admin_footer_text( $text ) {

    $footer = 'Website managed by <a href="https://example.com/" target="_blank" rel="noopener">Example Agency</a>';

    $allowed_html = array(
        'a' => array(
            'href'   => true,
            'target' => true,
            'rel'    => true,
        ),
    );

    return wp_kses(
        $footer,
        $allowed_html
    );
}

add_filter(
    'admin_footer_text',
    'my_custom_admin_footer_text'
);

This communicates an even clearer security expectation: the footer is allowed to contain an anchor, not arbitrary HTML.

Useful WordPress admin footer text examples

The technical implementation is easy. Choosing useful footer content is the more interesting part.

For a basic agency attribution:

Website managed by Example Agency

For ongoing maintenance:

Website maintained by Example Agency

For client support:

Need help? Contact Website Support

For an internal company platform:

Acme Website Management System · Internal Use

For documentation:

Need help managing your website? View the Documentation

For a combined implementation:

Managed by Example Agency · Documentation · Support

The footer should remain concise because it appears throughout the administration area.

For a larger collection of agency-specific wording and white-label patterns, see WordPress Admin Footer Text Examples for Agencies.

The broader objective should be reducing friction for the person managing the site. Reducing WordPress Admin Confusion for Clients explores how footer text, navigation, Dashboard content and other backend decisions fit into that larger problem.

Show different footer text to different users

The footer does not have to be identical for everyone.

WordPress capabilities can be used to provide information relevant to the current user’s responsibilities.

The official current_user_can() function checks whether the current user has a particular capability.

For example:

function my_custom_admin_footer_text( $text ) {

    if ( current_user_can( 'manage_options' ) ) {
        return 'Technical administration · Example Agency Support';
    }

    if ( current_user_can( 'edit_posts' ) ) {
        return 'Need publishing help? View the Editorial Guide';
    }

    return 'Website Support';
}

add_filter(
    'admin_footer_text',
    'my_custom_admin_footer_text'
);

An administrator sees technical support information, while users who can edit content receive an editorial message.

Check capabilities instead of relying on role names

WordPress documentation recommends capability checks for authorization logic rather than assuming that a named role always represents the permissions you need.

Roles can be customized, plugins can create new roles and individual users can have modified capabilities.

For example:

if ( current_user_can( 'manage_options' ) ) {
    // User has the required capability.
}

expresses the requirement more directly than asking whether the user happens to have the role called administrator.

The distinction is explained in more depth in WordPress User Roles and Capabilities, Explained.

Role-aware customization can also be applied to other administration components. Customizing the WordPress Toolbar for Different Roles covers the same principle for toolbar navigation.

Changing the WordPress version and update footer

Replacing the main footer message does not modify the version or update information shown on the other side of the footer.

That content is filtered separately through update_footer.

For example:

function my_custom_update_footer( $content ) {

    return 'Managed WordPress Platform';

}

add_filter(
    'update_footer',
    'my_custom_update_footer',
    20
);

The official update_footer hook reference confirms that WordPress uses this filter for version and update text in the administration footer.

Changing visible version text is not security hardening

Removing a visible WordPress version from the administration footer does not conceal the fact that the website uses WordPress.

Attackers can identify WordPress installations using many other characteristics, including:

  • asset paths;
  • HTML patterns;
  • REST endpoints;
  • plugin assets;
  • theme assets;
  • login behavior;
  • HTTP responses;
  • public metadata.

For that reason, changing the footer version should be considered an interface or white-label decision, not a meaningful standalone security control.

See How Attackers Fingerprint WordPress Sites for the broader fingerprinting problem and Why Hide Your WordPress Version Number? for the limitations of version hiding.

Where should the admin footer customization live?

There are several places where developers could technically place the filter, but they are not equally appropriate.

A site-specific plugin

For functionality belonging to the website rather than its visual theme, a site-specific plugin is a strong option.

For example:

wp-content/
└── plugins/
    └── site-admin-customizations/
        └── site-admin-customizations.php

The plugin might contain:

<?php
/**
 * Plugin Name: Site Admin Customizations
 * Description: Customizes the WordPress administration interface.
 * Version: 1.0.0
 */

function site_custom_admin_footer_text( $text ) {

    return 'Website managed by Example Agency';

}

add_filter(
    'admin_footer_text',
    'site_custom_admin_footer_text'
);

This keeps the customization independent from the frontend theme.

A custom agency plugin

Agencies managing multiple client installations can place footer customization inside a reusable management or white-label plugin.

This has several advantages:

  • one implementation can be maintained centrally;
  • agency information can be configurable;
  • support links can follow the same structure;
  • role-specific behavior can be reused;
  • the customization survives theme changes.

This approach fits particularly well with the strategy described in Standardizing the WordPress Admin for Teams.

Theme functions.php

You can technically add the filter to a theme’s functions.php file:

add_filter( 'admin_footer_text', function( $text ) {
    return 'Custom footer';
} );

But the admin footer normally represents backend functionality rather than frontend presentation.

If the theme changes, the footer customization disappears.

For a one-off project this may be acceptable. For reusable agency functionality, a plugin is generally easier to maintain.

Do not edit wp-admin files

Avoid modifying files such as:

wp-admin/admin-footer.php

directly.

Those files belong to WordPress Core and can be replaced during updates.

The existence of admin_footer_text means there is no need to modify Core for this task.

Building a reusable configurable footer

A production implementation can separate configuration from rendering.

For example:

function agency_get_admin_footer_config() {

    return array(
        'name'        => 'Example Agency',
        'website_url' => 'https://example.com/',
        'support_url' => 'https://example.com/support/',
    );
}

function agency_admin_footer_text( $text ) {

    $config = agency_get_admin_footer_config();

    $footer = sprintf(
        'Website managed by <a href="%1$s" target="_blank" rel="noopener">%2$s</a> · <a href="%3$s" target="_blank" rel="noopener">Support</a>',
        esc_url( $config['website_url'] ),
        esc_html( $config['name'] ),
        esc_url( $config['support_url'] )
    );

    return wp_kses_post( $footer );
}

add_filter(
    'admin_footer_text',
    'agency_admin_footer_text'
);

The configuration could later come from:

  • a WordPress option;
  • environment-specific configuration;
  • a network setting;
  • an agency management plugin;
  • a client-specific configuration file.

The rendering function does not need to change simply because the agency name or support URL changes.

Make footer text translatable when distributing a plugin

If the customization belongs to a plugin distributed across multilingual installations, user-facing strings should be internationalized.

For plain text:

function my_custom_admin_footer_text( $text ) {

    return esc_html__(
        'Website managed by Example Agency',
        'my-plugin'
    );
}

For strings containing dynamic values, use WordPress internationalization functions together with appropriate escaping.

The official WordPress internationalization documentation covers text domains, translation functions and the broader localization workflow.

Admin footer customization in WordPress Multisite

Multisite introduces another dimension because one WordPress installation can contain many sites.

You may want:

  • the same agency footer across the entire network;
  • different footer text for individual sites;
  • a different message in Network Admin;
  • support information based on the current site;
  • different content depending on user capabilities.

A network-activated plugin can provide a consistent implementation across the installation.

Site-specific configuration can then determine the actual footer text.

For example:

function network_custom_admin_footer_text( $text ) {

    $site_name = get_bloginfo( 'name' );

    return sprintf(
        '%s · Managed Website',
        esc_html( $site_name )
    );
}

add_filter(
    'admin_footer_text',
    'network_custom_admin_footer_text'
);

If capability checks need to target a particular site, modern WordPress provides current_user_can_for_site().

This is preferable to older examples that still use current_user_can_for_blog(), which has been deprecated in modern WordPress.

How admin footer customization fits into a white-label backend

Changing the footer is usually only one small part of a customized administration experience.

A client-oriented backend may also change:

  • the login page;
  • the admin menu;
  • Dashboard widgets;
  • toolbar items;
  • admin typography;
  • menu spacing;
  • user permissions;
  • administration notices.

For the login experience, Branding the WordPress Login Screen for Clients explains how branding can begin before the user reaches the Dashboard.

For navigation, How to Reorganize the WordPress Admin Menu covers restructuring the menu around the user’s actual tasks.

If the navigation itself needs more space, How to Resize the WordPress Admin Menu covers width, typography, item height and responsive behavior.

For the Dashboard, Decluttering the WordPress Admin Dashboard explains how to remove unnecessary information and create a more focused starting point.

Toolbar customization is covered separately in How to Remove Items from the WordPress Admin Bar.

The important principle is that white-labeling should improve the interface rather than merely erase WordPress references.

A footer reading “Managed by Example Agency” provides context. A support link provides an action. A carefully simplified Dashboard reduces confusion.

Those changes are more useful than hiding WordPress branding without improving anything else.

Common mistakes when changing the admin footer

Editing WordPress Core

This is unnecessary and fragile.

Use admin_footer_text instead of changing wp-admin/admin-footer.php.

Hiding the footer with CSS

This:

#wpfooter {
    display: none;
}

does not change the footer text. It removes the footer visually.

If your objective is to replace the content, use the filter intended for that purpose.

Using CSS pseudo-elements to fake new text

Another workaround sometimes looks conceptually like:

#footer-thankyou {
    font-size: 0;
}

#footer-thankyou::after {
    content: "Managed by Example Agency";
    font-size: 13px;
}

This changes presentation while leaving the underlying content untouched.

It is harder to maintain, less semantic and unnecessary when WordPress already exposes a PHP filter.

Confusing the main footer with update_footer

admin_footer_text changes the main attribution area.

update_footer controls version and update information.

Use the correct filter for the content you actually want to modify.

Returning untrusted HTML without sanitization

If configurable values are inserted into the footer, escape URLs, text and attributes according to their output context.

Do not assume that data is safe simply because it is displayed inside wp-admin.

Making the footer excessively promotional

The footer is part of the client’s working environment.

Keep branding restrained and prioritize useful information such as support or documentation.

For practical agency wording, see WordPress Admin Footer Text Examples for Agencies.

Using visual customization as access control

Changing or hiding footer information does not affect permissions.

Likewise, hiding an administration element with CSS does not prevent a user from accessing functionality they are authorized to use.

Real access restrictions should rely on WordPress capabilities. WordPress User Roles and Capabilities, Explained covers that distinction.

Related guides

Final recommendation

The correct way to change the WordPress admin footer text is to use the admin_footer_text filter.

For a simple replacement, the entire customization can be as small as:

function my_custom_admin_footer_text( $text ) {

    return 'Website managed by Example Agency';

}

add_filter(
    'admin_footer_text',
    'my_custom_admin_footer_text'
);

For production websites, build on that foundation according to what the footer needs to accomplish.

If it contains links, escape URLs correctly and allow only the HTML you need. If different users require different information, use capability checks. If the footer is part of a reusable agency system, place the implementation in a plugin rather than tying it to the active frontend theme.

If you also want to modify the version or update area, use update_footer separately rather than trying to force both parts through the same filter.

Most importantly, use the customization to make the administration interface more useful.

A client does not benefit merely because the default WordPress message has disappeared. They benefit when the replacement tells them who manages the website, where documentation lives or how to obtain support.

That is the difference between cosmetic white-labeling and thoughtful administration customization.

Simplify your WordPress stack

A modular WordPress toolkit. 104 focused tools.

Ultimately, you can build cleaner workflows, maintain fewer plugins and enable only the features each website actually needs.