Create a contact form that fits your site in a few clicks. Pick a use case, choose your fields, match your brand and copy clean HTML, CSS and JavaScript.
Start from a use case
Switching keeps your style and behavior settings.
Fields
Links the words "privacy policy" in the consent checkbox.
Messages
Messages show when the form sends without reloading the page. Turn that on under Behavior.
The address of the script or service that receives the form data. This tool only writes front-end code.
Code
Every class and data attribute in the export starts with this prefix.
Try the form here. Nothing you type is sent anywhere.
This contact form generator builds a ready-to-paste contact form for any website, complete with labels, validation and a thank-you message. Pick a use case, switch fields on or off and copy the code. That's it.
Everything runs in your browser. The output is plain HTML, CSS and a small, dependency-free script, so it works on static sites, page builders and custom themes alike. Need a form that isn't about contact, like a survey or a registration page? The HTML form generator handles any field mix. Once your form is live, the form conversion rate calculator shows how well it performs.
Each starting point sets sensible fields and copy. Change anything afterwards.
| Use case | Fields included | Good for |
|---|---|---|
| General | Name, email, subject, message, consent | Most business websites |
| Sales | Name, work email, company, team size, message | Demo and pricing requests |
| Support | Name, email, issue type, reference, message, screenshot | Help desks and product teams |
| Quote | Contact details, service, budget, timeline, project details | Agencies and freelancers |
| Feedback | Optional name and email, rating, comments | Collecting opinions after a purchase |
| Callback | Name, phone, best time to call, note | Local services and consultations |
Point the Action URL under Behavior at the script or service that should receive the messages. Only need a quick email link instead of a form? The mailto link generator builds one with the subject and message filled in. Running WordPress? IvyForms stores entries, filters spam and sends email notifications with no code at all.
A contact form generator is a web form builder tool that produces a ready-to-use contact form (HTML code, a script embed or a hosted link) from the fields and settings you pick, so you never write the markup or host the form yourself.
Choose fields, set a notification address, copy the output. That is the whole front-end workflow.
What the generator handles:
It does not receive the submission. Something else has to catch the data and turn it into an email, and that gap is where most generated forms fail.
A contact form is one of several types of forms, and the one built for inbound questions rather than sign-ups or orders.
Inside WordPress, a form plugin does the same job with its own admin screen and database, so plugins built for WordPress contact forms fit better when the site already runs on that CMS. A hand-coded form gives full control but means writing the markup, the validation and the mail script yourself.
Generators output one of three things: raw HTML and CSS code, a JavaScript or iframe embed, or a hosted link. The right one depends on whether your site accepts pasted code and whether you already have somewhere to send submissions.
| Output type | Needs a backend | Fits | Styling control |
|---|---|---|---|
| HTML and CSS code | Yes, a form endpoint | Static sites, WordPress, Wix, Squarespace, Webflow | Full |
| JavaScript or iframe embed | No, the vendor handles it | Sites that allow scripts or iframes | Vendor settings only |
| Hosted link | No, the vendor handles it | Any site, email, social profiles | Minimal |
Platform fit is rarely the blocker. Generated HTML works in a WordPress Custom HTML block, a Shopify Liquid section, a Wix HTML embed or a plain static file, and on Webflow, Squarespace, Hugo, Jekyll and Next.js sites.
MDN documents the two attributes that decide everything here: the action attribute sets where the data goes, and the method attribute sets how it travels.
A good generator outputs semantic markup with labels and accessibility attributes. Endpoint services usually ask you to sign up for a free account to get the URL that goes into the action attribute.
Pros: you own the code, no third-party script loads, and it runs on any host.
Cons: nothing is delivered until the action points to a working endpoint.
Keep the generated markup close to HTML form best practices: one label per input, the right input types, a visible submit button.
The vendor hosts the form and stores submissions, which removes the endpoint problem.
Trade-off: dependence. If the host blocks third-party scripts or iframes, the form does not render, and styling stays inside the vendor's settings.
The vendor keeps the whole page, form included, and you share a URL.
Most builders offer sharing by link next to embedding. It suits places where code cannot go, and it costs you the visitor's time on your own domain.
Works for:
Falls short for:
Three: name, email address and message. Most contact form templates treat these as the minimum, and everything else is optional.
Keep:
Add only with a reason:
Each input type also changes the generated markup, which this breakdown of common form field types covers.
Field count has a measurable cost, though sources disagree on how steep it is. Imaginary Landscape cut its contact form from 11 fields to 4 and conversion rose from 5.4% to 11.9% (case study, 2008).
An analysis of more than 40,000 landing pages found a gentler slope. Extra single-line text fields barely moved conversion, while multiple textareas and dropdowns pushed it down.
Read together, the cost sits in the heavy fields. A second one-line input is cheap, a second textarea or an unneeded dropdown is not.
The number of required fields barely changed in that test (4 before, 3 after), so Imaginary Landscape concluded that the total number of fields mattered more than the number of required ones.
Generators validate in the browser, so required fields and email format get checked before the form posts. That check is a convenience rather than protection, which is why the split between client-side and server-side validation matters for whatever receives the data.
The build takes six steps, and the last one decides whether the form works.
Where the code lives: embed builders usually keep it under a Publish or Embed tab, while endpoint services hand you a URL for the form's action attribute.
Starting from ready-made contact form templates saves most of step one, since the field order is already sensible.
Step three gets skipped more than any other. Without a visible confirmation, visitors cannot tell whether the form worked, so write one properly (see how to word a form submission confirmation message).
A form endpoint is a URL that receives the form's POST request and forwards the data as an email, a spreadsheet row or a webhook call. A generated HTML form without one submits into nothing.
MDN states the mechanism plainly: the action attribute defines where the data gets sent. If it points nowhere useful, the data goes nowhere useful.
Script embeds and hosted links skip this step because the vendor runs the backend.
Free plans differ on which of these routes they include.
A form can look perfect, show a success message and still deliver nothing. Work through the causes in this order:
Two changes address the usual causes. Send from an address on your own domain with the visitor's address in the Reply-To header, and route the mail through authenticated SMTP instead of mail().
WordPress plugins hit the same wall, as this guide to fixing a WordPress form plugin that stops sending email shows.
Test with real sends to two or three different mailboxes, including one on your own domain, before calling it fixed.
Start with a honeypot field, then add a CAPTCHA only if spam survives it. Every layer costs something, either visitor friction or a vendor quota.
A honeypot field costs nothing and catches the bots that fill every input they find. It misses bots that skip hidden fields, and some form backends warn that sophisticated bots recognize common honeypot names, so give the field a plausible name instead of "honeypot".
The mechanics are laid out in this explainer on what a honeypot is and why bots fall for it.
reCAPTCHA is free up to 10,000 assessments per month, according to Google Cloud's reCAPTCHA documentation. Without billing enabled, assessment requests past that limit return an error, while legacy SiteVerify calls keep returning success with a fixed 0.9 score and a quota warning. Either way, a busy form loses real verification until someone switches billing on.
Cloudflare's plans page (updated August 2026) lists unlimited challenges on the free plan. Turnstile belongs to a wider group of CAPTCHA alternatives built to avoid image puzzles.
Where the check runs: a CAPTCHA widget on its own protects nothing. Cloudflare's documentation says you still embed the widget and validate the token on your server, so a form posting to your own script needs that verification code.
A form backend that bundles the check does it for you. Some turn on reCAPTCHA with one click, others ship hCaptcha on their free plan using the vendor's own site key.
Plan limits decide which controls you get. A free plan may include basic spam filtering and your own reCAPTCHA key, while a custom honeypot field name sits on a higher tier.
A consent checkbox is required only when consent is your lawful basis, and when it is, the box has to start unticked. The EDPB's Guidelines 05/2020 (May 2020) state that pre-ticked boxes are not valid consent.
The 4 elements of valid consent:
Withdrawal has to be as easy as giving consent, per the EDPB's summary of the same guidance. A form that collects consent needs a stated way to take it back.
A vendor-hosted form stores your submissions, so the vendor processes personal data on your behalf. Check where it stores them, how long it keeps them and whether it offers a data processing agreement before you pick it.
The full checklist for a compliant form is in this guide to creating GDPR compliant forms.
Accessibility: WCAG success criterion 3.3.2 (Level A) requires labels or instructions wherever the form asks for input. W3C's technique H44 covers this with label elements that tie each label to its control.
A form can pass 3.3.2 and still fail criterion 1.3.1 when labels are not programmatically associated with their fields, W3C notes. Marking required fields in the label or legend (technique H90) is another accepted way to meet 3.3.2.
A CAPTCHA is part of the form, so its accessibility counts as well. Cloudflare lists WCAG 2.2 AAA compliance for Turnstile on both its free and Enterprise plans.
For a practical audit of your own markup, see this guide to form accessibility best practices.
Choose by output type first, then by what happens at the free-plan cap, because that is where these tools differ most.
| Tool type | Output | Typical free-plan catch |
|---|---|---|
| Embed builder | Embed code or share link | Vendor branding stays on forms |
| Widget platform | Script widget for HTML sites | Monthly view cap, then the widget is deactivated |
| Form endpoint | Endpoint for your own HTML | Stops accepting submissions at the monthly cap, or bills the overage |
| Endpoint with a generator | Endpoint plus generated HTML | One endpoint on the free plan; advanced features on top tiers |
Free-plan monthly submission limits: vendor pricing pages in October 2026 put them between 50 and 250 submissions a month. Widget platforms cap views instead of submissions.
The number matters less than the behavior at the cap. Some endpoints stop accepting submissions until the next month, while others keep delivering past the cap and bill the overage.
Widget platforms go a third way. When monthly views run out, the widget is deactivated until the next refresh date, so the contact form can vanish from the page.
For a site that already runs on plain HTML, a free endpoint plus generated code beats an embed. The form stays on your domain and the styling stays yours.
Embeds earn their place when nobody on the team touches code. Check whether the free plan keeps the vendor's branding on your form before you commit.
On WordPress a generator is optional, since free WordPress form plugins manage the form from the dashboard.
A generator is the wrong tool once the form needs logic, flow or data handling that its settings cannot express.
On WordPress, a form builder with conditional logic handles branching natively.
Whether a long inquiry belongs in a multi-step layout at all is a separate question, covered in multi-step forms vs single-step forms.
Everything else, a plain contact form on a small site, is what generators do well.
Want messages to land in your inbox automatically?
IvyForms gives WordPress sites a contact form with saved entries, spam filtering and instant email notifications, all without writing code.
Start from general, sales, support, quote, feedback or callback, then switch fields on or off.
Edit the wording, choose a field style and accent color, and decide what happens after someone submits.
Grab the HTML, CSS and JavaScript separately, or use the single embed block for page builders.
Yes. Use the code on personal and client projects without attribution or sign-up.
The form sends its data in the background and shows your success message in place of a page reload. If something goes wrong, visitors see your error message and can try again.
No. The JavaScript is a small, self-contained script with no dependencies. If you turn off friendly errors, the character counter and in-page sending, the form works with HTML and CSS alone.
Yes. Open a field in the Fields tab and fill in its custom error message. Leave it empty to keep the default wording, such as "Enter a valid email address."
Yes. Load the script once per page and it handles every contact form on that page. Give each style its own class prefix if you mix different looks on one site.
Your form is saved automatically in this browser. Use Export to download it as a JSON file and Import to open it again on another device.