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 Netlify Forms remains tied to Netlify hosting even though current credit plans include unlimited submissions. 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.

Unexpected token '<', "<!DOCTYPE "... is not valid JSON

This is how a 405 (or 404) shows up when the form submits with fetch(): the host answered with an HTML error page, and res.json() choked on its first character, the < of <!DOCTYPE html>. The JSON error hides the real status, so check the Network tab for the 405 underneath. Each browser words the parse error differently:

Tested in Chrome 154.0.8037.97 and Safari 26.6.2 on macOS 26.6.2, on October 2, 2026. Firefox wasn't part of that run, so Firefox wording is quoted from Firefox's own source or MDN, linked in each row.

Two changes make the real error visible. Check res.ok before parsing, and only call res.json() when the response says it is JSON:

const res = await fetch(form.action, { method: 'POST', body: new FormData(form) });
const isJson = (res.headers.get('content-type') || '').includes('application/json');

if (!res.ok) {
  throw new Error('Request failed (' + res.status + ')'); // e.g. 405 from a static host
}
const data = isJson ? await res.json() : null;

Then fix the 405 itself with one of the fixes below. More on reading API error bodies in how to send form data to an API.

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, owner email delivery works on every plan, and Pro can fan out to Slack or any signed webhook. Free for 500 submissions total, then Pro at $5/mo for 5,000 a month with webhooks. 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 and host coupling. Current credit plans include unlimited form submissions. Nothing comparable is built into 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.

Other form problems and fixes

• Contact form not working
• HTML form not submitting
• Form submission canceled (form not connected)
• 401 Unauthorized
• CORS error
• Form sends but no email arrives
• Emails land in spam
• WordPress form not sending
• Elementor form not sending
• Gravity Forms not sending
• WPForms not sending
• Ninja Forms not sending
• mailto: action not working
• Works in preview but not live
• Netlify form not working
• Webflow form not working
• Wix form not working
• Framer form not working
• Required attribute not working
• input type=number maxlength not working
• autocomplete="off" not working
• Form resubmission on refresh
• Duplicate form submissions

Still stuck? Test your endpoint with our free Form Action Tester or contact splitforms support.

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.