ACF vs Native Custom Fields: Choosing a Field Layer

Post meta is core WordPress. Any post can have arbitrary key-value pairs, stored in wp_postmeta, retrievable with get_post_meta, queryable with a meta query. It's stable, well-documented and going nowhere.

You can register meta with register_post_meta to declare a type, a sanitisation callback and whether it appears in the REST API — which matters for the block editor and for anything headless.

What you don't get is an interface. The native custom fields panel is a flat list of key-value text inputs with no validation, no field types, no repeatable groups and no way to stop an editor typing a date into a number field. It's fine for a developer editing one value and hopeless for a client managing content.

None of that changes where the data lives. Most field plugins store values in ordinary post meta, which is the important thing to understand about the lock-in question.

• Field types: image, file, date picker, colour, WYSIWYG, relationship to another post, taxonomy selector, true/false. Each with an appropriate control.
• Validation and required fields, so incomplete content can't be published.
• Repeatable groups, for things like a list of team members or a set of specifications.
• Conditional logic, so fields appear only when relevant.
• Field groups assigned to specific post types, templates or taxonomies.
• A vastly better editing experience, which is the real product.

Less than people fear, with caveats. Simple field values are stored as normal post meta under the field's name, readable with get_post_meta without the plugin present. Deactivate the plugin and your content is still there.

The caveats matter though. Complex field types — repeaters, flexible content, nested groups — are stored in a plugin-specific naming scheme that's tedious to read without the plugin's functions. Relationship fields store arrays of IDs in serialised form. And the field definitions themselves live in the plugin's format.

So the honest position: your content is portable, your field structure isn't, and the more you use the advanced field types the more work a migration becomes. That's an acceptable trade for most projects, but it's worth making knowingly.

This is the practice that makes the difference over a project's life, and it's the one most often skipped.

If fields are defined only in the database through the admin UI, they aren't in version control, they can't be deployed with code, and staging and production drift apart. Someone adds a field on production, someone else adds a different one on staging, and now the two environments render differently and nobody knows why.

Most field plugins support exporting definitions to PHP or JSON that lives in your repository and syncs automatically. Use it. Fields become part of the codebase, deploys carry them, and the environments stay identical.

• Prefix field names so they can't collide with a plugin's meta keys.
• Name for what the value is, not how it looks. hero_image, not top_banner_pic.
• Store IDs for images and posts, not URLs or titles. IDs survive a domain change, a CDN switch and a retitle.
• Keep booleans as booleans, not the strings a text field will give you.
• Don't store presentation — CSS classes, inline styles, colour hex values chosen per post. Store meaning and let the template decide the presentation, or a redesign becomes a data migration.
• Group related fields, so the editing screen has structure rather than thirty flat inputs.

Post meta is fast to read for a single post — WordPress loads all of a post's meta in one query and caches it. Reading twenty fields from one post costs no more than reading one.

Where it gets expensive is querying by meta value across many posts. Meta queries join a large table on values that aren't efficiently indexed, and they get slower as the site grows. If you need to filter or sort by something at scale, that something should probably be a taxonomy, not a field.

Repeaters with many rows generate a lot of meta rows — each sub-field of each row is its own entry. A repeater with ten rows of five fields is over fifty meta rows for one post. Usually fine; worth knowing when a page has several such repeaters and feels slow.

These three solve overlapping problems and choosing wrong produces a site that's awkward to edit.

• Fields are right when every item of a type has the same structured attributes — a case study always has a client, an industry and a result.
• Blocks are right when editors compose a page from components in an order they choose.
• A custom post type is right when the thing has its own identity, URL and archive.
• A common mistake is a huge field group for page content that editors actually want to reorder — that's blocks. Another is a block per content type — that's usually a post type with fields.

If a separate frontend will consume this data, check the API story before committing. Fields are not automatically exposed — native meta needs register_post_meta with show_in_rest, and plugin fields usually need a bridging extension.

Those bridges vary in quality and maintenance, particularly for complex field types. A repeater or flexible content field that's awkward to consume over an API is a problem you discover late, after the content model is built.

For a headless project, test the API output of your intended field structure early, with realistic content in it.

For most client sites: use a field plugin for the editing experience, define the fields in code and keep them in version control, name fields semantically, store IDs rather than URLs, and use taxonomies for anything you'll filter by.

That gets you the good interface without the parts of the lock-in that actually hurt, and it means the next developer can read the field structure in the repository rather than clicking through an admin screen.