How to send an HTML form to email without a backend

“Just email me when someone fills out the form” is the most common request in web development—and the most repeated backend nobody wanted to maintain. You can send an HTML form to email without writing Node, PHP, or Python in your repo. You do it by pointing the form at a hosted form endpoint or by loading a vendor embed that POSTs on your behalf.

This pillar guide walks through the patterns, tradeoffs, and failure modes (spam, deliverability, no archive) so you pick the right tool—not only the shortest tutorial snippet.

Pattern 1: HTML action to a hosted URL

The classic static-site approach:

<form action="https://www.muxforms.com/api/v1/forms/FORM_UUID/submit" method="POST">
  <input type="email" name="email" required />
  <textarea name="message" required></textarea>
  <button type="submit">Send</button>
</form>

Replace the URL with your vendor (Formspree, Web3Forms, etc.). Field names must match what the backend expects.

Pros: Zero JavaScript, works on the oldest hosts.
Cons: Browser navigation on submit unless you use AJAX; CORS if you switch to fetch later; limited UX for validation.

For MuxForms, most teams use embed.js instead of raw action URLs so validation and tokens are handled—see Next.js tutorial.

Pattern 2: Embed script (schema from dashboard)

<div data-form-id="FORM_UUID"></div>
<script src="https://www.muxforms.com/embed.js" defer></script>

The script fetches your field schema, renders inputs, and POSTs with the correct headers. Marketers change fields without redeploying HTML.

Pros: One inbox, spam settings, styling tokens in dashboard.
Cons: Requires allowing your site origin (CORS guide).

WordPress: tutorial without a plugin.
Static hosts: static-site roundup.

Pattern 3: fetch from the browser

await fetch("https://www.muxforms.com/api/v1/forms/FORM_UUID/submit", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ email: "a@b.com", message: "Hello", _hp: "" }),
});

You must satisfy CORS and often a submit token from GET /api/v1/forms/{id}. Hand-rolling this is error-prone; embed or server proxy is safer.

Pattern 4: Server Action or API route (still “no backend” in your product sense)

Your Next.js app can POST server-side with an ingest secret—no public backend repo for mail, but one server function holds the secret:

await fetch(submitUrl, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-MuxForms-Ingest-Secret": process.env.MUXFORMS_INGEST_SECRET!,
  },
  body: JSON.stringify(payload),
});

The “backend” is still MuxForms; you only host a thin forwarder. Details in API docs.

Email-only services (no real inbox)

Email-only is fine for hackathon pages. Production marketing sites usually want search and webhooks—compare Formspree alternatives.

Deliverability reality

Without a backend you outsource SMTP. Good vendors send from verified domains and handle bounces; bad setups land in spam.

WordPress wp_mail() is the cautionary tale—plugins fight hosting blocks. Hosted backends skip PHP mail entirely.

Spam on public forms

Any public action URL will be discovered. Combine:

• Honeypot field left empty by real users
• Rate limits
• Turnstile or reCAPTCHA when needed

Read the dedicated guide: honeypot vs Turnstile vs reCAPTCHA.

Checklist before launch

1. Create form; match field names in HTML or JSON.
2. Add https://www.yourdomain.com to allowlist (and localhost for dev).
3. Set notification email; send test submission.
4. Confirm row appears in inbox—not only email.
5. Add spam controls before ads go live.

When MuxForms is a good fit

• Multiple sites or React Native plus web
• You want unlimited forms on one plan after trial
• You need webhooks without enterprise tiers

When a free access-key tool covers your volume, use it honestly—see Web3Forms comparison.

Related guides

• What is a form backend?
• Fixing CORS errors