Advanced Custom Fields has been the default answer to “how do I add custom fields in WordPress” for over a decade. That default got a real challenger in WordPress 6.5, when the Block Bindings API shipped as a native way to connect custom field data to core blocks without installing a single plugin. So the ACF vs Block Bindings question is not academic anymore: it’s a real decision on every new WordPress build.
The honest answer is that both are right, just for different jobs. Block Bindings is not a full ACF replacement yet, but it’s also not a toy. Knowing exactly where the line sits saves you from installing a plugin you don’t need, or from fighting core WordPress to do something it still can’t.
What Is the WordPress Block Bindings API?
The Block Bindings API is a native WordPress feature, introduced in WordPress 6.5, that connects custom field values directly to core blocks like Paragraph, Heading, Image, and Button, with no plugin required. A block binding doesn’t store the value inside the block itself, it stores a reference to a data source, so updating the source updates every block using it automatically.
In practice, that means a value like a price, an event date, or a product SKU can live in post meta, and any bound block on the front end just displays whatever that meta field currently holds. Change the meta value once, and every block referencing it updates without touching the block markup again. This is part of the same shift covered in Do You Still Need a WordPress Child Theme in 2026?, where native WordPress features keep absorbing jobs that used to require a plugin.
Setting up a binding starts with registering the custom field in code. A typical setup in a theme’s functions.php file looks like this:
function moshiur_register_event_price_meta() {
register_post_meta( 'post', 'event_price', array(
'show_in_rest' => true,
'single' => true,
'type' => 'string',
) );
}
add_action( 'init', 'moshiur_register_event_price_meta' );Once the meta field is registered, a Paragraph block can bind to it directly in the block markup, and the value shows up automatically wherever that binding is used, without a shortcode or a template edit.
What Does ACF Do That Block Bindings Doesn’t?
Advanced Custom Fields covers structured content types that Block Bindings has no equivalent for: repeaters, flexible content layouts, image galleries, relationship fields, and a visual field-builder interface that non-technical editors can use without touching code. ACF also ships with conditional logic, so fields can show or hide based on what an editor selects elsewhere in the same form, something the native API doesn’t offer at all.
ACF is also still one of the most widely used plugins in the entire WordPress ecosystem. According to the official ACF plugin page on WordPress.org, the plugin is “proudly powering over 2 million sites.” That scale is exactly why so many themes, page builders, and other plugins already assume ACF is installed and build integrations around it.
The free version of ACF covers most of this. ACF PRO, a paid upgrade, adds the Repeater field, Flexible Content field, Gallery field, options pages, and ACF Blocks, which let you build custom Gutenberg blocks entirely through the ACF interface instead of writing React.
ACF vs Block Bindings: Feature Comparison
The table below lines up the two options side by side. Neither one wins outright, the right choice depends entirely on what the field needs to do and who needs to edit it.
| Feature | ACF | Block Bindings API |
|---|---|---|
| Cost | Free core plugin, Pro from a paid license | Free, built into WordPress core |
| Setup | Visual UI, little to no code | Requires PHP in functions.php or a plugin |
| Field types | 30+, including repeater, gallery, relationship | Any registered meta, but limited to simple text/image values |
| Supported blocks | Any location: posts, pages, custom post types, users, options pages | Paragraph, Heading, Button, Image (expanding over time) |
| Custom Gutenberg blocks | Yes, via ACF Blocks (Pro) | No built-in block-building tool |
| Best for | Non-technical editors, complex structured content | Developers comfortable with code, simple field-to-block links |
Do You Still Need ACF in WordPress?
Yes, for most real client sites ACF is still worth installing, because Block Bindings only covers a narrow slice of what structured content actually requires. Block Bindings is best treated as a lightweight, native option for simple cases, not a full ACF alternative in 2026.
The gap isn’t about which tool is “better,” it’s about scope. Block Bindings connects a single value to a single block. ACF manages entire structured datasets: a repeatable list of team members, a gallery of before-and-after photos, a relationship field linking a product to related products. Those use cases show up constantly on business and ecommerce sites, and Block Bindings currently has no way to handle them.
When Block Bindings Is Enough
Block Bindings is enough when a site needs a handful of simple, single-value custom fields connected to core blocks, and a developer is comfortable registering them in code. It’s a good fit for these situations:
- A single reusable value, like a price, SKU, or event date, shown in a Paragraph or Heading block
- A site with no non-technical editors who need a friendly, plugin-based form to fill in fields
- A lightweight custom post type where adding one more plugin feels like overkill
- A block theme project already leaning on Full-Site Editing patterns and template parts
When You Still Need ACF
ACF is still the right call whenever a site needs repeatable or complex structured content, or when a client needs to edit fields through a clean, no-code form. Common cases include:
- Repeatable content, like FAQ lists, team member grids, or testimonial carousels
- Image galleries or multi-file fields attached to a post or page
- Relationship fields connecting one post type to another, like products to categories or case studies to services
- Custom Gutenberg blocks built without writing React, using ACF Blocks
- Non-technical clients who need a guided, form-based editing experience instead of raw block markup
This is the same tradeoff that shows up in the Elementor vs Gutenberg decision: native tools keep getting stronger, but they still don’t cover every case a page builder or a dedicated plugin handles out of the box.
How to Set Up a Basic Block Binding, Step by Step
Setting up a working block binding takes three steps: register the meta field, bind it to a block, and confirm it renders on the front end. Here’s the process for a simple text value.
- Register the custom field with
register_post_meta()infunctions.php, settingshow_in_restto true so the block editor can access it. - Add a Paragraph, Heading, Image, or Button block in the editor, then bind its content attribute to the registered meta key using the block’s Attributes panel or the Code Editor view.
- Enter a value for that custom field on the post’s edit screen, save, and check the front end to confirm the bound block displays the value correctly.
In the Code Editor view, a bound Paragraph block looks like this:
<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"core/post-meta","args":{"key":"event_price"}}}}} -->
<p>$49</p>
<!-- /wp:paragraph -->The value shown in the block markup is just a placeholder. WordPress replaces it with the live meta value at render time, which is what makes the binding dynamic instead of static text.
Can You Use ACF and Block Bindings Together?
Yes, ACF and Block Bindings can be used together on the same site without conflict, because ACF-registered fields are stored as standard WordPress post meta. That means a field created through ACF’s visual interface can, in some setups, still be referenced by a native block binding, giving editors the friendly ACF form while developers use the native API for simple display logic elsewhere.
This combination is worth considering on larger sites: use ACF for the complex, editor-facing fields, and reach for Block Bindings on lightweight template parts where a full plugin dependency doesn’t make sense. Block Bindings is part of the broader push toward Full-Site Editing, where WordPress core keeps absorbing functionality that used to live exclusively in plugins.
For a business site with product listings, staff bios, or a portfolio of past work, structured fields like these are common. Examples of these kinds of builds are in the portfolio.
The Bottom Line
ACF vs Block Bindings isn’t a fight either tool needs to win. Block Bindings is a genuinely useful native option for simple, single-value fields tied to a handful of core blocks, and it removes a plugin dependency in cases where that’s all a site needs. ACF still owns everything more complex: repeaters, galleries, relationships, conditional logic, and a form-based editing experience non-technical clients can actually use. Pick based on what the field needs to do, not which one feels more “modern.”
Frequently Asked Questions
The core ACF plugin is free and includes 30+ field types. ACF PRO is a paid upgrade required for the Repeater field, Flexible Content field, Gallery field, options pages, and ACF Blocks.
No. WordPress has native custom field support built in, and since WordPress 6.5 it also has the Block Bindings API, which connects those fields to core blocks without installing any plugin.
At launch in WordPress 6.5, Block Bindings supported the Paragraph, Heading, Button, and Image blocks, and WordPress core has continued expanding which blocks and attributes it covers since then.
Yes. ACF-registered fields are stored as standard WordPress post meta, so they can work alongside the Block Bindings API rather than replacing it.
Yes, for most real-world client sites ACF is still worth using, since it covers structured content types like repeaters, galleries, and relationship fields that Block Bindings does not support natively.

Leave a Reply