Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

To add a custom field to WordPress registration, render it in the form users actually submit, validate it before account creation, and save the cleaned value as user metadata after the user is created. A registration field does not automatically become an editable profile field: profile-screen output and saving are separate work.

Choose the registration workflow first

WordPress core, a custom theme form, a membership plugin, WooCommerce, and a custom API endpoint can all handle signup differently. The core login-page flow is documented around register_new_user(). Its hooks are not a universal guarantee for third-party forms, so use the extension points documented by the plugin or endpoint that owns your form.

Signup surface What to verify Where the value is normally stored
Core WordPress registration Use the core form’s rendering method and the registration_errors and user_register lifecycle hooks. User metadata (the usermeta table)
Custom theme or front-end form Confirm how the form creates users and attach validation and persistence to that implementation. User metadata after a user ID exists
Membership, ecommerce, or registration plugin Use its documented field and validation APIs; do not assume core hooks receive its submission. The plugin’s documented storage, often user metadata
REST or custom endpoint Validate and authorize the request in the endpoint, then write metadata deliberately. User metadata, optionally exposed through REST

Design the field contract

Before writing PHP, decide the meta key, data type, whether one value or multiple values are stored, and whether the field is required. Define the accepted format and behavior for an omitted or malformed value. Collect only data the site needs, and avoid putting sensitive information into a broadly exposed profile field.

WordPress stores essential account columns in its users table and arbitrary additional values in user metadata. As the Plugin Handbook explains, “Because of this, to store additional data, the usermeta table was introduced, which can store any arbitrary amount of data about a user.” See Working with User Metadata.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Add a field to the core registration form

The following example adds a required “Company” input to the core registration form. Put it in a small custom plugin rather than a theme’s functions.php if the field should survive a theme change.

<?php
// Render the field in the core registration form.
add_action( 'register_form', function () {
    $value = isset( $_POST['company_name'] )
        ? sanitize_text_field( wp_unslash( $_POST['company_name'] ) )
        : '';
    ?>
    <p>
        <label for="company_name">Company<br>
            <input type="text" name="company_name" id="company_name"
                   class="input" value="<?php echo esc_attr( $value ); ?>"
                   size="25" required>
        </label>
    </p>
    <?php
} );

Rendering only creates an input. It does not validate or save anything, and client-side required is not a security boundary.

Validate before WordPress creates the account

For core registration, use registration_errors. It receives a WP_Error object before user information is saved; adding an error aborts account creation. Always return the object, including when the submitted value is valid. WordPress describes this filter as one that “can be used to create custom validation rules on user registration” in its hook reference.

add_filter( 'registration_errors', function ( $errors, $sanitized_user_login, $user_email ) {
    $company = isset( $_POST['company_name'] )
        ? sanitize_text_field( wp_unslash( $_POST['company_name'] ) )
        : '';

    if ( '' === $company ) {
        $errors->add(
            'company_name_required',
            __( '<strong>Error:</strong> Please enter your company name.', 'my-plugin' )
        );
    } elseif ( mb_strlen( $company ) > 120 ) {
        $errors->add(
            'company_name_too_long',
            __( '<strong>Error:</strong> Company names must be 120 characters or fewer.', 'my-plugin' )
        );
    }

    return $errors;
}, 10, 3 );

Use the validation rule that matches the field’s contract: for example, a strict allow-list for a role-like value, a format check for an identifier, or a length limit for free text. Sanitize for the intended storage format, but do not treat sanitization as a substitute for validation.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Save the value after successful registration

Once WordPress has created the account, save the value against the new user ID with update_user_meta(). The user_register action is commonly used for additional metadata passed by custom registration forms, as documented at user_register.

add_action( 'user_register', function ( $user_id ) {
    if ( ! isset( $_POST['company_name'] ) ) {
        return;
    }

    $company = sanitize_text_field( wp_unslash( $_POST['company_name'] ) );

    if ( '' !== $company ) {
        update_user_meta( $user_id, 'company_name', $company );
    }
} );

The hook reference cautions that not all user metadata has necessarily been stored when user_register fires. Save the value your code owns there, and do not assume every other profile property is already populated. If a plugin creates the account through a different process, use that plugin’s post-registration event instead.

Make the field editable in wp-admin

Signup capture and later profile editing are separate features. For the user’s own profile, output the field on show_user_profile; for an administrator editing another user, use edit_user_profile. Save both screens through their corresponding personal-options and profile-update hooks.

function my_company_profile_field( $user ) {
    ?>
    <h2>Additional information</h2>
    <table class="form-table">
        <tr>
            <th><label for="company_name">Company</label></th>
            <td>
                <input type="text" name="company_name" id="company_name"
                       value="<?php echo esc_attr( get_user_meta( $user->ID, 'company_name', true ) ); ?>"
                       class="regular-text">
            </td>
        </tr>
    </table>
    <?php
}
add_action( 'show_user_profile', 'my_company_profile_field' );
add_action( 'edit_user_profile', 'my_company_profile_field' );

function my_save_company_profile_field( $user_id ) {
    if ( ! current_user_can( 'edit_user', $user_id ) ) {
        return;
    }

    if ( isset( $_POST['company_name'] ) ) {
        update_user_meta(
            $user_id,
            'company_name',
            sanitize_text_field( wp_unslash( $_POST['company_name'] ) )
        );
    }
}
add_action( 'personal_options_update', 'my_save_company_profile_field' );
add_action( 'edit_user_profile_update', 'my_save_company_profile_field' );

The profile hooks and metadata workflow are covered in WordPress’s user-metadata documentation. A front-end account page needs its own permission check, nonce, validation, and metadata update; users do not need wp-admin access for a custom account editor.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Register metadata and decide on REST exposure

register_meta( 'user', ... ) documents the value’s type, whether it is single or multiple, sanitization, authorization, and REST behavior. For example:

register_meta( 'user', 'company_name', array(
    'type'              => 'string',
    'single'            => true,
    'sanitize_callback' => 'sanitize_text_field',
    'auth_callback'     => function () {
        return current_user_can( 'edit_users' );
    },
    'show_in_rest'      => false,
) );

Set show_in_rest to true only when the value should be available through the REST API, and define an appropriate schema and authorization policy. Making a field visible or writable through an API can expose profile information beyond the intended audience.

When a REST response needs custom read or update callbacks, or a representation that is not simply registered meta, use register_rest_field instead. The REST Handbook explains both approaches in Modifying Responses; the metadata API details are in register_meta().

Security and reliability checklist

  • Confirm which form actually creates the user before selecting hooks.
  • Validate on the server before creation; browser validation alone is insufficient.
  • Use a stable, namespaced meta key and a clearly defined type.
  • Uns lash request values before sanitizing them, and escape values when printing them into HTML.
  • Use capability checks, nonces, and authorization callbacks for profile-edit screens and REST updates.
  • Save metadata only after a valid user ID exists.
  • Test required, empty, malformed, overlong, duplicate-submission, and permission-denied cases.
  • Decide explicitly whether the field is private, administrator-visible, front-end editable, or REST-exposed.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Common failure modes

The field appears but is always blank after signup

The input was rendered, but no post-registration code saved it, or the code is attached to a hook that the actual form never fires. Verify the form owner and inspect the saved value with get_user_meta( $user_id, 'company_name', true ).

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Invalid registrations still succeed

Validation may be running after account creation, or the callback may not return the WP_Error object. For core registration, add errors through registration_errors before creation and return the object every time.

The value saves but cannot be edited

Persistence does not create a profile UI. Add the wp-admin profile hooks or build a separately authorized front-end editor.

A plugin registration form ignores the code

The plugin may bypass the core registration path. Follow its documented rendering, validation, and after-create hooks rather than assuming register_form or user_register receives every submission.

Implementation decision guide

  • Core login-page signup: render the input, validate with registration_errors, and save with user_register.
  • Plugin-owned signup: use the plugin’s documented field and lifecycle APIs, then store in user metadata if that is its supported model.
  • Admin-only editing: add show_user_profile/edit_user_profile output and the matching save hooks.
  • Front-end editing: create a protected account form with nonce, capability or ownership checks, server validation, and update_user_meta().
  • API consumers: register metadata with deliberate type, schema, authorization, and REST visibility, or expose a custom field with register_rest_field.

The Bottom Line

A dependable WordPress registration field has four distinct parts: form rendering, pre-save validation, post-creation metadata storage, and—if needed—separate profile editing or REST exposure. Match each part to the system that actually handles your site’s signup flow.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.