Contact form for SvelteKit apps

Two paths. (1) Client-side fetch (snippet above): drop a .svelte file under src/routes/contact/+page.svelte, no server file needed. (2) Form action with progressive enhancement: see the alternative-pattern snippet — adds a +page.server.ts and uses use:enhance.

Yes. The form action just needs to POST FormData to splitforms.com from your +page.server.ts. The alternative-pattern snippet shows the full flow including error handling and redirect.

If using form actions, return fail(400, { message }) from the action — SvelteKit exposes it via the form prop. If using client fetch, render messages from data.message in your status state.

Yes — that's the recommended progressive-enhancement pattern. use:enhance with no arguments uses the default behavior: the form posts traditionally without JS, AJAXes with JS, and the page state updates without a full reload either way.

From a form action: throw redirect(303, '/thanks'). From client fetch: navigate with goto('/thanks'). Or skip both and render an inline success message inside {#if status === 'ok'}.

Yes. Vercel, Netlify, Node, Cloudflare Workers, Cloudflare Pages, static, deno — all of them. The form posts to splitforms.com from the browser, so the adapter only matters for SSR rendering of the form page itself.

If you use +page.server.ts form actions, the form's action attribute must be ?/contact (or whatever you named it) — not /api/contact. Forgetting the ?/ prefix routes to a 404 because SvelteKit doesn't recognize it as an action.

use:enhance without arguments uses default progressive-enhancement behavior — which calls the form action and re-renders. If you need custom logic (toast on error, etc.), return a function: use:enhance={({ formData, cancel }) => async ({ result }) => …}.

If you use a SvelteKit form action that proxies to splitforms.com via fetch, the round-trip eats your CF Worker time budget on cold start. Skip the proxy: have the form POST directly to splitforms.com from the client (the snippet above does this).

$env/static/public is inlined at build time (faster, but key is in the bundle). $env/dynamic/public is read at runtime (slower, but rotatable without rebuild). For the splitforms key, static is fine if you've locked the key to your domain.

If you try to read the splitforms response in +page.server.ts's load(), you'll find it's a separate request. Form action results are passed via the form prop on the page component, not via load. Read them as export let form.

If your +page.server.ts exports actions = { contact: async () => {…}, newsletter: async () => {…} } and your form posts to ?/contact, SvelteKit dispatches by the URL query — but the submitter button must also have formaction="?/contact" if you have multiple submit buttons in one form. Browsers send only the clicked submitter's formaction, so a stray button targeting ?/newsletter will hit the wrong action even when the form's main action is ?/contact. Symptom: submissions inexplicably trigger the wrong handler. Audit every <button type="submit"> for stale formaction attributes left over from layout iteration.

SvelteKit's headline form story is form actions — write a default-exported actions object in +page.server.ts, and SvelteKit handles FormData parsing, progressive enhancement (use:enhance), and result passing via the form prop. It's elegant DX — but it doesn't deliver email. You still write the SMTP integration, the spam-filter logic, the database for storing submissions, the webhook fan-out. The result is a form action that's ~80% boilerplate and ~20% your business logic. Splitforms collapses the boilerplate: the form posts directly from the browser to splitforms.com, the form action becomes a thin proxy (or you skip it entirely), and the operational layer disappears.

SvelteKit's adapter system is the deployment story: @sveltejs/adapter-vercel, -netlify, -cloudflare, -cloudflare-workers, -node, -static. The form's POST is cross-origin to splitforms regardless of adapter. On Cloudflare Pages/Workers (free tier: 10ms CPU per request), avoid Pattern B — the form action's fetch round-trip eats your budget; use Pattern A. On Vercel/Netlify, both patterns work with no measurable difference. $env/static/public inlines at build time (use for client-exposed keys); $env/static/private is server-only (use for Pattern B's server-action key). Domain-lock the access key.