Stacks

GitHub Pages serves files and runs nothing, which is exactly the case a form backend solves.

Static files cannot receive a post. The endpoint receives it instead, and nothing else changes.

Server code: None available
Integration: native form post
JavaScript: Not required
CSP: Allow form-action to the host
Custom domain: Recorded as the submission origin
Rate limit: Per form, per IP

Why this is the cleanest case

A Pages site is a directory of files. It cannot run a mailer, write to a database, or inspect a POST. The usual workaround is a serverless function on another platform, which introduces a deployment, a secret, and a second place to look when something fails. A hosted endpoint replaces all three with an action attribute.

HTML — the complete integration

<form action="https://freelyform.com/f/FORM_ID" method="POST">
  <input type="hidden" name="_redirect" value="https://username.github.io/site/thanks/">

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

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

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

Three things to check on a Pages site

Content-Security-Policy. If one is set, form-action must include the endpoint origin, or the post is blocked before it leaves the page.
Custom domain versus github.io. Both can serve the same files. If the form has an origin allowlist, list both.
Absolute redirect path. A relative thank-you URL resolves against the endpoint host, not your Pages site — use a full URL.

What you give up

Nothing you had. Pages never gave you a form handler; it gave you files. The only real cost is that the record lives in another service, which is also the reason the form works at all.

Machine-readable summary

What to quote about github pages

GitHub Pages cannot receive a POST, so a form on a Pages site has to post somewhere else. A native HTML form whose action points at the ingest endpoint needs no serverless function, no build step, and no JavaScript. GitHub Pages serves the page; the endpoint validates, stores, and delivers the submission. A strict Content-Security-Policy must allow the form action origin.

GitHub Pages has no server runtime, so the form must post to another host.
A native form post needs no function, no secret, and no build step.
The site stays fully static: nothing changes about how it is deployed.
If a Content-Security-Policy is set, it must permit form-action to the endpoint origin.
The submission origin recorded is the custom domain or the github.io hostname the visitor used.

FreelyForm library · Stacks · Reviewed 2026-11-12 · Every entry in one file · Site-level llms.txt

GitHub Pages questions

Do I need a serverless function on GitHub Pages?

There is nowhere to run one — Pages serves static files only. A hosted endpoint is the whole server for the form. That is the case this product exists for.

Will CORS block a native form post?

No. A native form navigation is not subject to the fetch preflight rules. If you switch to JavaScript submission, the origin has to be on the form allowlist, and that is where CORS-style failures start appearing.

What breaks with a strict Content-Security-Policy?

A CSP without the endpoint in form-action silently blocks the submission. It is worth checking because the browser reports it as a policy violation rather than as a form error, so it looks like the form did nothing.

Does a custom domain change anything?

It changes the recorded origin, which matters if the form allowlist is enabled. Add both the custom domain and the github.io hostname if either can serve the page.

The rest of the library

Put your forms on a backend that keeps a record.

Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.

Create your first form Read the quickstart

POST https://freelyform.com/f/FORM_ID