AJAX contact form with vanilla JavaScript

Copy the HTML + script snippet above into any page. Replace YOUR_ACCESS_KEY with your splitforms key. The script attaches a submit listener, builds FormData, posts to splitforms.com, and renders the response inline. No build step, no npm install.

Yes. Use jQuery's $.post or $.ajax with processData: false, contentType: false so it doesn't double-encode the FormData. Modern browsers don't need jQuery for this — but the splitforms endpoint accepts requests from any HTTP client.

Check data.success after parsing the JSON response. If false, render data.message into your status element. Wrap the fetch in try/catch for network errors, and check res.ok for HTTP-level errors — they're three separate failure modes.

Yes — anything that POSTs FormData to a URL works. The splitforms endpoint doesn't care about the client library, only about the request body and the access_key field.

Two options. (1) Inline success: render a styled <p> with aria-live after a 2xx response (default in our snippet). (2) Configure a URL in Dashboard → Form settings → Redirect and let the browser submit natively for a server-side 302.

The AJAX version requires JS. For a no-JS fallback, add action="https://splitforms.com/api/submit" method="POST" to the form tag and configure any thank-you URL in the splitforms dashboard. With JS, your handler intercepts; without JS, the browser performs a native form POST.

Without preventDefault, the browser does its own form submission to wherever the form's action attribute points (or the current page) AND your fetch runs. You see a flash, the page reloads, and your handler's effects are lost.

new FormData(form) skips inputs without a name attribute, skips disabled inputs, skips unchecked checkboxes/radios. If a field doesn't show up in your splitforms inbox, check whether it's disabled at submit time.

If splitforms returns a 401 (bad key) or 429 (rate limit), fetch resolves successfully. You have to check res.ok or data.success yourself. Wrapping in try/catch only catches network failures, not HTTP errors.

Without disabling the button on the first click, a quick double-click sends two POSTs. Both succeed; the user sees one success message; you see two submissions. Always set button.disabled = true at the start of the handler.

If your site has a Content-Security-Policy header with connect-src 'self', fetch to splitforms.com is blocked. Add it explicitly: connect-src 'self' https://splitforms.com.

Common mistake: writing fetch(url, { method: 'POST', headers: { 'Content-Type': 'multipart/form-data' }, body: formData }). The browser silently fails to append the boundary parameter (; boundary=---WebKitFormBoundary…) because you've overridden its automatic header — splitforms's parser then sees a malformed body and returns 400. Fix: omit the headers object entirely. The browser sets Content-Type correctly when you pass a FormData instance as the body. Same trap when copying example code from old jQuery tutorials that hardcode the header.

Vanilla JS / AJAX forms have been the no-framework default since jQuery's heyday. Without splitforms, the 'AJAX' part is one fetch line; the operational part is everything else: a backend route, an SMTP provider, a database for submissions, a honeypot or reCAPTCHA, a thank-you page, error handling for HTTP 4xx/5xx, retry logic. For 'JS-only on a static host' setups (Cloudflare Pages, GitHub Pages, S3), there's literally no server to run the route on — historically that meant Formspree, Formspark, Web3Forms, Basin. Splitforms is the modern entry: same shape, better free tier, better spam filtering, and signed webhooks from Pro.

Vanilla JS deploys to any static host — the snippet is HTML + inline <script>, no build step. CSP: if your site sets connect-src 'self', add https://splitforms.com to the directive or fetch is blocked. Browser support: native fetch is in every browser back to Edge 18 — the snippet runs without polyfills on every market-share-relevant browser. The progressive-enhancement variant (Pattern B) keeps the form working when JS fails to load — useful on flaky networks, ad-blocked clients, or for accessibility tools that disable JS.