How to add custom fields in WordPress

Decide whether the value belongs to one post, page or custom post type. Examples include a subtitle, external URL, event date or product reference. Give the field a stable key such as event_date; do not change the key later unless you also migrate existing values.

Use a single text value where possible. WordPress stores arrays and objects as serialised data, which makes them harder to query and edit safely. Keys beginning with an underscore are treated as protected and are hidden from the standard Custom Fields list.

For a one-off or simple text value, edit the post or page and open the Custom Fields panel. In the block editor, select the three-dot Options menu, choose Preferences, enable Custom fields under Advanced, then reload the editor. Enter the key in Name, enter the value, and save the post.

The panel is fine for occasional values, but it has no tailored labels, validation or helpful input controls. It is also easy for an editor to mistype a key, creating a second field that your template will never read.

For a field used repeatedly, register it with register_post_meta() on the init hook. Set the post type, key, single to true, and the correct type, such as string, integer or boolean. Add show_in_rest when the block editor or REST API must read and write the value.

The post type must support custom-fields for registered post meta to work correctly. If you control a custom post type, include that support when registering it.

If the default panel is too awkward, create an admin meta box with add_meta_box() and attach it to the add_meta_boxes hook. Render a labelled input, select or textarea, and load the existing value with get_post_meta(). The meta box can target posts, pages or a named custom post type.

Put this code in a small site plugin or a child theme rather than editing a parent theme. The manual route gives you full control, but you must maintain the PHP, field markup, permissions and compatibility with the block editor yourself.

Save the submitted value on save_post, usually with update_post_meta(). Before saving, verify a nonce, check that the current user can edit the post, ignore autosaves and revisions, confirm the expected field exists, and sanitise it for its type. Use text sanitisation for plain text, URL sanitisation for URLs, and appropriate validation for dates or numbers.

A common Friday-afternoon failure is saving every save_post request without these checks. Autosaves, revisions and unrelated updates can overwrite a good value or save empty data.

Retrieve the value with get_post_meta( get_the_ID(), 'your_key', true ), then escape it for its output context. Use HTML escaping for text, attribute escaping inside an HTML attribute, and URL escaping for links. Do not print stored values directly.

If you need the value in a block or through the REST API, register it with show_in_rest. For block bindings, the field must also be registered for REST access and its key must not start with an underscore.