To add a field whose value can differ for each variation, render an input on each variation with the woocommerce_variation_options_inventory hook, then save it with woocommerce_save_product_variation, storing the value as metadata on that variation’s own ID. The method below follows WooCommerce’s official developer tutorial. Before writing code, decide whether the data is really a variation-defining choice, internal metadata, or an option shoppers fill in, because each needs a different approach.
Decide what kind of field you need
Three different requirements often get called “custom fields for variations.” Choosing the wrong one leads to code that saves data nobody can use, or to a shopper-facing choice that never reaches the cart.
As an Amazon Associate I earn from qualifying purchases.
| What you need | Right approach | Where the value lives | Covered in this guide |
|---|---|---|---|
| A choice that defines which variation is bought (for example, size or colour) | A product attribute used for variations | Attribute terms and the variation records that use them | No. WooCommerce describes attributes as a way to organise products around shared characteristics. |
| Extra item-specific data that staff maintain (for example, a supplier SKU or a warehouse bin) | Custom metadata saved through PHP hooks | Post metadata on each variation | Yes. This is the method described below. |
| An input a shopper enters or selects on the product page | A product-options extension | The extension’s own storage | Only as an alternative. See the extensions section. |
A field saved on the parent variable product is shared by every variation. A field saved on each child variation can hold a different value per variation. If the values must differ, save them on the variations, not the parent.
Add the field to each variation
The official example was written for WordPress 6.2 and WooCommerce 7.6.0, as documented in the WooCommerce Developer Documentation tutorial titled “How to add a custom field to simple and variable products.” Those releases are older than current ones, so treat them as a baseline and check hook behaviour against the WordPress and WooCommerce versions on your site.
#1 Best Overall
Render the input for each variation
- Open Products > All Products, edit a variable product, and open the Variations tab under Product data.
- Register a callback on
woocommerce_variation_options_inventory. The official example’s callback receives the loop index, the variation data, and the variation object. - Read the stored value for that variation and render the input with WooCommerce’s
woocommerce_wp_text_input()helper, so the field is prefilled when you edit. - Give the input a name indexed by the loop, such as
_custom_value[$loop], and use a metadata key that is unique to your plugin or theme.
Save the value against the variation ID
- Register a callback on
woocommerce_save_product_variation. Its arguments include the variation ID and the loop index. - Use the loop index to find the matching posted value, so each variation receives its own entry. Stop if the value is not present.
- Sanitise the value for its real type, load the variation with
wc_get_product(), update the metadata withupdate_meta_data(), and persist it withsave_meta_data().
Sanitise by data type
The official example uses sanitize_text_field() because its field is text. Text sanitisation is not enough for every field. Match the function to the data you expect.
| Field type | Suggested handling (standard WordPress functions) |
|---|---|
| Short text | sanitize_text_field(), as in the official example |
| Whole number | absint(), plus a check for the allowed range |
| Decimal number | floatval(), plus a check for the allowed range |
| Email address | sanitize_email(), then is_email() |
| URL | esc_url_raw() when saving, esc_url() when printing |
| Yes or no | Store only 'yes' or 'no'; anything else is rejected |
Complete example
The code below combines the two hooks and the functions named above. Replace the prefix fs_ and the metadata key _custom_value with names for your project. Test it on a staging site first.
Rank #2
<?php
// Render the field on each variation.
add_action( 'woocommerce_variation_options_inventory', 'fs_render_variation_field', 10, 3 );
function fs_render_variation_field( $loop, $variation_data, $variation ) {
$value = get_post_meta( $variation->ID, '_custom_value', true );
woocommerce_wp_text_input( array(
'id' => '_custom_value_' . $loop,
'name' => '_custom_value[' . $loop . ']',
'label' => 'Custom value',
'value' => $value,
'wrapper_class' => 'form-row form-row-full',
) );
}
// Save the field against the variation ID.
add_action( 'woocommerce_save_product_variation', 'fs_save_variation_field', 10, 2 );
function fs_save_variation_field( $variation_id, $loop ) {
if ( ! isset( $_POST['_custom_value'][ $loop ] ) ) {
return;
}
$value = sanitize_text_field( wp_unslash( $_POST['_custom_value'][ $loop ] ) );
$variation = wc_get_product( $variation_id );
if ( ! $variation ) {
return;
}
$variation->update_meta_data( '_custom_value', $value );
$variation->save_meta_data();
}Read the value back wherever you need it with wc_get_product( $variation_id ) and get_meta( '_custom_value' ). Keep the metadata key identical across rendering, saving, and display, or the value will appear to disappear.
Show the value on the storefront
Saving variation metadata does not place the value on the product page. WooCommerce’s tutorial notes that variable-product pages update only some content when a shopper selects a variation, and it points to the add-to-cart-variation.js file as an example of that behaviour. A separate official snippet shows how to read custom metadata and escape it with esc_html(), but that sample works at product level, not per variation.
To show a variation’s value when a shopper changes the selection, you need to pass the value to the front end with the variation data and update the page with JavaScript. Plan and test that work as its own step, because WooCommerce’s documentation does not provide a complete variation-aware display solution.
Use the REST API with care
WooCommerce’s v2 REST API documentation describes endpoints to create, retrieve, update, delete, and batch-manage variation resources. The v3 variation documentation covers retrieving a variation. A separate v3 endpoint lists the names of recorded custom fields.
None of these pages establishes that arbitrary custom metadata can be written or returned for every variation. Before relying on the API, confirm which WooCommerce API version you are calling, whether your metadata key is registered, and whether the response includes it. Test with a single variation before you automate a bulk update.
Free tools Windows power users keep installed
One-click scans. No signup required.
Customer-facing options from extensions
If the goal is to let shoppers add extra choices or input, a product-options extension is usually a better fit than custom metadata. These tools handle the product-page form, the cart, and the order record. They are not drop-in replacements for developer-managed variation metadata.
Dynamic Product Options
WooCommerce documents this extension for product-page fields, choices, and display rules. Variation is among the premium rule conditions it lists, so you can show options only for certain variations. Check the current feature list and compatibility with your WooCommerce version before you buy.
Product Options and Fields
WooCommerce documents this extension as allowing options attached to a specific variation. Those options appear when the shopper selects that variation. Confirm that the option type, the storage method, and the order output meet your needs before you rely on it.
WooCommerce’s custom fields documentation also points readers to its Marketplace for extensions and to Woo Agency Partners for advanced customisation. The documentation does not state current pricing, service suitability, or partner terms, so verify those directly with the vendors.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Troubleshooting
- The field appears on the parent product, not on each variation. You probably used a parent-product hook. Variation fields need
woocommerce_variation_options_inventory. - Values swap between variations. The input name and the save callback use different indexes. Use the same loop index in both, and check the posted array in your browser’s developer tools before saving.
- The value is not saved. Check that the input name matches the key you read in
$_POST, that the metadata key matches on save and read, and thatwc_get_product()returns an object. - The value saves but the shopper does not see it. This is expected. The save step stores data only. Display needs the separate front-end work described above.
- The code works on an older site but not on a newer one. The official example was written for WordPress 6.2 and WooCommerce 7.6.0. Check the hooks and admin markup on your installed versions and update the code if needed.
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.
