HTML Form Action Attribute: Complete Guide with Examples

What is the form action attribute?

The action attribute on an HTML <form> element specifies the URL where the form data should be sent when the user clicks the submit button. Without it, the form submits to the current page URL — which is almost never what you want for a contact form.

Here's the simplest working example:

<form action="https://splitforms.com/api/submit" method="POST">
  <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY">
  <label>Name <input type="text" name="name" required></label>
  <label>Email <input type="email" name="email" required></label>
  <label>Message <textarea name="message" required></textarea></label>
  <button type="submit">Send</button>
</form>

When the visitor clicks Send, the browser collects all named fields, encodes them as application/x-www-form-urlencoded (the default content type for POST forms), and sends an HTTP POST request to the URL in action. The server at that URL receives the data and does something with it — saves it, emails it, stores it in a database.

POST vs GET: which method should you use?

The method attribute works alongside action. It controls the HTTP verb the browser uses to send the data. Two practical choices:

• POST — sends data in the request body. Not visible in the URL. No practical size limit. Required for file uploads. This is what you want for contact forms, lead capture, and any form with sensitive data.
• GET — appends data to the URL as query parameters (e.g. ?name=John&email=john@example.com). Visible in browser history and server logs. Capped at roughly 2,000 characters in most browsers. Useful only for search forms and filtering.

Rule of thumb: if your form has a textarea, an email field, or any data you wouldn't want in a URL — use POST.

<!-- POST: data in request body (use this for contact forms) -->
<form action="https://splitforms.com/api/submit" method="POST">

<!-- GET: data in URL query params (search forms only) -->
<form action="/search" method="GET">

Relative vs absolute action URLs

The action attribute accepts both relative and absolute URLs. The choice matters:

• Absolute URL (https://splitforms.com/api/submit) — the browser sends the request to that exact URL regardless of where the form lives. This is what you use with a hosted form backend.
• Relative URL (/api/submit) — the browser resolves it against the current page origin. If your site is https://mysite.com and action is /api/submit, the request goes to https://mysite.com/api/submit. This is what you use with a same-origin API route.
• Root-relative URL (/api/submit) — same as relative but always starts from the domain root.

For static sites hosted on Vercel, Netlify, Cloudflare Pages, GitHub Pages, or S3, you almost always want an absolute URL pointing to a hosted form backend — because there's no server on your origin to handle the POST request.

Form content types: urlencoded, multipart, and JSON

The enctype attribute controls how the browser encodes form data before sending. Three options:

<!-- Default: application/x-www-form-urlencoded -->
<form action="/api/submit" method="POST">
  <!-- works everywhere, no enctype needed -->

<!-- File uploads: multipart/form-data (REQUIRED for file inputs) -->
<form action="/api/submit" method="POST" enctype="multipart/form-data">
  <input type="file" name="attachment">

<!-- JSON: text/plain (hack, not recommended — use fetch instead) -->
<!-- Most servers don't parse this correctly from a native form -->

For contact forms without file uploads, the default application/x-www-form-urlencoded is correct. Every form backend and server framework parses it automatically. Only switch to multipart/form-data when you have a <input type="file"> element.

If you need to send JSON (e.g. your API only accepts application/json), you can't do it with a native form — you need JavaScript with fetch(). See the section below.

Using fetch() instead of the action attribute

The action attribute triggers a full page navigation on submit. For a smoother UX (no page reload, inline success/error messages), intercept the submit event and send the data with fetch():

<form id="contact-form">
  <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY">
  <input type="text" name="name" required>
  <input type="email" name="email" required>
  <textarea name="message" required></textarea>
  <button type="submit">Send</button>
</form>

<script>
const form = document.getElementById('contact-form');

form.addEventListener('submit', async (e) => {
  e.preventDefault(); // stop the page reload

  const formData = new FormData(form);
  const response = await fetch('https://splitforms.com/api/submit', {
    method: 'POST',
    body: formData,
  });

  const result = await response.json();
  if (result.success) {
    form.reset();
    alert('Message sent!');
  } else {
    alert('Something went wrong: ' + result.message);
  }
});
</script>

Key points: FormData automatically collects all named fields, e.preventDefault() stops the native form submission, and fetch with FormData sets the correct content type (multipart/form-data) automatically. Always keep the action attribute on the form as a fallback in case JavaScript fails — progressive enhancement.

Using splitforms as your form action endpoint

Instead of building a backend, deploying it, maintaining SMTP, and dealing with spam — point your form action at https://splitforms.com/api/submit and you're done. Here's what happens on submit:

1. The browser POSTs form data to the splitforms endpoint.
2. Splitforms validates your access key and stores the submission.
3. You get an email notification at the address configured in your dashboard.
4. AI spam filtering runs automatically — no CAPTCHA needed.
5. The visitor is redirected to your thank-you page (configurable).

<form action="https://splitforms.com/api/submit" method="POST">
  <input type="hidden" name="access_key" value="YOUR_ACCESS_KEY">
  <input type="hidden" name="redirect" value="https://yoursite.com/thanks">
  <input type="text" name="name" placeholder="Name" required>
  <input type="email" name="email" placeholder="Email" required>
  <textarea name="message" placeholder="Message" required></textarea>
  <!-- Honeypot spam protection -->
  <input type="checkbox" name="botcheck" class="hidden" tabindex="-1" autocomplete="off">
  <button type="submit">Send Message</button>
</form>

Plans: free up to 500 submissions/month, Starter at $1/month for webhooks, Pro at $5/month for 5,000 submissions plus custom SMTP. Email hello@splitforms.com with questions, or get your free access key.

For framework-specific guides, see Next.js, React, Astro, and Svelte integration pages.

Common mistakes and how to fix them

• Missing name attribute on inputs. The browser only sends fields that have a name. An input without name is silently dropped. Always add name="email", not just id="email".
• Forgetting method="POST". The default method is GET, which appends data to the URL. For contact forms, always set method="POST" explicitly.
• Wrong content type for file uploads. If you have <input type="file">, you must set enctype="multipart/form-data" or the file won't be sent.
• CORS errors with fetch. If you're using fetch() to submit to a cross-origin endpoint, the server must include Access-Control-Allow-Origin in its response. Native form submissions (with action) don't trigger CORS — only fetch() does.
• Submit button outside the form. The <button type="submit"> must be inside the <form> element. If it's outside, the form won't submit.

For more debugging tips, see contact form not working and CORS error fix guide.

FAQ

More reads: HTML contact form code, all blog posts, and the splitforms docs.