ACF vs Secure Custom Fields: Commercial ACF vs WordPress.org SCF (2026)

Advanced Custom Fields (ACF) and Secure Custom Fields (SCF) share a closely related field-management model and familiar APIs, but they now represent different project paths. ACF is maintained commercially by WP Engine with a free edition and paid ACF PRO. Secure Custom Fields is distributed through WordPress.org and WordPress developer documentation as a free project with advanced field, CPT, taxonomy, block, JSON, and API features.

Compare	Advanced Custom Fields (ACF®)Free; ACF PRO Personal $49/year for 1 site Remove	Secure Custom FieldsFree Remove
Pricing model	Freemium	Free
Starting price	Free; ACF PRO Personal $49/year for 1 site	Free
Free version	Yes	Yes
Sites included	1 Personal; 10 Freelancer; unlimited Agency	Unlimited
Lifetime option	No	No
Refund policy	30-day money-back guarantee	Not applicable — free/open-source plugin
Setup level	Intermediate	Intermediate
WordPress.org rating	4.5/5 (1,440)	4.8/5 (65)
Active installs	2M+	100K+
Best for	Developers and site builders creating structured content models in WordPress	developers building structured WordPress content with custom fields, options, post types, and taxonomies under the Secure Custom Fields project
Not ideal for	Users expecting every custom field to design and render itself without template or builder work	sites already standardized on ACF or ACF Pro that cannot safely switch or retest their field stack
Tested version	6.8.10	6.9.5
Last reviewed	2026-09-23	2026-09-23
Features
Visual field builder	Yes	Yes
Custom field types	Yes	Yes
Repeater / repeatable groups	Paid plan	Yes
Flexible content / layout fields	Paid plan	Yes
Post / object relationships	Yes	Yes
Custom post types / taxonomies	Yes	Yes
Options / settings pages	Paid plan	Yes
Custom Gutenberg blocks	Paid plan	Yes
Front-end forms / submissions	Yes	Yes
Conditional field logic	Yes	Yes
Custom database table storage	No	No
Local JSON / versionable config	Yes	Yes
REST / API support	Yes	Yes
Code-first / export workflow	Yes	Yes

Shared concepts make the comparison unusual

Both products use familiar field groups, location rules, field APIs, repeaters, relationships, Local JSON concepts, and ACF-style developer functions. That reduces the conceptual migration barrier compared with moving to a completely different custom-fields framework.

The similarity also increases the need for discipline. Do not assume every current or future behavior remains interchangeable just because function names and field structures look familiar. Test the exact fields, blocks, REST behavior, and third-party integrations used by the site.

Advanced fields and content modeling

ACF free covers many standard field types, while ACF PRO adds premium capabilities such as Repeater, Flexible Content, Clone, Gallery, Options Pages, and ACF Blocks.

Secure Custom Fields currently documents advanced fields including Repeater, Flexible Content, Relationship, Clone, Gallery, Google Map, and others, plus custom post types, custom taxonomies, Local JSON, and APIs as part of its free project.

Blocks and editor integration

ACF Blocks is an ACF PRO feature and is widely used for PHP-rendered custom Gutenberg blocks. Its ecosystem is mature and many development teams already have established component patterns around it.

SCF documents block support and continues to evolve alongside WordPress core. Teams using sophisticated block libraries should test editing, previews, nested data, and deployment rather than assuming identical runtime behavior across the two projects.

Security and update governance

Both projects are actively maintained, but they have different release and governance paths. SCF’s 2026 changelog includes multiple hardening updates around REST permissions, front-end forms, gallery responses, uploads, encryption, and Local JSON.

For production sites, the important question is not which project has “security” in the name. It is how your team tests updates, tracks advisories, stages changes, and responds when a field-system update affects templates or editing workflows.

Commercial support vs free distribution

ACF PRO licenses currently start at $49/year for one site, with Freelancer and Agency tiers for larger portfolios. That purchase includes premium features, updates, and the commercial product/support model.

Secure Custom Fields is free. The license saving can be meaningful across many sites, but agencies should include migration QA and future compatibility testing in the decision. Free software is not free operationally when it becomes core application infrastructure.

Third-party compatibility is the practical gate

ACF has years of third-party integrations across page builders, import/export tools, multilingual plugins, developer libraries, and hosting workflows.

SCF retains a familiar API model, but a production migration should verify every integration that explicitly checks for ACF, ACF PRO, plugin constants, licensing state, or premium-only behavior. Compatibility claims should be tested on the exact stack.

Do not switch and redesign the schema at the same time

If a site moves from ACF to SCF or back, keep field names, keys, return formats, and content structures stable during the first migration. Changing the implementation and the schema simultaneously makes it difficult to identify whether a regression comes from compatibility or from the content-model redesign.

Back up field definitions and content, stage the migration, verify front-end rendering and editor saves, then test REST responses, blocks, options, repeaters, relationships, and any automated imports before deployment.

Project governance matters more than headline price

ACF PRO has a commercial license and support model; SCF is free. That pricing difference is easy to understand, but the ongoing governance difference is more important on production sites. Agencies need a policy for who approves updates, how compatibility is tested, and what happens when a third-party plugin explicitly documents support for ACF rather than SCF. Treat ecosystem compatibility as a recurring maintenance item, not a one-time migration checkbox.

Compatibility testing should include field keys, not only field names

ACF-style systems can store both values and reference metadata around field keys. A migration that preserves visible field names but changes keys or field definitions can still affect template helpers, REST output, field synchronization, or third-party integrations. Export definitions and compare keys, locations, return formats, and nested structures before and after switching.

A rollback plan is essential because both systems sit close to content storage

Before switching ACF and SCF on a production site, take a database backup and export the field definitions. Test save/edit operations for the content types that use complex fields, not just front-end rendering. A site can look correct while new editor saves silently produce different structures. The rollback point should restore both plugin state and field configuration together.

Compatibility debt should be measured before switching

ACF and Secure Custom Fields share substantial concepts, APIs, and field structures, which makes a migration look deceptively simple. The real risk is compatibility debt in everything around the field system: page builders, import/export tools, custom blocks, REST consumers, PHP helper calls, deployment scripts, and third-party extensions may test explicitly against one implementation or version. Build a dependency inventory before switching and classify each dependency as field-storage only, API dependent, or vendor-specific. Then test the highest-risk integrations first. SCF also has its own Local JSON and WP-CLI workflows, so schema deployment can remain versionable, but the team should choose one source of truth and avoid editing field definitions independently in production. A low-license-cost migration is not low-cost if every release needs compatibility investigation.

Update-source divergence should be treated as a release-management risk

Because ACF and Secure Custom Fields now follow different project and release paths, compatibility can drift even when today’s APIs look similar. A future WordPress core change, security hardening release, or block-editor update may land differently in each project. Agencies considering SCF should therefore test against a fixed compatibility matrix instead of relying on historical ACF behavior. Record WordPress version, builder versions, block dependencies, REST consumers, and any ACF-specific add-ons in staging QA. The longer the project lives, the more important this becomes: compatibility is a moving target, not a one-time migration result.

FAQs