When I prefer HTML to a visual form builder

HTML is a useful editing surface when you already know the structure you want. You can keep labels, attributes, and layout together without opening a settings panel for each change.

That is a workflow preference, not a reason to rule out visual editing. Core Forms supports both, and the better choice depends on who will maintain the form.

Where HTML helps me

I prefer editing markup directly when the job is mostly layout: labels, fields, and a small number of conditions. The structure is visible, and I can review a saved HTML file with ordinary code tools.

That does not make every visual builder slow or every generated form heavy. Frontend performance depends on what gets loaded for visitors. A JSON export can also be versioned and reviewed; whether it imports cleanly depends on the plugin’s format and supported versions.

Core Forms keeps both editing paths available. Use the visual editor when field settings or step organization are easier to manage there, and test round trips before treating either exported representation as a reusable template.

What I do instead

The full workflow:

1. Write the form in HTML. A new Core Form, paste in the markup. Six fields, three minutes.

2. Add data-show-if for conditionals. I covered this in the conditional fields piece. Two attributes, no UI.

3. Wire actions. Email notification, Mailchimp, Notion, Slack, whatever. Each is a 30-second config in the Actions tab.

4. Drop it into the page. Shortcode in classic editor or Gutenberg block in FSE. Done.

Include validation, notification, and mobile checks in the work, whichever editor you use.

The time depends on the form and the person editing it. Compare the work your team actually repeats.

Why this scales

When I have 12 client sites with similar contact forms, I have a _template.html file in my notes. New client, copy-paste the template into Core Forms, change two field labels, ship.

Keep reusable templates in a format your team can review. HTML is useful for markup-led forms; a structured export can preserve richer field and layout settings. Test imports and previews on the destination site rather than assuming either format is universally portable.

Where visual editing helps

The visual editor makes field types and settings discoverable. It also provides step controls and a working preview.

• Use Add field to choose a field type.
• Select a field to edit its label, validation, and other settings.
• Use Form layout → Multi-step when the form needs named sections.
• Use Save & preview to check the saved result.

A preview is useful feedback, but it does not replace testing the real embed and its configured actions.

When you’d disagree

If you:

• Build forms occasionally.
• Don’t write HTML by reflex (you’re a designer or content lead, not a developer).
• Need a non-technical client to edit forms themselves.

Then a form builder probably wins for you. The fastest path is the one you can use without thinking about it.

I write HTML by reflex. So my fast path is HTML. Yours might not be.

What this post isn’t

Use HTML when it gives you clearer control. Use visual editing when it makes changes easier to understand. Neither choice establishes frontend performance by itself.

Core Forms offers Visual and Code modes. Use the visual step editor for multi-step layouts and Code for direct HTML editing. Pick the workflow that fits the change.

The next step

Pick one form on one site that’s stuck in a builder. Look at the rendered HTML in DevTools. Then write the same form in 30 lines of HTML.

Notice which one you’d rather maintain in two years.

For sites that are still on a builder by default, Core Forms is the alternative that doesn’t fight you. The HTML stays HTML.

The HTML form examples show what the code-first approach looks like for a dozen common forms.