Gutenberg Form Builder: What 'Native' Actually Means (And Why Most Plugins Fake It)

Search for "Gutenberg form builder" and you'll find dozens of plugins claiming native block editor support. Contact Form 7 has a Gutenberg block. WPForms has a Gutenberg block. Gravity Forms, Formidable, Ninja Forms -- they all have Gutenberg blocks.

But here's the thing: having a Gutenberg block and being a Gutenberg form builder are two very different things.

Most of these plugins use the block editor as a delivery mechanism, not a building tool. They wrap their proprietary form builder inside a single block, which renders a shortcode on the front end. The block editor is just a fancy dropdown menu for picking which form to embed.

That's not a native Gutenberg form builder. That's a shortcode with extra steps.

The Shortcode Wrapper Pattern

Here's how the vast majority of WordPress form plugins work with Gutenberg:

1. You build your form in a separate, proprietary builder -- a custom admin page with its own drag-and-drop interface, its own field library, and its own settings panels.
2. When you want to add the form to a page, you insert a single Gutenberg block that's essentially a dropdown menu: "Select a form."
3. That block renders a shortcode like [wpforms id="123"] or [contact-form-7 id="abc"] on the front end.
4. The plugin's PHP then parses that shortcode and outputs the form HTML.

The block editor never touches the form itself. It has no idea what fields are in it, how they're laid out, or how they behave. The form is an opaque black box that happens to be delivered via a block.

This is the approach used by:

• Contact Form 7 -- The CF7 block is literally a shortcode inserter. Pick a form, get a shortcode. The block preview shows placeholder text, not your actual form.
• WPForms -- The WPForms block shows a live preview of your form, which is nicer. But you still build the form in WPForms' own builder. The block is a read-only embed, not an editor.
• Gravity Forms -- Same pattern. The block is a form picker. The real builder is a separate admin page.
• Ninja Forms -- The block inserts a shortcode. Building happens elsewhere.
• Formidable Forms -- Same story. Proprietary builder, block-as-embed.

These plugins all "support Gutenberg." None of them are Gutenberg.

What a Native Gutenberg Form Builder Actually Looks Like

A truly native Gutenberg form builder doesn't have a separate builder. The block editor is the builder.

Every form field is its own block. A text input is a block. An email field is a block. A textarea, a dropdown, a checkbox group, a submit button -- all individual Gutenberg blocks.

You build forms the same way you build pages: by adding blocks, arranging them, configuring them in the sidebar, and using the block editor's built-in tools for layout and structure.

This is how SkunkForms works. When you create a form, you're working with real Gutenberg blocks:

• Form block (the container)
• Text Input block
• Email block
• Textarea block
• Select / Dropdown block
• Checkbox block
• Radio block
• File Upload block
• Submit Button block

Each block has its own settings in the block sidebar -- label, placeholder, required validation, conditional logic. You drag fields around, group them in columns, and preview the actual form right in the editor.

There's no separate builder to learn. No proprietary interface. No context switching between "form admin" and "page editor." It's all one tool: the block editor you already know.

Why the Difference Matters

You might think this is an academic distinction. Who cares whether the form is built with native blocks or a proprietary builder, as long as it works?

It matters more than you'd expect. Here's why.

Full Site Editing Compatibility

WordPress Full Site Editing (FSE) lets you design your entire theme using the block editor -- headers, footers, templates, template parts. It's the future of WordPress theming, and it only works with blocks.

Shortcode-based form plugins work in the site editor the same way they work in the post editor: you pick a form from a dropdown. But because the form itself isn't made of blocks, you can't edit it in context. You can't see the actual fields in your template. You can't adjust individual field styles to match your theme while you're designing it.

A native block form builder gives you full control inside FSE. You can place individual form fields directly in templates, see them render in the editor, and style them alongside your other template blocks.

Block Patterns and Reusable Blocks

Gutenberg's pattern system lets you save groups of blocks as reusable templates. This is incredibly powerful for forms.

With native form blocks, you can save an entire form -- or just a section of fields -- as a block pattern. Need the same "Name + Email + Phone" field group across five different forms? Save it as a pattern and insert it wherever you need it. Update the pattern once, and every form using it updates automatically.

Shortcode-based forms can't do this. The form is a single opaque block. You can't break it into reusable pieces because there are no pieces -- just one monolithic embed.

theme.json Integration

WordPress theme.json is the centralized system for controlling design -- colors, typography, spacing, border radius. Block themes use it to maintain consistent styling across every block on the site.

Native Gutenberg blocks respect theme.json by default. When your theme defines a primary color, form field borders, button styles, or font sizes, native form blocks pick them up automatically. Your forms match your theme without writing a single line of CSS.

Shortcode-based form plugins generate their own HTML outside the block system. They either ship their own styles (which may clash with your theme) or require you to manually override their CSS to achieve visual consistency. Some handle this better than others, but none of them integrate as seamlessly as actual blocks.

No Separate Builder to Learn

Every proprietary form builder is different. WPForms has a left-panel field list with a center-panel canvas. Gravity Forms uses a sequential field-stacking approach. Formidable has a drag-and-drop builder with its own grid system. Ninja Forms has a multi-step builder flow.

When you switch form plugins -- or when a new team member joins -- there's a learning curve for each one.

Native Gutenberg forms have zero learning curve for anyone who's used the WordPress editor. Same keyboard shortcuts. Same block inserter. Same sidebar settings. Same drag-and-drop behavior. If you can build a page, you can build a form.

One Source of Truth

With shortcode-based plugins, your form structure lives in the plugin's database tables, not in the post content. The block editor stores a reference (the shortcode), but the actual form definition is elsewhere.

This creates problems. Form data doesn't show up in WordPress exports properly. It's tied to the plugin -- deactivate the plugin and the shortcode renders as plain text. Your forms are hostage to a third-party data structure.

Native block forms store everything in the post content, the same way every other block does. The form structure is the block markup. It's portable, human-readable, and doesn't disappear when you deactivate a plugin (the blocks gracefully degrade, and the content is still there).

The Performance Angle

There's a practical performance benefit to native blocks, too.

Shortcode-based form plugins typically load their JavaScript and CSS on every page, or require configuration to limit asset loading to pages with forms. They need runtime shortcode parsing -- WordPress has to find the shortcode in the content, call the plugin's render function, and inject the output.

Native blocks can leverage WordPress's built-in block asset system: block.json declares exactly which scripts and styles each block needs, and WordPress only enqueues them when the block is present on the page. No global stylesheet. No shortcode parsing overhead. No wasted requests on pages without forms.

For a deeper look at how plugin bloat affects performance, see our guide to fixing your WordPress form stack.

A Side-by-Side Comparison

When Shortcode-Based Plugins Make Sense

To be fair, the shortcode approach has advantages in specific cases.

If you need extremely complex form logic -- multi-page forms with calculation fields, payment integrations with conditional pricing, or forms that create WordPress posts and user accounts -- the established plugins have years of development behind those features. WPForms and Gravity Forms have enormous ecosystems of addons.

And if your workflow involves non-technical users who will never open the block editor -- people who only interact with forms through the plugin's dedicated admin page -- the separate builder may actually be simpler for them.

But for most WordPress sites building contact forms, lead capture forms, feedback forms, and support request forms? The native block approach is simpler, faster, more integrated, and more aligned with where WordPress is heading.

Where WordPress Is Heading

WordPress has committed to the block editor as the future of content creation, site building, and -- increasingly -- the entire admin interface. Gutenberg Phase 3 (collaborative editing) and Phase 4 (multilingual support) are being built on blocks.

The writing is on the wall. Shortcode-based plugins are building on a legacy foundation. They work, and they'll continue to work for years. But they're swimming against the current.

Native Gutenberg form builders are building on the same foundation WordPress itself is built on. As the block editor gains new capabilities -- better responsive controls, interactivity API improvements, new block types -- native form blocks inherit those improvements automatically.

The question isn't whether block-native forms are the future. It's whether your current form plugin is ready for it.

Try the Block-Native Approach

If you're curious what a truly native Gutenberg form builder feels like, SkunkForms is free to download. Install it, open the block editor, and add a Form block. You'll immediately feel the difference.

No separate builder. No shortcode. No new interface to learn. Just blocks -- the same way you build everything else in WordPress.

It also comes with a built-in CRM, so your form submissions don't just sit in a database table waiting for you to export them. But that's a story for another post.