Looking for a Carbon Fields alternative? Field Forge offers both visual builder and code-first workflows, plus AI features and ACF compatibility.
| Feature | Field Forge from $35/yr | Carbon Fields |
|---|---|---|
| Field registration | ✗ | ✗ |
| Visual builder | ✓ | ✗ |
| Non-developer friendly | ✓ | ✗ |
| AI schema generation | ✓ | ✗ |
| Custom table storage | ✓ | ✗ |
| ACF compatibility | ✓ | ✗ |
| TypeScript generation | ✓ | ✗ |
| GraphQL generation | ✓ | ✗ |
| Schema versioning | ✓ | ✗ |
| Commercial support | ✓ | ✗ |
| Modern API | ✓ | ✓ |
Carbon Fields is a free, open-source WordPress custom fields library maintained by HTML Burger. Like CMB2, it’s a code-first library where developers define fields in PHP rather than using a visual builder. It has a loyal following among experienced WordPress developers who prefer programmatic field setup, and it’s lightweight and performant for its use case.
But Carbon Fields has no visual builder, no paid support, no AI features, and an effectively invisible organic search footprint (13 keywords, 40 monthly traffic per SEMRush data). For teams that want both code-first workflows AND visual editing, Field Forge is the better fit.
| Field Forge | Carbon Fields | |
|---|---|---|
| Price | $35/year (Personal) to $169/year (Agency) | Free |
| Field registration | Visual builder + code API | Code only (PHP files) |
| Visual builder | Yes (modern) | No |
| Non-developer friendly | Yes | No (requires PHP skills) |
| AI schema generation | Yes | No |
| Custom table storage | Yes | No (wp_postmeta) |
| ACF compatibility | Yes | No |
| TypeScript generation | Yes | No |
| GraphQL generation | Yes | No |
| Schema versioning | Yes | No (use git for code files) |
| Commercial support | Yes | No |
| Modern API | Yes | Yes (good API design) |
Carbon Fields has one of the cleanest code APIs in the WordPress custom fields space. Field registration uses fluent method chaining that reads naturally:
use Carbon_Fields\Container;
use Carbon_Fields\Field;
Container::make('post_meta', 'Hero Section')
->where('post_type', '=', 'page')
->add_fields([
Field::make('text', 'hero_title', 'Hero Title'),
Field::make('textarea', 'hero_subtitle', 'Hero Subtitle'),
Field::make('image', 'hero_image', 'Hero Image'),
]);
For developers who value clean PHP code, Carbon Fields feels more elegant than CMB2’s older-school API.
GPL-licensed, free forever, maintained by HTML Burger (a WordPress development agency). No subscription, no license keys.
Small codebase with minimal runtime overhead. No heavyweight admin UI to render because there’s no admin UI beyond the standard post meta box rendering.
HTML Burger is an active WordPress development agency that uses Carbon Fields internally on client projects. This gives Carbon Fields a level of maintenance continuity that purely hobbyist projects sometimes lack.
The core trade-off is the same as with CMB2: Carbon Fields has no visual builder. Every field must be defined in PHP code. For teams that include non-developers, or developers who want to rapid-prototype field group structures before committing to code, Carbon Fields requires switching to a different tool.
Field Forge offers both a visual builder AND a code API. Developers can use the code API for production deployments; non-developers can use the visual builder; content editors can view and edit field groups without touching PHP.
No other custom fields plugin has AI-based field group generation. Field Forge is first. For teams building new field groups regularly, AI generation saves significant time over hand-coding every field.
AI schema generation feature →
Carbon Fields stores values in wp_postmeta, same as ACF and CMB2. Performance on large sites is the same (or similar to) ACF — the N+1 query problem affects all wp_postmeta-based plugins equally.
Field Forge’s custom indexed table is 3–10x faster on sites with 1,000+ posts or complex repeaters.
Custom table storage feature →
Carbon Fields has its own API and doesn’t try to be ACF-compatible. Migration from ACF to Carbon Fields requires rewriting every template reference. Migration from Carbon Fields to ACF or any other plugin requires the same rewriting.
Field Forge’s ACF compatibility layer means Carbon Fields code can be gradually migrated: you can mix Field Forge and Carbon Fields during transition, and once migrated, your get_field() calls work natively.
ACF compatibility layer feature →
Carbon Fields has no TypeScript generation, no GraphQL schema output, and no WPGraphQL integration. For headless WordPress teams using Next.js / Astro / Nuxt, Carbon Fields means writing types by hand or using a separate GraphQL plugin.
Field Forge auto-generates TypeScript and GraphQL definitions for every field group.
Carbon Fields is community-supported via GitHub issues. Response times depend on HTML Burger’s availability, which is secondary to their client work. For production sites that need guaranteed support, community-only isn’t enough.
Field Forge’s paid plans include priority email support with 1 business day response.
Carbon Fields has complex fields like complex (nested fields) and association (cross-reference). Field Forge has equivalent functionality — Group, Repeater, Flexible Content, Clone, and Relationship fields — with more sophisticated sub-field nesting and a visual builder for configuring them.
Carbon Fields migration is currently beta/manual verification scope in Field Forge. Carbon definitions are code-first, so a production move should be handled as a mapped project instead of a guaranteed one-click import:
Container::make() and add_fields() callswp_postmeta / wp_termmeta / wp_usermeta to Field Forge’s custom tablecarbon_fields_after_save, etc.) — translate to Field Forge’s hook equivalentsStraightforward Carbon Fields sites can usually be planned in hours, but the exact effort depends on custom containers, hooks, and theme API calls.
For everything else — teams with mixed dev/non-dev members, larger sites, headless WordPress, AI features, commercial support — Field Forge is a better fit.
Is Field Forge’s code API as clean as Carbon Fields’?
Field Forge’s fieldforge_register_field_group() function uses an array-based configuration similar to ACF’s programmatic API. It’s functional but not as fluent as Carbon Fields’ method chaining. If pure API aesthetic is your priority, Carbon Fields wins on that specific metric. But the trade-off is no visual builder, no AI, no headless tooling, no performance.
Can I keep my Carbon Fields code if I migrate?
Partially. Field Forge’s ACF compatibility layer handles get_field()-style access, but Carbon Fields’ carbon_get_post_meta() function uses a different API. You’ll need to update Carbon Fields data access calls in your theme to use either ACF-style get_field() (via compat layer) or Field Forge’s native API.
Does Field Forge have Carbon Fields’ “complex” field type?
Carbon Fields’ complex field is a repeating field with nested sub-fields. Field Forge has this via the Repeater field type with support for arbitrary sub-field nesting.
Will Carbon Fields work alongside Field Forge during migration?
Yes. Both plugins use different storage (wp_postmeta for Carbon Fields, custom table for Field Forge), so they don’t conflict. Run both during migration, test thoroughly, then deactivate Carbon Fields once the site is fully on Field Forge.
Is Field Forge slower than Carbon Fields on small sites?
No. Field Forge’s custom table storage has equivalent performance to Carbon Fields’ wp_postmeta on small sites. On large sites, Field Forge is significantly faster.
Get Field Forge — from $35/year →
14-day refund. ACF/SCF one-click import included. Carbon Fields migration is available as beta/manual mapping until a verified importer fixture is complete.
Field Forge’s fieldforge_register_field_group() function uses an array-based configuration similar to ACF’s programmatic API. It’s functional but not as fluent as Carbon Fields’ method chaining. If pure API aesthetic is your priority, Carbon Fields wins on that specific metric. But the trade-off is no visual builder, no AI, no headless tooling, no performance.
Partially. Field Forge’s ACF compatibility layer handles get_field()-style access, but Carbon Fields’ carbon_get_post_meta() function uses a different API. You’ll need to update Carbon Fields data access calls in your theme to use either ACF-style get_field() (via compat layer) or Field Forge’s native API.
Carbon Fields’ complex field is a repeating field with nested sub-fields. Field Forge has this via the Repeater field type with support for arbitrary sub-field nesting.
Yes. Both plugins use different storage (wp_postmeta for Carbon Fields, custom table for Field Forge), so they don’t conflict. Run both during migration, test thoroughly, then deactivate Carbon Fields once the site is fully on Field Forge.
No. Field Forge’s custom table storage has equivalent performance to Carbon Fields’ wp_postmeta on small sites. On large sites, Field Forge is significantly faster.
Every feature included. Every plan. Starting at $35/yr.