Form Submission 405 Error: Why Static Hosts Reject POST (2026 Fix)

What 405 Method Not Allowed actually means

HTTP status codes in the 4xx range mean "your request was understood and rejected." The 405 is unusually specific: the URL exists, but not for the HTTP method you used. Compare:

• 404 Not Found — nothing lives at this URL for any method.
• 405 Method Not Allowed — something lives here, but it only answers (typically) GET and HEAD. Your POST was refused before any application logic ran.

Per the HTTP spec (RFC 9110 §15.5.6), a 405 response should include an Allow header listing the methods the resource supports. Static hosts generally do:

HTTP/2 405
allow: GET, HEAD
content-type: text/html

allow: GET, HEAD is the smoking gun. It says: this URL is a file, not a program. You can read it; you cannot send it anything. If you're getting a different status entirely, start with the broader contact form debugging guide — this post is specifically about the 405.

Why static hosts can't accept POST — by design

A static host is, at its core, a CDN in front of a folder of files produced by your build. When a request for /contact arrives, the edge node looks up contact/index.html and streams the bytes back. That lookup-and-stream operation is the entire request lifecycle. There is:

• No process that parses a request body — the body of your POST is discarded unread.
• No database or mailer to do anything with the data even if it were parsed.
• No application code at all between the TLS termination and the file system.

This isn't a limitation to be patched; it's the trade that makes static hosting fast, cheap, and effectively unhackable. The cost is that anything dynamic — and accepting a form submission is dynamic — must happen somewhere else: in a function the host runs on demand, or on a third-party server you point your form at.

This is why the same HTML that worked on your old PHP shared host (where contact.php was a program) breaks the moment you migrate to Netlify or Pages. The markup didn't break — the execution environment behind the URL disappeared. The full landscape of options is covered in static site contact forms and working contact forms for JAMstack.

Host-by-host: what each platform does with your POST

GitHub Pages

Purely static, no escape hatch. POST to any github.io URL returns 405. There is no functions product and no forms feature — an external endpoint is the only option. (Setup guide: add a contact form to GitHub Pages.)

Netlify

Static paths 404/405 on POST, but Netlify has two escape hatches: Netlify Forms (add data-netlify="true" so the build scans and registers the form — with a hidden form-name input if your form renders via JavaScript) and Netlify Functions. Gotchas: forms injected client-side after build are never detected, and the free Forms tier caps at 100 submissions/month before charging. Details and the no-functions alternative: Netlify contact form without functions.

Vercel

No built-in form handling. Static output 405s on POST. The platform answer is a serverless function — in Next.js, a route handler:

// app/api/contact/route.ts
export async function POST(req: Request) {
  const data = await req.formData();
  // ...validate, store, send email yourself
  return Response.json({ ok: true });
}

Note the function only receives the data — you still have to build validation, spam filtering, and email sending (the genuinely hard part). And if you build with output: "export", API routes don't exist at all. The trade-offs are covered in server actions vs form backend.

Cloudflare Pages / S3 + CloudFront

Same story: static assets are GET-only. Cloudflare offers Pages Functions; S3 offers nothing (S3 returns 405 Method Not Allowed with an XML error body for POST to a website endpoint). External endpoint or function, your pick.

Confirm the diagnosis with curl

Take your HTML and JavaScript out of the equation. From a terminal:

# 1. Does the page itself accept POST? (Expect 405 on a static host)
curl -i -X POST -d "name=test&email=t@example.com" https://yoursite.com/contact

# 2. What methods ARE allowed? Read the Allow header in the response.

# 3. Does your intended endpoint accept POST? (Expect 200)
curl -i -X POST \
  -d "access_key=YOUR_ACCESS_KEY&email=t@example.com&message=hello" \
  https://splitforms.com/api/submit

If (1) returns 405 and (3) returns 200, the entire fix is one attribute in your HTML — the action. No build changes, no redeploy logic, nothing else. If (3) fails too, the problem is the payload (missing key, wrong Content-Type); read the response body, which names the issue.

One more 405 flavor worth knowing: redirects can convert your POST into a GET-then-405 or strip the body. If your form posts to http:// and the host 301s to https://, or posts to /submit which redirects to /submit/, browsers re-issue the request in ways that lose the method or body. Check the Network tab for a 301/308 before the 405, and always use the exact, final, https URL in action.

The three fixes, ranked

1. Point the form at a hosted form endpoint (fastest)

Change one attribute and the 405 is gone, on any host:

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

splitforms accepts the POST your host can't: submissions hit your dashboard, spam is filtered, and Starter can fan out to inbox, Slack, or any webhook. Free for 500 submissions/month, Starter at $1/mo for delivery, Pro at $5/mo for 5,000. No build config, works the same on every static host. (Compare options in best form backends or against Formspree.)

2. Use your host's native feature (if it has one)

Netlify Forms works for simple cases if you accept build-time detection quirks and the 100/month free cap. Nothing comparable exists on Vercel, GitHub Pages, or S3.

3. Write a serverless function (most control, most work)

Right when you need custom logic — writing to your own database, multi-step workflows. You own validation, spam defense, email deliverability (see why form emails go to spam), and uptime. For a contact form, that's a lot of infrastructure for one <form> tag.

Verify the fix end to end

1. Deploy the updated action and hard-refresh the live page (CDNs cache HTML — make sure you're testing the new markup).
2. Submit a real test entry from the deployed site, not localhost.
3. Network tab: the POST should return 200, no redirect chain in front of it.
4. Confirm the email notification arrives and the submission shows in the dashboard.
5. Run the rest of the pre-launch form test checklist — a form that returns 200 can still fail on the email leg.

FAQ

Skip the fix debugging — switch the action to https://splitforms.com/api/submit and it just works. Get a free access key.

Related: CORS errors on form submission, HTML form to email without PHP, JAMstack form backend, and the splitforms API reference.