How to customize the WordPress login page

Customizing the WordPress login page can turn the default wp-login.php screen into an interface that feels like a deliberate part of the website rather than a separate piece of WordPress administration.

A customized login screen can include:

• a custom logo;
• brand colors;
• custom typography;
• a different page background;
• restyled form fields and buttons;
• custom messages;
• a different logo destination;
• additional information for users;
• a layout designed specifically for clients, members or customers.

WordPress provides dedicated hooks for the login environment, so these changes can be implemented without editing wp-login.php itself.

That distinction matters.

The login file belongs to WordPress Core. Editing it directly creates an implementation that can be overwritten by updates and is unnecessarily difficult to maintain.

A better architecture is:

WordPress login page
        +
login-specific hooks
        +
custom CSS / assets
        +
optional filters
        =
custom login experience

This guide explains how the WordPress login page works, how to customize its logo, colors, background, typography, form, buttons, messages and links, which hooks should be used, how to keep the implementation maintainable, and where login-page design ends and authentication security begins.

How the WordPress login page works

The standard WordPress authentication screen is generated by:

/wp-login.php

The official WordPress login documentation identifies wp-login.php as the standard login endpoint.

A visitor can normally reach it directly:

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

and visiting:

https://example.com/wp-admin/

while logged out normally redirects the visitor into the authentication flow.

The same login environment also handles related actions such as:

• authentication;
• password recovery;
• registration when enabled;
• logout;
• password reset;
• privacy-related confirmation flows;
• recovery mode.

This is important when writing custom CSS because the login page is not always displaying exactly the same form.

WordPress adds action-specific body classes

The login page receives classes that reflect its current action.

WordPress also exposes the login_body_class filter, which allows developers to add their own body classes.

That makes targeted styling possible.

For example:

add_filter( 'login_body_class', function( $classes ) {
    $classes[] = 'brand-login';
    return $classes;
} );

You can then target:

body.brand-login {
    background: #f5f5f5;
}

without affecting the public website or WordPress administration screens.

The login page has its own asset-loading context

Frontend styles registered through wp_enqueue_scripts should not be assumed to exist automatically on the login screen.

WordPress provides a dedicated hook:

login_enqueue_scripts

The official WordPress Developer Reference identifies it as the appropriate hook for enqueueing scripts and styles on login and registration-related screens.

This gives the login page a clean separation from:

frontend
wp-admin
block editor
login screen

For a deeper look at WordPress login extension points, see WordPress Login Hooks Explained.

Do not edit wp-login.php directly

Technically, a developer could open:

/wp-login.php

and change its HTML, CSS or PHP.

That is not a sensible customization strategy.

wp-login.php is part of WordPress Core.

A WordPress update can replace that file, which means direct modifications can disappear.

Direct Core edits also make it harder to:

• track customizations;
• test WordPress updates;
• move the customization between sites;
• debug conflicts;
• separate application code from Core code.

Use hooks, filters, stylesheets and plugins instead.

Where should login customization code live?

There are several reasonable options.

For a site-specific implementation, customization can live in:

• a custom plugin;
• a site-specific functionality plugin;
• a child theme;
• a managed snippet system.

A theme can be acceptable when the login design genuinely belongs to that theme.

However, client branding and administrative functionality often survive theme changes. In those cases, a plugin or site-specific module is usually a cleaner location.

How to load custom CSS on the WordPress login page

The recommended starting point is login_enqueue_scripts.

Create a login stylesheet and enqueue it only where it is needed:

function project_login_assets() {

    wp_enqueue_style(
        'project-login',
        get_stylesheet_directory_uri() . '/assets/css/login.css',
        array(),
        '1.0.0'
    );
}

add_action(
    'login_enqueue_scripts',
    'project_login_assets'
);

The login screen can now have its own stylesheet:

/assets/css/login.css

This is preferable to loading an entire frontend stylesheet containing rules for:

• navigation;
• footers;
• page builders;
• sliders;
• cards;
• WooCommerce components;
• animations;
• other unrelated frontend elements.

Keep login CSS isolated

The login page is a small interface.

Its stylesheet can usually remain compact and purpose-built.

A basic structure might be:

body.login {
    background: #f5f5f5;
}

.login #login {
    width: 360px;
}

.login form {
    border: 0;
    border-radius: 12px;
    box-shadow: 0 12px 40px rgba(0, 0, 0, 0.08);
}

.login .button-primary {
    border-radius: 8px;
}

The exact selectors should always be tested against the current WordPress login markup rather than copied indefinitely from an old tutorial.

login_head also exists, but it serves a broader purpose

WordPress exposes the login_head action after login scripts and styles have been enqueued.

It can be used to insert content into the login document’s <head>.

For stylesheet loading, however, login_enqueue_scripts is the more appropriate asset API.

Customizing the logo, background and form

The most visible login-page customization is usually replacing the default WordPress branding with the website or client’s identity.

Replace the WordPress logo

A custom logo can be applied through login-specific CSS.

For example:

.login h1 a {
    background-image: url("../images/login-logo.svg");
    background-size: contain;
    background-position: center;
    background-repeat: no-repeat;

    width: 220px;
    height: 80px;
}

Use an appropriately optimized asset rather than uploading an enormous image and shrinking it through CSS.

SVG can be useful for logos where the project’s security and upload configuration permits it. Optimized raster formats can also work perfectly well.

Change the logo destination

Changing the visible logo without changing its link can create an odd experience: the client sees their company logo but clicking it takes them somewhere unrelated to that brand.

WordPress provides the login_headerurl filter for this purpose.

function project_login_logo_url() {
    return home_url( '/' );
}

add_filter(
    'login_headerurl',
    'project_login_logo_url'
);

The logo can now lead back to the website.

Change the accessible logo text

WordPress also provides:

login_headertext

The official hook documentation describes it as the filter for the link text associated with the login header logo.

function project_login_logo_text() {
    return get_bloginfo( 'name' );
}

add_filter(
    'login_headertext',
    'project_login_logo_text'
);

Older tutorials may still reference:

login_headertitle

but that hook has been deprecated in favor of login_headertext.

Customize the page background

A simple brand background can be created with CSS:

body.login {
    background:
        linear-gradient(
            135deg,
            #111111 0%,
            #252525 100%
        );
}

Or use a background image:

body.login {
    background-image:
        url("../images/login-background.webp");

    background-size: cover;
    background-position: center;
    background-repeat: no-repeat;
}

Be careful with large decorative images.

The login page should remain fast even on:

• mobile connections;
• older devices;
• remote client networks;
• poor Wi-Fi;
• administrative environments where the visual background provides no functional benefit.

Restyle the login card

The form itself can be visually separated from the background:

.login form {
    padding: 32px;

    background: #ffffff;

    border: 0;
    border-radius: 16px;

    box-shadow:
        0 20px 60px
        rgba(0, 0, 0, 0.12);
}

Keep sufficient contrast between the form and its surrounding background.

The WCAG guidance on text contrast remains relevant even though the login screen is not part of the public marketing site.

Customize fields, buttons and typography

Once the overall layout is established, the smaller interface components can be aligned with the site’s design system.

Style input fields

For example:

.login input[type="text"],
.login input[type="password"],
.login input[type="email"] {
    min-height: 48px;

    padding: 10px 14px;

    border: 1px solid #d8d8d8;
    border-radius: 8px;

    background: #ffffff;
}

Do not remove visible focus states merely because they conflict with the visual design.

Keyboard users need to know which control currently has focus.

A custom focus treatment might be:

.login input:focus {
    border-color: #111111;

    box-shadow:
        0 0 0 2px
        rgba(17, 17, 17, 0.15);

    outline: none;
}

Customize the login button

The primary button can follow the brand system:

.login .button-primary {
    min-height: 44px;

    padding: 0 20px;

    border: 0;
    border-radius: 8px;

    font-weight: 600;
}

Remember to define hover and focus states as well.

.login .button-primary:hover,
.login .button-primary:focus {
    filter: brightness(0.92);
}

Use custom typography carefully

The login screen can use the same font family as the public site, but that does not mean the entire frontend typography stack should be loaded into wp-login.php.

Load only the font resources actually required by the login interface.

For a detailed comparison of font-delivery strategies, see Self-Hosted Fonts vs. Google Fonts in WordPress.

If the login screen specifically uses Google Fonts, see Choosing Google Fonts for a WordPress Login Page.

A small authentication screen rarely needs:

300
400
500
600
700
800
900

for a single family.

Usually one or two carefully selected weights are enough.

Customize login messages and supporting content

Visual customization is only one part of the login experience.

WordPress also allows developers to change or add contextual content.

Add a message above the login form

The login_message filter modifies the message displayed above the login form.

For example:

function project_login_message( $message ) {

    if ( ! empty( $message ) ) {
        return $message;
    }

    return '<p class="project-login-message">'
        . esc_html__(
            'Sign in to manage your website.',
            'project'
        )
        . '</p>';
}

add_filter(
    'login_message',
    'project_login_message'
);

This can be useful for:

• client instructions;
• membership information;
• support contact guidance;
• environment warnings;
• staging-site identification.

Do not expose sensitive information

A login message is publicly visible to anyone who can reach the login page.

Do not put information there such as:

• administrator usernames;
• internal infrastructure details;
• private support credentials;
• security configuration;
• information useful for account enumeration.

Login messaging should improve usability without disclosing unnecessary operational information.

Error messages are a separate concern

WordPress also exposes authentication errors through dedicated filtering.

Before changing those messages for aesthetic reasons, understand what information they communicate to legitimate users and potential attackers.

See WordPress Login Error Messages, Explained for the security and usability implications.

The login shake animation can also be changed

WordPress may apply a shake animation after certain login errors.

If the project requires a calmer interface or has specific motion-accessibility requirements, that behavior can be modified separately.

See How to Disable the WordPress Login Shake Animation.

Build a complete custom login implementation

A maintainable implementation separates PHP behavior from CSS presentation.

For example, a site-specific plugin could contain:

/project-login/
    project-login.php
    assets/
        css/
            login.css
        images/
            logo.svg
            background.webp

PHP

<?php

/**
 * Plugin Name: Project Login Branding
 * Description: Customizes the WordPress login screen.
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}


/**
 * Login assets.
 */
function project_login_assets() {

    wp_enqueue_style(
        'project-login',
        plugin_dir_url( __FILE__ )
            . 'assets/css/login.css',
        array(),
        '1.0.0'
    );
}

add_action(
    'login_enqueue_scripts',
    'project_login_assets'
);


/**
 * Logo destination.
 */
function project_login_logo_url() {
    return home_url( '/' );
}

add_filter(
    'login_headerurl',
    'project_login_logo_url'
);


/**
 * Accessible logo text.
 */
function project_login_logo_text() {
    return get_bloginfo( 'name' );
}

add_filter(
    'login_headertext',
    'project_login_logo_text'
);


/**
 * Custom body class.
 */
function project_login_body_class( $classes ) {

    $classes[] = 'project-login';

    return $classes;
}

add_filter(
    'login_body_class',
    'project_login_body_class'
);

CSS

body.project-login {
    display: flex;
    align-items: center;

    min-height: 100vh;

    background: #f4f4f4;
}

.project-login #login {
    width: min(400px, calc(100% - 32px));

    padding: 0;
}

.project-login h1 a {
    width: 220px;
    height: 72px;

    background-image:
        url("../images/logo.svg");

    background-size: contain;
    background-position: center;
    background-repeat: no-repeat;
}

.project-login form {
    padding: 32px;

    border: 0;
    border-radius: 14px;

    background: #ffffff;

    box-shadow:
        0 20px 60px
        rgba(0, 0, 0, 0.08);
}

.project-login input[type="text"],
.project-login input[type="password"] {
    min-height: 48px;

    border-radius: 8px;
}

.project-login .button-primary {
    min-height: 44px;

    border: 0;
    border-radius: 8px;
}

This approach keeps the customization independent from WordPress Core and makes it easier to:

• version the implementation;
• deploy it to staging;
• test WordPress updates;
• reuse it across projects;
• disable it without touching Core;
• keep the active theme independent from administrative branding.

For agencies maintaining many installations, this separation becomes especially useful.

Plugin-based customization vs. custom code

You do not have to build every login page manually.

There are three broad approaches:

custom code
plugin/module
fully custom authentication interface

Custom code

Custom code provides precise control and keeps the implementation small when requirements are limited.

It is suitable when you need:

• a custom logo;
• a few brand colors;
• specific CSS;
• a custom message;
• a custom logo URL;
• a small number of predictable modifications.

A dedicated customization module

A dedicated module becomes useful when non-developers need to configure:

• logos;
• backgrounds;
• form colors;
• typography;
• button styling;
• spacing;
• layout options.

TheOneWP provides a dedicated Custom Login Page feature for managing login-page customization without building the entire interface manually.

This is especially useful when login branding needs to be treated as configuration rather than hardcoded project CSS.

A completely custom login form is a different project

Sometimes the requirement is not:

restyle wp-login.php

but:

build a login form inside the website

WordPress provides the official wp_login_form() function for rendering a login form elsewhere in WordPress.

That approach can make sense for:

• membership portals;
• customer areas;
• private communities;
• front-end dashboards;
• applications where users should never interact directly with wp-admin.

But building a front-end login experience introduces more responsibility around redirects, errors, password recovery, registration, authentication flows and compatibility.

Do not replace the native login page merely because the default page is visually plain.

Login branding and login security are different layers

A customized login page can look completely different while using exactly the same WordPress authentication system underneath.

Changing:

• the logo;
• background;
• button color;
• font;
• form radius;
• spacing;

does not make a password harder to guess.

Likewise, changing the login URL does not customize the visual design by itself.

Changing the login URL is a separate operation

If the objective is to replace the predictable public login address, see How to Change the WordPress Login URL.

And before treating that as a complete security solution, see Does Hiding wp-login.php Actually Help Security?.

A custom URL can reduce unwanted automated traffic against the default endpoint, but it does not replace authentication controls.

Security needs multiple layers

A stronger login architecture may combine:

• strong unique passwords;
• rate limiting;
• two-factor authentication;
• login monitoring;
• careful user-role management;
• controlled account access;
• appropriate session security;
• optional login endpoint changes.

See WordPress Login Security Layers, Explained for the complete model.

For an implementation-oriented review, use A WordPress Login Hardening Checklist.

Rate limiting still matters on a branded login page

A beautiful custom login form can still receive automated authentication attempts.

See How to Limit Login Attempts in WordPress for the protection layer designed specifically around repeated attempts.

TheOneWP’s Access Manager can also provide controls around login access and attempt management, while Two-Factor Authentication adds an additional authentication factor.

Design the login page for the people who actually use it

The correct amount of customization depends heavily on the site.

A personal WordPress site

If one administrator sees the login screen a few times per month, extensive visual customization may provide little practical value.

A logo and a small amount of styling may be enough.

A client website

For an agency-managed website, the login page can be the client’s first interaction with the administrative environment.

Branding can make the transition from:

company website
→ authentication
→ WordPress administration

feel intentional rather than disconnected.

For that use case, see Branding the WordPress Login Screen for Clients.

A membership site

A membership site’s login screen may be visited by hundreds or thousands of non-technical users.

In that situation, prioritize:

• clarity;
• mobile usability;
• accessible focus states;
• helpful errors;
• password recovery;
• consistent branding;
• fast loading.

The login page becomes part of the product experience rather than merely an administrative utility.

An ecommerce site

If customers authenticate through WooCommerce account flows, determine which authentication interface customers actually see before spending time customizing wp-login.php.

The correct interface to customize is the one real users encounter.

Test the complete login lifecycle

A login customization is not finished when the main sign-in form looks correct.

Test the complete authentication lifecycle.

Normal login

Verify:

• username or email input;
• password input;
• Remember Me;
• submit button;
• keyboard navigation;
• focus styles;
• successful redirect.

Incorrect credentials

Check that error messages:

• remain readable;
• do not overflow the form;
• have sufficient contrast;
• do not break the layout.

Lost password

Test:

wp-login.php?action=lostpassword

A stylesheet designed only around the normal login form can easily produce awkward spacing on the recovery screen.

Password reset

Test the complete reset process rather than only the initial email-request form.

Registration

If public registration is enabled, verify the registration action as well.

Logout

Confirm that logout messages and navigation remain visible and correctly styled.

Recovery Mode

WordPress can use the login environment during Recovery Mode.

A highly aggressive CSS override should not make emergency access harder when the site is already experiencing a problem.

Mobile devices

Test narrow screens rather than assuming a desktop form scaled down automatically.

At minimum check:

• 320 to 375 pixel widths;
• input sizing;
• button tap targets;
• logo dimensions;
• background cropping;
• password visibility controls;
• long translated strings;
• virtual keyboard behavior.

A login page should remain functional before it remains decorative.

WordPress login customization checklist

• Do not edit wp-login.php directly.
• Use login_enqueue_scripts for login-specific styles and scripts.
• Keep login assets separate from unnecessary frontend assets.
• Replace the default logo with an optimized brand asset where appropriate.
• Use login_headerurl to control the logo destination.
• Use login_headertext for appropriate accessible link text.
• Use login_body_class when a dedicated CSS namespace helps.
• Maintain visible keyboard focus states.
• Maintain sufficient text and control contrast.
• Keep form controls large enough for touch interaction.
• Optimize large background images.
• Load only required font families and weights.
• Use login_message carefully for public-facing instructions.
• Do not expose sensitive information in login messages.
• Test normal authentication.
• Test invalid credentials.
• Test password recovery.
• Test password reset.
• Test registration when enabled.
• Test logout.
• Test Recovery Mode compatibility.
• Test the interface on mobile devices.
• Test translated login screens if the site is multilingual.
• Keep visual customization separate from security configuration.
• Use rate limiting and additional authentication controls where appropriate.
• Retest the customized page after significant WordPress updates.

Related guides

• Branding the WordPress Login Screen for Clients
• Choosing Google Fonts for a WordPress Login Page
• WordPress Login Hooks Explained
• How to Change the WordPress Login URL
• WordPress Login Security Layers, Explained
• A WordPress Login Hardening Checklist

Final recommendation

The WordPress login page is designed to be extended. There is usually no reason to modify wp-login.php directly just to create a branded authentication experience.

Use WordPress’s login-specific hooks to separate behavior cleanly:

login_enqueue_scripts
→ styles and scripts

login_headerurl
→ logo destination

login_headertext
→ accessible logo text

login_body_class
→ custom CSS targeting

login_message
→ contextual messaging

login_head / login_footer
→ additional extension points

Keep the visual layer similarly focused. Customize the logo, background, typography, form and controls without importing an entire frontend design system into a page that only needs a small authentication interface.

For client websites and membership platforms, the login screen deserves more attention because it becomes a recurring user-facing interface. In those cases, consistent branding, responsive design, accessibility and clear messaging can materially improve the experience.

But visual customization should never be confused with authentication security.

A custom logo does not stop brute-force attempts. A different background does not protect compromised credentials. Even changing the login URL is only one possible layer rather than a replacement for strong passwords, rate limiting, monitoring and two-factor authentication.

The strongest implementation treats the login screen as two connected systems:

Login experience
=
branding
+ usability
+ accessibility

Login security
=
credentials
+ rate limiting
+ access controls
+ additional authentication
+ monitoring

Customize the first without weakening the second.