Static Forms in Astro: Handling Submissions Without a Server

Static Forms in Astro: Handling Submissions Without a Server with onsubmit.dev (form backend)

Astro is a great fit for content-heavy sites that ship very little JavaScript, but that creates an interesting problem as soon as you add a contact form: where does the POST request go? With onsubmit.dev (form backend), an Astro site can submit forms to an external endpoint instead of adding its own API route or server.

This is particularly useful for Astro projects deployed as static files to a CDN, GitHub Pages, or another static host. You can keep the site static while still accepting contact requests, feedback, registrations, and similar submissions.

Start with the zero-JavaScript pattern

The simplest approach is also the most aligned with Astro's philosophy: use the browser's native form submission behavior.

You don't need a hydrated component merely to collect a few fields. A regular HTML form can make a POST request directly to a form backend:

---
// src/pages/contact.astro
---

<form method="POST" action="https://onsubmit.dev/f/YOUR_FORM_ID">
  <label>
    Name
    <input type="text" name="name" required />
  </label>

  <label>
    Email
    <input type="email" name="email" required />
  </label>

  <label>
    Message
    <textarea name="message" required></textarea>
  </label>

  <button type="submit">Send message</button>
</form>

Replace YOUR_FORM_ID with the endpoint supplied for your form.

There is no client framework involved here. The browser serializes the named fields and sends them directly when the visitor clicks the button.

That has several nice properties for an Astro project:

• No Astro server endpoint is required.
• No React, Vue, or other client runtime needs to be hydrated.
• The form still works when JavaScript is unavailable.
• Your static deployment remains static.

It is worth remembering that native HTML already does a lot of work. required, type="email", labels, and standard browser submission cover many simple forms without additional JavaScript.

Where astro-onsubmit fits

For Astro-specific integration, astro-onsubmit provides a convenient way to connect an Astro project to the service. Check the current Astro integration documentation before adding it, since package APIs and configuration can change over time.

The important architectural point is that form handling doesn't require turning the entire page into an interactive application. Astro can continue rendering HTML at build time while the external service owns the server-side submission endpoint.

This differs from creating something such as:

src/pages/api/contact.ts

An API route means you need a deployment target capable of executing that server code. Sending the form to a hosted endpoint removes that requirement.

Progressive enhancement

The native form should ideally remain the baseline. JavaScript can then enhance the experience rather than becoming a prerequisite for submitting the form.

For example, an enhanced version might intercept the browser submission to:

• Show an inline loading state
• Submit without navigating away
• Render success feedback in place
• Display validation or server errors next to the form

If the enhancement fails to load, the original method and action still provide a working submission path.

This approach is especially natural in Astro because it prevents a small contact form from becoming the reason you ship a substantial client-side runtime.

When implementing an enhanced version, preserve the semantics of the underlying <form>. Avoid replacing standard form behavior with clickable <div> elements or JavaScript-only handlers. Native controls provide keyboard behavior, validation, and accessibility features for free.

Keep secrets out of the browser

One caveat applies to every static-site form solution: anything included in the generated HTML or browser JavaScript is public.

Don't put private API keys, SMTP credentials, database credentials, or other secrets into an Astro client component. A hosted form endpoint is useful precisely because sensitive server-side processing can happen somewhere other than the static site.

Similarly, don't treat client-side validation as a security boundary. Validation in the browser improves UX, but incoming form submissions still need server-side validation and abuse protection.

When this pattern makes sense

A hosted endpoint works particularly well for relatively straightforward forms: contact pages, feedback forms, waitlists, lead forms, and event inquiries.

For workflows that need application-specific authorization, database transactions, complex business rules, or deeply customized processing, adding an Astro server route or a separate application backend may be the better architecture.

For the common "I have a static Astro site and need this form to go somewhere" case, however, outsourcing the endpoint keeps the deployment model pleasantly simple.

Start with plain HTML and zero client JavaScript. Add progressive enhancement only when it improves the experience. That lets an Astro site remain what it was designed to be: mostly static, fast, and uncomplicated—even when it needs a form.