Custom Fields in WordPress: Native Fields vs ACF vs Block Bindings

“Custom fields” in WordPress can mean three genuinely different things depending on when you learned WordPress: the native meta box from 2005, Advanced Custom Fields, or block bindings, the newest Gutenberg-native approach. Confusing them leads to picking the wrong tool for a simple job.

Native Custom Fields: The Original, Barebones Version

WordPress has shipped a native Custom Fields meta box since its earliest versions: a simple key-value pair UI in the post editor. It’s functional but has no field types (everything is plain text), no validation, and by default is hidden in the block editor unless re-enabled from the editor’s options panel. It’s rarely used directly today except for very simple, one-off data.

Advanced Custom Fields (ACF): The Long-Standing Standard

ACF built an entire visual field-builder UI on top of the native custom fields system: text, image, repeater, relationship, and many other field types, assignable to specific post types or conditions. It became the de facto standard for structured content in WordPress, and most “custom fields” discussions online implicitly mean ACF. The free version covers most field types; ACF Pro adds Repeater, Flexible Content, and Options Pages.

Also Read: Nexter Blocks Repeater: How to Build Dynamic Layouts with ACF and JetEngine — ACF’s Repeater field type specifically, connected to a real block-based frontend.

Block Bindings: The Native, Gutenberg-First Alternative

Block Bindings, added to WordPress core, connects a block’s attribute (an image’s URL, a paragraph’s text) directly to a custom field value, without needing ACF as an intermediary for the connection itself. Registering the field and the binding is code, not a visual builder:

// Register the underlying meta field
function register_product_sku_meta() {
    register_post_meta('post', 'product_sku', [
        'show_in_rest' => true,
        'single'       => true,
        'type'         => 'string',
    ]);
}
add_action('init', 'register_product_sku_meta');

Once registered, a paragraph block’s content (or another supported attribute) can be bound to that product_sku meta field directly from the block editor’s own binding UI — no ACF field group needed for the connection itself. It’s native, requires no additional plugin for the binding mechanism, and is designed to work naturally with block themes. The tradeoff: it’s newer, has a narrower set of supported block attributes than ACF’s mature field-type library, and the registration process above is more code-oriented than ACF’s visual field builder.

Side-by-Side, at a Glance

Which to Actually Use

• Simple, one-off data on a handful of posts — native custom fields are enough; installing ACF for one field is overkill.
• Structured content at any real scale (repeaters, relationships, options pages, conditional field logic) — ACF remains the most mature, widely-supported option.
• A pure block-theme build where you want to avoid an extra plugin dependency for simple attribute binding — Block Bindings is worth using directly, if your WordPress version and block attribute needs support it.

Also Read: What Is a Custom Post Type in WordPress? — custom fields and custom post types are commonly paired but solve different problems; this explains the distinction.

Conclusion

None of these three replaces the others outright — native fields for the simplest cases, ACF for mature, large-scale structured content, and Block Bindings for a lighter-weight, block-native connection where your build allows it. Picking based on project scale rather than habit avoids both over-engineering a simple site and under-powering a complex one.

FAQ

Do I need ACF if I’m using Block Bindings?

Not necessarily for the binding mechanism itself, but ACF can still register the underlying custom fields with a friendlier UI than manual code, and many sites use both together.

Are native custom fields still relevant?

For simple, low-volume data, yes — they add zero plugin overhead. For anything more structured, ACF or Block Bindings are almost always a better fit.

Will Block Bindings eventually replace ACF?

Not clearly, at least not soon — ACF’s field-type library and visual builder remain considerably more mature; Block Bindings is a newer, narrower, core-native mechanism rather than a full ACF replacement today.

Do I need to write PHP to use Block Bindings at all?

Yes, currently — registering the underlying meta field with register_post_meta() is a code step; there’s no purely visual equivalent to ACF’s field-group builder for this yet.

Suggested Reading

• Nexter Blocks Repeater: How to Build Dynamic Layouts with ACF and JetEngine
• What Is a Custom Post Type in WordPress?
• WPML vs Polylang vs TranslatePress: Which WordPress Translation Plugin Should You Use?