Custom Post Type UI vs ACF: Content Types vs Fields & Full Modeling (2026)

Custom Post Type UI (CPT UI) and Advanced Custom Fields (ACF) are often installed together, but modern ACF has made the overlap larger because it can now register custom post types and taxonomies itself. CPT UI remains focused on content-type registration, while ACF combines content types with custom fields and broader structured-content tooling.

Compare	Custom Post Type UIFree; CPT UI Pro $99 Remove	Advanced Custom Fields (ACF®)Free; ACF PRO Personal $49/year for 1 site Remove
Pricing model	Freemium	Freemium
Starting price	Free; CPT UI Pro $99	Free; ACF PRO Personal $49/year for 1 site
Free version	Yes	Yes
Sites included	Free plugin unlimited; Pro license terms per purchase	1 Personal; 10 Freelancer; unlimited Agency
Lifetime option	No	No
Refund policy	30-day money-back guarantee on Pro	30-day money-back guarantee
Setup level	Beginner-friendly	Intermediate
WordPress.org rating	4.6/5 (276)	4.5/5 (1,440)
Active installs	1M+	2M+
Best for	Site builders and developers who need custom post types or taxonomies without hand-coding registration	Developers and site builders creating structured content models in WordPress
Not ideal for	Users expecting the free plugin to create custom fields or design front-end templates automatically	Users expecting every custom field to design and render itself without template or builder work
Tested version	1.19.3	6.8.10
Last reviewed	2026-09-10	2026-09-23
Features
Visual field builder	No	Yes
Custom field types	No	Yes
Repeater / repeatable groups	No	Paid plan
Flexible content / layout fields	No	Paid plan
Post / object relationships	No	Yes
Custom post types / taxonomies	Yes	Yes
Options / settings pages	No	Paid plan
Custom Gutenberg blocks	Paid plan	Paid plan
Front-end forms / submissions	No	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

What each plugin actually owns

CPT UI is primarily a registration interface for custom post types and taxonomies. It gives administrators access to WordPress registration arguments without writing register_post_type() and register_taxonomy() code.

ACF can register CPTs and taxonomies while also defining field groups and attaching structured data to those objects. That makes ACF more capable as a single content-modeling tool, but broader scope is not automatically a reason to replace a stable CPT UI setup.

Fields are the biggest functional difference

CPT UI free does not provide a general custom-field system. It focuses on defining the content containers.

ACF is fundamentally a field system. Even the free version handles many field types and conditional logic, while PRO adds repeaters, flexible layouts, options pages, blocks, and other advanced features.

Existing CPT UI + ACF sites can stay that way

A common WordPress architecture has CPT UI register the post type and ACF attach fields. That division remains valid and can be easy for teams to understand.

Migrating CPT registration into ACF only to reduce one plugin creates avoidable risk if rewrite slugs, capabilities, REST settings, archive behavior, or taxonomy arguments change. Plugin count alone is not an architecture goal.

Exporting registration to code

CPT UI includes tools for exporting registration code, which can be useful when a project wants to move content-type definitions from the database into a theme or custom plugin.

ACF supports Local JSON for field configuration and can also move toward code-oriented registration workflows. The important governance question is where schema ownership lives: admin UI, version-controlled configuration, or application code. Pick one source of truth for each layer.

Blocks and front-end presentation

CPT UI free does not design front-end templates. Its current Pro offering adds block-editor-oriented display tooling, but the free plugin remains focused on registration.

ACF PRO includes ACF Blocks and integrates deeply with dynamic-content builders. If the project needs structured fields and presentation components, ACF has the broader path. If presentation is handled entirely by the theme or builder, CPT UI may be all that is needed for the registration layer.

Pricing and maintenance

CPT UI remains free and actively maintained, with an optional Pro product.

ACF has a free version and PRO starting at $49/year for one site. The cost comparison is only relevant if you need ACF’s field or PRO functionality; replacing a free registration plugin with ACF solely for CPT creation does not create much value.

Changing post-type registration can break URLs

The most dangerous migration detail is not fields; it is registration behavior. A different rewrite slug, has_archive value, hierarchical flag, REST setting, capability map, or taxonomy attachment can change URLs and editor behavior.

Before moving a CPT from CPT UI to ACF, export every registration argument and reproduce it exactly on staging. Flush rewrite rules once after the migration and crawl existing URLs before deployment.

Content-type definitions should be deployment artifacts

Whether CPTs are registered through CPT UI, ACF, or PHP, treat registration arguments as versioned application configuration. Export or document slugs, labels, capabilities, rewrite settings, REST visibility, supports, taxonomies, and archive behavior. A production edit to one checkbox can change public URLs or editor capabilities, so schema changes deserve the same review as code changes.

Consolidation can reduce plugins while increasing coupling

Moving CPT registration into ACF can reduce one plugin, but it also makes ACF responsible for both the content container and the data attached to it. That tighter coupling is convenient until the field layer needs to change. Keeping CPT UI separate can preserve a cleaner boundary: content types remain stable while the field system evolves independently. Neither architecture is inherently superior; choose the boundary you want to maintain.

CPT ownership should remain stable during field-system migrations

If a site already uses CPT UI plus ACF, replacing both responsibilities in one release increases the blast radius. A safer sequence is to leave CPT registration untouched while changing field tooling, or leave fields untouched while moving CPT registration. Keeping one side stable makes URL, capability, and REST regressions easier to isolate.

A content type is a public contract once URLs exist

After a CPT is indexed, linked, integrated, or exposed through REST, its registration becomes part of the site’s public contract. Moving registration from CPT UI to ACF should therefore be evaluated like an infrastructure migration, not admin cleanup. Preserve the post type key, rewrite behavior, archive URL, REST base, capabilities, and taxonomy associations unless there is a deliberate migration plan for each change.

Registration portability is the real CPT UI advantage

Custom Post Type UI is deliberately narrow, and that narrowness can improve portability. It registers post types and taxonomies without also owning the custom-field schema, templates, or broader data model. ACF can now consolidate those responsibilities, which is convenient, but consolidation should be a conscious architecture choice rather than a cleanup goal. If CPT registration is exported to PHP or otherwise documented, the content type can survive a field-system replacement with fewer moving parts. Before consolidating CPT UI into ACF, ask what future migration you are making easier: fewer plugins today, or looser coupling tomorrow? The safest long-lived architecture preserves stable post type keys, taxonomy keys, rewrite rules, capabilities, and REST settings independently from whatever field framework happens to be used at the time.

REST visibility and capability maps deserve regression tests

When moving a post type from CPT UI to ACF, the visible labels are the least risky part. REST exposure, capability_type, map_meta_cap, public/queryable settings, archive behavior, supports, and taxonomy attachments can affect editors, APIs, permissions, and front-end URLs. Capture the existing register_post_type() arguments before migration and compare them field by field after the switch. Then test REST endpoints as both administrators and lower-privilege users. A migration can preserve URLs while still breaking editorial permissions or an external application that depends on the old REST base.

FAQs