Beautifully styled contact form with Tailwind CSS
A polished, accessible, dark-mode-ready Tailwind contact form template. Drop into any project that has Tailwind configured — Next.js, React, Astro, Vue, Svelte, plain HTML. Includes focus rings, validation states, loading spinner, and a working backend.
What your Tailwind CSS contact form actually looks like.
Drop-in form backend with spam filtering, signed webhooks, and a real submissions dashboard. The same code in this preview is what you copy into your Tailwind CSS project — no SDK, no plugin, no PHP.
- ✓1,000 submissions per month, free forever
- ✓Honeypot + AI spam classifier on every plan
- ✓Signed webhooks to Slack, Discord, your server
Ship a Tailwind CSS contact form without a backend.
No SDK, no PHP, no plugin. Your form posts standard FormData to one URL — submissions land in your inbox.
Get your free access key
Verify your email and your access key is generated instantly. Free for 1,000 submissions per month, forever.
By signing up, you agree to our terms and privacy policy.
Drop in the Tailwind CSS code
Copy the Tailwind CSS snippet on the right and paste it into your project. Replace YOUR_ACCESS_KEY with the key from step 1.
Submissions land in your inbox
Hits your dashboard and email in seconds. Forward to Slack, Discord, Sheets, Notion, or any signed webhook URL.
Try it now — no signup, no key.
This is a styled HTML preview of what your Tailwind CSS form will look like. Submitting opens a confirmation, no real request is sent.
Your Tailwind CSS form posts FormData to /api/submit. Splitforms validates the access key, runs the spam classifier, and forwards the parsed submission to your inbox plus the dashboard.
- →14ms median round-trip from the edge.
- →Honeypot + classifier, no CAPTCHA.
- →Per-domain key locking out of the box.
{
"access_key": "sk_live_4f9a_••••",
"name": "Maya Iyer",
"email": "maya@studio71.co",
"message": "…"
}How to ship this without regrets.
Five rules that make the difference between a form that works in the demo and a form that survives launch traffic.
- 01
Wrap each input in a `<div>` with the label — gives you a stable spacing block. Easier to reorder fields without re-adding `mb-4` everywhere.
- 02
Use `focus:ring-2 focus:ring-offset-2` for accessibility — sighted keyboard users need to see where focus is, and screen readers don't care.
- 03
Add `aria-busy={status === 'loading'}` to the form element. Tailwind doesn't style aria-busy by default, but screen readers announce the change.
- 04
For dark mode, define your accent color as a CSS variable in @layer base — then `bg-[var(--accent)]` works regardless of light/dark.
- 05
Don't use `disabled:opacity-50` alone for the submit button — pair with `disabled:cursor-not-allowed` and `disabled:bg-gray-400` so the state is unmistakable.
What bites people who skip the docs.
Worth a 60-second skim before you ship to production. Each one has caused a Tailwind CSS support ticket at least once.
JIT mode purges classes inside template strings
If you build the form HTML inside a JS template literal, Tailwind's JIT can't see your classes and purges them. Either move the markup into a .html / .tsx / .vue file, or add the classes to your safelist in tailwind.config.js.
Tailwind 4's @theme replaces tailwind.config.js — focus colors break
Tailwind 4 (released 2026) moved theme tokens into CSS via @theme { … }. If you copy a Tailwind 3 snippet using focus:ring-orange-500, the orange-500 token has to be defined in your @theme block or it falls back to no ring color. Use a CSS variable: focus:ring-[var(--accent)] for portability.
Form gets no styling at all — Preflight not loaded
If you're embedding the form inside a Shadow DOM, iframe, or a CMS that strips global CSS, Tailwind's Preflight (the global reset) doesn't apply. Inputs render with browser-default white backgrounds, ignoring bg-white if you set it in @apply but not as a utility on the element. Always use utilities directly on the input.
Dark mode classes need `class` strategy explicitly set
Tailwind defaults to media-query dark mode (prefers-color-scheme). If your form has dark:bg-gray-900 and you toggle dark mode via a class on <html>, you need darkMode: 'class' in tailwind.config.js (Tailwind 3) or @variant dark (.dark &) in your CSS (Tailwind 4).
@tailwindcss/forms plugin overrides splitforms styling
The official forms plugin resets input styles aggressively. Combined with our pre-styled snippet, you may get double-padded inputs. Either remove @tailwindcss/forms from your config, or use class="form-input" and let the plugin style everything.
peer-invalid + required fires on first paint, painting your form red on load
Adding peer-invalid:border-red-500 to inputs styled by a sibling peer class seems clean — but the :invalid pseudo-class is true the moment a required empty input renders, so the whole form lights up red before the user has typed anything. Combine with :user-invalid (modern browsers) or guard with peer-[:not(:placeholder-shown)]:peer-invalid:border-red-500 so red only appears after the user has actually interacted. Tailwind 3.4+ adds the user-invalid variant directly; earlier versions need an arbitrary variant.
How Tailwind CSS handles forms without splitforms.
The shape of the problem before splitforms enters the picture — and the gap it fills for Tailwind CSS specifically.
Tailwind is a styling layer — it has no opinion on form submission, networking, or backend. The 'native' approach means writing utility classes for visual treatment and bringing your own delivery mechanism: a Next.js route handler, a Vite + React + fetch combo, an HTMX endpoint, etc. Tailwind UI ($299 one-time) sells styled form templates but doesn't include a backend either. Tailwind v4's @theme directive changes how tokens are defined, not what forms do. The shape of the problem stays: utility classes for look-and-feel, splitforms for delivery. Drop the snippet on this page into any framework with Tailwind configured and you have a styled, working form in 60 seconds.
Two ways to ship splitforms on Tailwind CSS.
Pick the pattern that matches your constraints — JS budget, key-exposure tolerance, server-side opacity. Both produce the same result.
Pattern A — utility-first inline styles
Every input gets utilities directly on the element — explicit, JIT-safe, no @apply indirection. Works in HTML, JSX, TSX, Vue, Svelte, Astro identically.
Pattern B — dark-mode + accessible focus states (Tailwind v4)
Pairs dark: variants with focus-visible: for keyboard-only focus rings. Uses CSS variables for accent color so the same component works in light/dark without rewriting utilities.
Shipping Tailwind CSS + splitforms to production.
Host-specific gotchas, env-var conventions, and the boring-but-load-bearing details for putting this on the public internet.
Tailwind is purely a build-time concern — utilities are compiled into your CSS bundle, then deployed as static assets. JIT mode (default in v3+) and the v4 engine both purge unused classes; if you build form HTML inside a JS template literal at runtime, Tailwind can't see those classes and purges them — add to safelist or move markup into source files. Works on every host. For dark mode toggled via class, set darkMode: 'class' in v3 config or use @variant dark (.dark &) in v4 CSS. The @tailwindcss/forms plugin resets input styles aggressively — pick one (plugin OR explicit utilities), not both.
splitforms vs native tailwind css.
What you get for free vs what you build, pay for, or do without.
Dark-mode-ready variant with loading spinner
Same form, plus dark-mode classes, an inline SVG spinner during submit, and accessible aria-live for status changes. Tailwind 3 and 4 compatible.
Things developers ask before they integrate.
Direct answers, no marketing fluff. Missing one? Email hello@splitforms.com.
Ship your Tailwind CSS contact form in 60 seconds.
1,000 free submissions per month. No credit card. Lock the access key to your domains, paste the snippet, watch submissions land in your inbox.