CMB2 vs ACF: Code-First Meta Boxes vs Visual Custom Fields (2026)

CMB2 and Advanced Custom Fields (ACF) both create custom data-entry interfaces for WordPress, but they target different development styles. CMB2 is a code-first metabox framework designed to be bundled into themes and plugins. ACF is a visual field-management product with a large editor and integration ecosystem.

Compare	CMB2Free Remove	Advanced Custom Fields (ACF®)Free; ACF PRO Personal $49/year for 1 site Remove
Pricing model	Free	Freemium
Starting price	Free	Free; ACF PRO Personal $49/year for 1 site
Free version	Yes	Yes
Sites included	Unlimited	1 Personal; 10 Freelancer; unlimited Agency
Lifetime option	No	No
Refund policy	Not applicable — free/open-source plugin	30-day money-back guarantee
Setup level	Advanced	Intermediate
WordPress.org rating	5.0/5 (91)	4.5/5 (1,440)
Active installs	300K+	2M+
Best for	WordPress developers who need a code-first toolkit for custom fields, metaboxes, option pages, and frontend or admin forms.	Developers and site builders creating structured content models in WordPress
Not ideal for	Non-developers who want a visual field builder and a no-code field-management interface.	Users expecting every custom field to design and render itself without template or builder work
Tested version	2.12.0	6.8.10
Last reviewed	2026-09-23	2026-09-23
Features
Visual field builder	No	Yes
Custom field types	Yes	Yes
Repeater / repeatable groups	Yes	Paid plan
Flexible content / layout fields	Limited	Paid plan
Post / object relationships	No	Yes
Custom post types / taxonomies	No	Yes
Options / settings pages	Yes	Paid plan
Custom Gutenberg blocks	Limited	Paid plan
Front-end forms / submissions	Yes	Yes
Conditional field logic	No	Yes
Custom database table storage	No	No
Local JSON / versionable config	No	Yes
REST / API support	Limited	Yes
Code-first / export workflow	Yes	Yes

Code-first vs visual configuration

CMB2 field definitions live in PHP configuration. That makes them naturally version-controlled and deployable with a theme or plugin, but non-developers cannot safely redesign the schema from wp-admin.

ACF centers on a visual field-group builder and can also synchronize definitions through Local JSON. That makes it easier for editors and implementers to work visually while still supporting disciplined development workflows.

Field types and repeatable data

CMB2 ships a broad set of text, date, taxonomy, WYSIWYG, file, oEmbed, select, checkbox, and other field types. Most fields can be repeatable, and repeatable groups support nested structures.

ACF free offers a broad field library, while ACF PRO adds high-level components such as Repeater, Flexible Content, Clone, and Gallery. For editorial teams, those PRO controls can be more approachable than developer-configured repeatable arrays.

Options, users, terms, and front-end forms

CMB2 can create options-page forms and manage post, user, and term meta. Its flexible API can render forms on the front end as well.

ACF similarly works across posts, users, taxonomy terms, options, and front-end forms. The difference is workflow: CMB2 expects developers to define behavior in code, while ACF exposes more of the schema through the WordPress admin.

Custom post types are not CMB2’s job

CMB2 is a metabox/custom-fields framework; it does not try to become a complete CPT/taxonomy registration product. Projects usually register content types in code or with another tool.

ACF now includes CPT and taxonomy registration in addition to fields. That can consolidate the content model for site builds, but plugin/theme developers may still prefer explicit code registration alongside CMB2.

Portability and bundling

CMB2 is explicitly designed so developers can bundle it with a project, and it only loads the newest available version. This makes it useful for distributable plugins and themes that need guaranteed field UI without asking the site owner to configure another plugin.

ACF is typically a site-level dependency. ACF PRO distribution and licensing should be handled according to its license model, so commercial product developers need to think differently about dependency management.

Pricing and support model

CMB2 is free and open source. Its cost is developer time: schema changes require code changes and deployments.

ACF is freemium and ACF PRO starts at $49/year for one site. The paid product buys advanced field types, features, updates, and a commercial ecosystem that can reduce custom implementation work.

When a code-first schema is safer

For a plugin or product where changing a field definition can break application logic, preventing casual admin edits is a feature. CMB2 keeps the schema under developer control by default.

For client sites where content teams regularly request new fields or layout changes, ACF’s visual workflow can reduce development friction. The tradeoff is governance: production users should not have unrestricted schema-editing permissions just because the UI exists.

Migration requires mapping stored shapes, not just field names

Simple scalar meta can often move between CMB2 and ACF with little data transformation if meta keys stay the same. Repeatable groups, galleries, relationship-style fields, options, and return formats need deeper mapping.

Inventory the raw values in the database before switching. A template that expects a CMB2 serialized group array will not automatically understand an ACF repeater structure even when the visible admin fields look similar.

Developer ownership changes the maintenance model

With CMB2, schema changes normally go through a developer, repository, release, and deployment. With ACF, some teams allow authorized administrators to modify fields directly. The second workflow is faster for iteration but needs stronger change control. If a field drives templates, API consumers, or imports, changing it is effectively a code change even when the edit happens in wp-admin.

CMB2 works especially well when fields are part of a product, not a site configuration

A distributable plugin often needs its own fields to exist wherever the plugin is installed. CMB2 fits that model because field definitions ship with the code. ACF is usually a better fit when the field schema belongs to a particular site and administrators need to manage it visually. This distinction matters more than the raw field-type list.

Testing should include serialized and repeatable values

Simple text fields are rarely the migration problem. Repeatable groups, file lists, nested values, and custom sanitization callbacks are where CMB2 and ACF implementations can diverge. Build fixtures containing empty rows, multiple files, optional values, and edge-case data before migration. If those fixtures survive save, load, export, and template rendering, the migration is much safer.

Documentation quality matters because code-first fields are invisible to editors

CMB2 configurations live in code, so future maintainers need clear comments and examples showing where fields are registered, what each meta key stores, and which templates consume it. ACF exposes more of that information in wp-admin, but complex sites still benefit from a schema document. The less visible the configuration is to non-developers, the more important repository documentation becomes.

Code-first schemas need explicit lifecycle ownership

CMB2 has one major architectural property that is easy to underestimate: the schema normally ships with code. That means field changes can follow pull requests, version control, automated tests, and deployment environments by default. It also means non-developers cannot usually inspect or modify the model without reading code. ACF reverses that balance by making schema management much more visible in wp-admin while still offering JSON/PHP export workflows for disciplined teams. The right choice depends on who owns future change. For a distributable plugin or internal application maintained by developers, CMB2’s code-first lifecycle can reduce configuration drift. For a client site where editors and implementers need to understand the model visually, ACF usually reduces handoff friction. In either case, schema changes should have an owner, a review path, and a rollback method.

Validation and sanitization ownership differs more than the field UI suggests

CMB2 and ACF can render similar inputs, but the code path that validates and sanitizes those values may be very different. CMB2 projects often attach custom sanitization callbacks directly in field definitions; ACF projects may rely on field settings, validation hooks, save_post logic, or downstream template assumptions. Before migrating, inventory every custom callback and every field whose stored shape is trusted by application logic. Test malicious, malformed, empty, and boundary values—not only happy-path content. A migration is unsafe if the admin UI looks identical but validation rules have silently disappeared.

FAQs