Fixing CORS errors on form submit

You wired a contact form, opened DevTools, and see red text: blocked by CORS policy or No Access-Control-Allow-Origin. The submission never reached your inbox. This is one of the most common integration failures on modern Jamstack sites—and it is fixable once you know browsers enforce origin, not your feelings about www.

This guide explains why CORS happens on form POSTs, how preflight works, and the four fixes teams actually use with hosted backends like MuxForms.

What CORS is (in one paragraph)

Browsers restrict JavaScript running on https://www.example.com from reading responses from https://api.other.com unless api.other.com explicitly allows https://www.example.com via Access-Control-Allow-Origin. Pure HTML <form action="https://api.other.com"> navigations are different; fetch and XHR from your React app trigger CORS. Embeds that POST JSON also trigger OPTIONS preflight.

Symptom checklist

Fix 1: Add the exact origin to the allowlist

In MuxForms (and similar products), each form has allowed origins:

• https://www.example.com
• http://localhost:3000 for dev

Rules:

• Include scheme (https://).
• www and non-www are different—allow both or redirect consistently.
• Staging URLs need their own entries (https://staging.example.com).

After saving, hard-refresh and retry. Read the JSON body on 403—MuxForms returns Origin is not authorized for this form when CORS blocks you.

Fix 2: Use the official embed

embed.js performs schema GET, obtains a submit token, and POSTs with headers the API expects. Custom fetch without that flow often dies on 403 even when CORS headers exist.

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

Next.js wrapper: blog tutorial.

Fix 3: Submit from the server (no CORS)

Server Actions, Route Handlers, and PHP wp_remote_post are not browsers—CORS does not apply. Send the ingest secret:

POST /api/v1/forms/{id}/submit
Content-Type: application/json
X-MuxForms-Ingest-Secret: ingsec_xxxxxxxx

Documented in submit API. This is the right pattern when you refuse to maintain origin lists for every preview deployment—proxy through your server.

Fix 4: React Native and Expo

Native fetch does not send browser Origin the same way; CORS is rarely the issue. 403 usually means missing ingest secret or wrong field names (422). See collecting forms from React Native.

Expo Web is a browser—allowlist its dev origin.

Preflight in depth

When JavaScript sets Content-Type: application/json, the browser sends:

OPTIONS /api/v1/forms/{id}/submit
Origin: https://www.example.com
Access-Control-Request-Method: POST

The server must respond 204 with:

Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: POST, OPTIONS

MuxForms handles OPTIONS when ingest is configured. If preflight fails, fix allowlist before debugging POST body.

Status codes vs CORS

CORS errors sometimes mask 403—check Network tab response headers and body.

Common mistakes

1. Allowing example.com but site redirects to www.example.com.
2. Testing from Vercel preview URL without adding *.vercel.app or specific preview origin.
3. Exposing ingest secret in client bundle—use server proxy instead.
4. Forgetting honeypot _hp empty string in JSON payloads.

Related content

• HTML form without backend
• Spam controls
• Formspree-style tools (each has its own CORS rules)