Advanced Custom Fields

What Is Advanced Custom Fields?

Advanced Custom Fields, almost universally abbreviated to ACF, is a WordPress plugin that lets developers and site builders add their own custom fields to the WordPress editing screens. Out of the box, WordPress gives you a title and a single content area for each post or page. ACF extends that model dramatically, allowing you to attach structured, typed fields, text inputs, image pickers, date selectors, relationship fields, repeaters, and dozens more, to any post type, page, user, taxonomy term, or settings screen. It is one of the most widely installed developer-oriented plugins in the entire WordPress ecosystem and a cornerstone of how professional agencies build custom WordPress sites.

The core problem ACF solves is the gap between WordPress as a blogging tool and WordPress as a flexible content management system. A real-world website rarely consists of just a title and a body of text. A property listing needs a price, a number of bedrooms, a map location, and a gallery. A staff directory needs a job title, a headshot, a phone number, and a department. A landing page needs a hero heading, a subheading, a set of feature blocks, and a call-to-action. ACF gives developers a clean, visual way to define exactly those fields and then present editors with a tailored, intuitive editing interface instead of a generic text box.

It is important to be precise about what ACF is and is not. ACF is a WordPress plugin that runs on your own hosting inside a WordPress installation. It is not a hosted service, not a browser extension, and not a standalone application. It is also primarily a developer tool: ACF defines and stores the fields, but a developer (or a carefully built theme) is responsible for outputting those field values into templates. The plugin was created by Elliot Condon and is now owned by WP Engine, which maintains both a free version distributed through the WordPress.org plugin directory and a paid ACF PRO version that adds the powerful Repeater, Flexible Content, Options Page, and Gallery features.

Because ACF stores its field values in standard WordPress database tables and exposes them through the WordPress REST API and template functions, it leaves recognizable traces both in a site's markup and in its API responses. That makes it detectable from the outside in several ways, though, as we will discuss, ACF is generally subtler to fingerprint than a front-end visual builder, because much of what it does happens in the WordPress admin and in template logic rather than in obvious page markup.

The reason ACF matters so much to anyone analyzing a WordPress site is that its presence is a strong signal of a custom, developer-built site rather than a templated one. When a site uses ACF, it almost always means a developer or agency designed bespoke content structures for that project. That is valuable context for sales intelligence, competitive research, and technical due diligence.

How Advanced Custom Fields Works

ACF's central concept is the field group. A developer creates a field group in the WordPress admin (under a dedicated ACF menu), gives it a title, and adds individual fields to it. Each field has a type, text, textarea, number, email, image, file, WYSIWYG editor, select, checkbox, true/false, date picker, color picker, Google Map, relationship, post object, taxonomy, user, and many more. Each field also has a name (the key used to retrieve its value in code) and a label (what the editor sees).

The second half of a field group is its location rules. These rules determine where the field group appears in the WordPress admin. You might say "show this field group when the post type is equal to property," or "when the page template is equal to Landing Page," or "when the current user role is administrator." This conditional system is what makes ACF so flexible: you can build entirely different editing experiences for different content types, all from a visual interface without writing PHP to register meta boxes by hand.

When an editor fills in those fields and saves a post, ACF stores the values in the standard WordPress wp_postmeta table (or the appropriate meta table for users, terms, or options). The field values are saved as post metadata with the field name as the meta key, alongside a reference to the ACF field definition. This means ACF data lives in the same place as ordinary WordPress custom fields, which is part of why the plugin integrates so cleanly with the rest of the ecosystem.

Outputting the data is the developer's job. In a theme template, a developer calls ACF functions like get_field('price') or the_field('hero_heading') to retrieve and display a field's value. ACF PRO's Repeater and Flexible Content fields enable far more sophisticated patterns: a Repeater lets an editor add an arbitrary number of rows (for example, a list of team members or FAQ entries), while Flexible Content lets editors assemble a page from a library of predefined layout blocks, effectively a structured, developer-controlled page builder.

To picture the workflow end to end, imagine an agency building a real-estate website. A developer creates a "Property" custom post type, then builds an ACF field group with fields for price, bedrooms, bathrooms, square footage, a photo gallery, and a map location, setting the location rule to show only on the Property post type. The agency's content team then adds each property through a clean, purpose-built form, never touching code or fighting a generic editor. The developer writes a single-property template that pulls those field values and lays them out beautifully. When a visitor loads a property page, WordPress renders that template with the stored field data. The same structured data can also be exposed through the REST API to power a mobile app or a decoupled front end.

Modern ACF has also embraced the WordPress block editor. ACF Blocks (part of ACF PRO) let developers register custom Gutenberg blocks whose settings are powered by ACF fields, giving editors block-based building with developer-defined, structured inputs. This bridges ACF's structured-data philosophy with WordPress's modern editing experience.

How to Tell if a Website Uses Advanced Custom Fields

ACF is genuinely harder to detect than a front-end builder, because by design it operates mostly in the admin and through template logic. There is no guaranteed front-end fingerprint on every ACF site. That said, several real signals exist, and StackOptic inspects them from the server side just as you can check them manually. Where a signal is not present, the honest answer is that ACF may still be in use behind the scenes.

Plugin asset paths. When a page enqueues ACF's own scripts or styles, the asset URLs include the plugin directory /wp-content/plugins/advanced-custom-fields/ (free version) or /wp-content/plugins/advanced-custom-fields-pro/ (PRO). These typically load only where ACF outputs interactive components (for example, certain front-end forms or map fields), so they are a reliable positive signal when present but are often absent on pages that simply render field values as plain HTML.

REST API exposure. WordPress exposes data at /wp-json/, and ACF field values can appear in REST responses. On sites that expose ACF fields to the API, a request such as /wp-json/wp/v2/posts may include an acf object in each item containing the custom field data. Seeing an acf key in a WordPress REST response is a strong, direct indicator of the plugin.

Map field artifacts. ACF's Google Map field renders a container with the class acf-map, and it loads the Google Maps JavaScript API. A page containing an element with the acf-map class is very likely using ACF for that map.

Generic custom-field meta. Because ACF stores data in standard post meta, the rendered values themselves usually look like ordinary HTML and carry no ACF-specific marker. This is why you cannot conclude "no ACF" simply from clean markup; the data is there, just indistinguishable from any other content once rendered.

WordPress confirmation first. ACF only runs on WordPress, so the usual WordPress signals apply, a <meta name="generator" content="WordPress ..."> tag, /wp-content/ and /wp-includes/ paths, and the /wp-json/ REST API. Confirm WordPress first, then look for ACF-specific evidence.

Here is how to check each signal yourself:

Method	What to do	What ACF may reveal
View Source	Open the page, right-click, "View Page Source"	/plugins/advanced-custom-fields/ asset paths, an acf-map element
Browser DevTools	Inspect elements and the Network tab	Requests to the ACF plugin directory, the Google Maps API on map fields
REST API	Visit /wp-json/wp/v2/posts in the browser	An acf object inside post items exposing field data
Wappalyzer	Run the extension on the live page	Sometimes identifies "Advanced Custom Fields" when assets are present
BuiltWith	Look up the domain	Current and historical ACF detection where signals are exposed

A practical command-line check is curl -s https://example.com/wp-json/wp/v2/posts | grep -o '"acf"'. If that returns a match, the site is exposing ACF data through the API. For broader methodology, see our guides on how to identify a WordPress theme and plugins and how to tell if a website is built with WordPress.

It is worth being candid about the limits here. Many ACF sites expose no obvious front-end fingerprint at all, because the plugin's entire purpose is to feed clean, structured data into a developer's templates, and rendered field values are simply HTML. When the REST API does not expose the acf object and no ACF assets are enqueued on the public pages, even a thorough scan may not be able to confirm ACF with certainty. The strongest approach combines several signals, an asset path, an acf REST key, an acf-map element, on top of confirmed WordPress, and treats their absence as inconclusive rather than as proof the plugin is missing. Server-side analysis helps here because it fetches the raw HTML and API responses directly, without the noise a browser introduces by executing scripts and rewriting the DOM.

Key Features

• Visual field builder. Define dozens of field types and group them without writing PHP to register meta boxes manually.
• Flexible location rules. Show field groups conditionally based on post type, page template, taxonomy, user role, and more.
• Repeater fields (PRO). Let editors add unlimited rows of structured data, such as team members, FAQs, or feature lists.
• Flexible Content (PRO). Build pages from a library of developer-defined layout blocks, a structured alternative to free-form page builders.
• ACF Blocks (PRO). Register custom Gutenberg blocks whose interface is powered by ACF fields.
• Options pages (PRO). Create global settings screens for site-wide values like contact details or footer content.
• REST and template integration. Retrieve field values with simple functions and expose them through the WordPress REST API.

Pros and Cons

Pros

• Turns WordPress into a genuinely flexible CMS with clean, structured content modeling.
• Gives content editors a tailored, intuitive interface instead of a generic editor.
• Stores data in standard WordPress meta tables, keeping it portable and well integrated.
• A mature, extremely well-documented plugin with a huge community and reliable support.

Cons

• Requires a developer to output field values; it is not a turnkey design tool for non-coders.
• Heavy reliance on ACF can create lock-in, since templates depend on its functions to display data.
• The most powerful features (Repeater, Flexible Content, Options Pages) require the paid PRO version.
• Field data stored as post meta can be less performant for very large, query-heavy datasets without care.

Advanced Custom Fields vs Alternatives

ACF competes with other custom-fields and content-modeling solutions in the WordPress space. The table below compares it with common alternatives.

Product	Approach	Audience	Standout strength
Advanced Custom Fields	Visual field builder feeding developer templates	Developers and agencies	Flexibility, maturity, clean data model
Meta Box	Developer-focused custom fields, code or UI	Developers	Performance options and modular extensions
Pods	Custom fields plus custom post types and taxonomies	Site builders	All-in-one content modeling in one plugin
Carbon Fields	Code-defined custom fields (developer library)	Developers	Lightweight, version-controlled field definitions
Native WordPress custom fields	Raw post meta with a basic UI	Anyone	Built in, no plugin required, but unstructured

If a site turns out to use a different content-modeling approach, the same detection techniques apply; when profiling a WordPress site's broader toolset you might also check for an SEO plugin like Yoast SEO to understand how the site manages metadata alongside its custom content.

Use Cases

ACF is most at home on custom, developer-built WordPress sites where the content does not fit the default title-and-body model. Agencies use it as a default part of their build process, defining bespoke field groups for each client's content types so editors get a purpose-built interface. This is the single most common scenario: ACF is essentially the backbone of professional custom WordPress development.

It also fits directory and listing sites (real estate, job boards, restaurant guides) where each entry has many structured attributes, corporate sites with complex page layouts assembled from Flexible Content blocks, and any project that needs custom settings pages for global content. Developers building headless or decoupled WordPress sites use ACF to model content and expose it through the REST API to a separate front end built in React, Next.js, or Vue.

Consider a few concrete scenarios. A university department site might use ACF to model courses, faculty profiles, and research projects, each with their own structured fields, giving non-technical staff a clean way to keep content current. A SaaS company might build its marketing pages from ACF Flexible Content layouts, so its marketing team can assemble new pages from approved building blocks without a developer. An online magazine might use Repeater fields to manage structured article components like pull quotes, image galleries, and related-link lists. In each case the common thread is structured, editor-friendly content powered by developer-defined fields.

From a sales-intelligence perspective, detecting ACF on a prospect's site is a meaningful signal. It strongly indicates a custom, agency- or developer-built WordPress site rather than a templated one, which suggests a budget for professional development and a more sophisticated content operation. That profile is valuable when prioritizing leads for WordPress-focused services, sizing a market of custom-built sites, or assessing a prospect's technical maturity. Understanding how technology footprints map to buyer profiles is the core idea behind using tech-stack data to qualify leads, and ACF is a textbook example of a high-signal detection.

Frequently Asked Questions

Is Advanced Custom Fields free?

There are two versions. The free version, distributed through the WordPress.org plugin directory, covers the core field types and field-group system and is fully capable for many projects. ACF PRO is a paid upgrade that adds the Repeater, Flexible Content, Gallery, Options Pages, and ACF Blocks features. Most professional agency builds use ACF PRO because those advanced features are central to building flexible, structured layouts. The plugin is owned and maintained by WP Engine.

Can you tell if a site uses ACF for free?

Sometimes, but not always. The clearest free checks are looking for asset paths containing /wp-content/plugins/advanced-custom-fields/ or -pro/, an element with the acf-map class, or an acf object in the /wp-json/wp/v2/posts REST response. A quick curl -s URL/wp-json/wp/v2/posts | grep '"acf"' reveals API exposure. However, many ACF sites render field values as plain HTML with no ACF-specific marker, so the absence of these signals does not prove ACF is missing.

Does ACF data show up in the WordPress REST API?

It can, but only when configured to. ACF provides a setting (and PRO offers per-field-group control) to expose field values in the REST API. When enabled, each item in a response like /wp-json/wp/v2/posts includes an acf object containing the custom field data. This is both a powerful feature for headless WordPress and one of the most reliable external signals that a site uses ACF. If the option is disabled, the fields will not appear in the API even though they exist in the database.

Is ACF a page builder?

Not in the conventional sense. ACF is a content-modeling tool, not a drag-and-drop visual designer. However, its PRO Flexible Content field lets developers build a structured, block-based editing experience where editors assemble pages from predefined layouts. This is sometimes described as a "developer's page builder" because it gives editors flexible page assembly while keeping the design and output fully under the developer's control, unlike free-form builders that let editors style anything.

What happens to my content if I deactivate ACF?

The underlying data is safe, because ACF stores field values in WordPress's standard post meta tables. Deactivating ACF does not delete that data. However, the data will stop displaying, because your theme templates rely on ACF functions like get_field() to retrieve and output the values, and those functions will no longer exist. You would either need to keep ACF active, reactivate it, or rewrite your templates to read the meta values directly. This template-level dependency is the main form of lock-in to weigh.

Want to identify Advanced Custom Fields and the rest of a site's stack automatically? Run any URL through StackOptic at https://stackoptic.com.