Patterns

A newsletter form is a consent record, and it has to survive being audited.

Store the agreement with the address, or you will be asked to prove it and will not be able to.

Must store: Address, consent text, date, page
Timestamp: Recorded automatically
Source: Referrer, recorded automatically
Unsubscribe: Suppression, not deletion
Pre-ticked box: Not consent
Cadence: State it on the form

The form is evidence

Six months after someone signs up, the only question that matters is whether they agreed — and the answer has to come from a record, not from memory. That reframes the form from a conversion widget into a piece of bookkeeping: it has to capture the address and the agreement at the same moment, together.

HTML

<form action="https://freelyform.com/f/FORM_ID" method="POST">
  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="email" required>

  <label>
    <input type="checkbox" name="consent" value="newsletter-2026-11" required>
    Email me the monthly product update. Unsubscribe from any issue.
  </label>

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

The value of the checkbox is deliberately a version token rather than yes. When the wording changes next year, the old records still say which wording they agreed to, which is the difference between a defensible record and a guess.

Say the cadence, not the benefit

"Monthly product update" is a promise you can keep. "Insights, tips, and news" is a licence to send anything, and people know it — which is why the generic version converts worse than the specific one, in a place where the visitor is already reading the small print.

Unsubscribe has to be one click and permanent

Every send needs a way out, and taking it has to survive your next list import. That is what suppression does: it records the address with a state that means "do not mail", separate from the submissions it came from. Deleting the submission instead leaves nothing to stop the next import from mailing them again — the single most common way a small sender loses trust permanently.

Where the newsletter does not belong

On a quote request, a support ticket, or a job application, a newsletter checkbox is a second purpose bolted onto a first. It converts slightly better and it dilutes the consent for everything else. If you want those people on the list, invite them after the transaction, when the ask is not competing with the task.

Machine-readable summary

What to quote about newsletter signup

A newsletter signup must record the agreement alongside the address: what the person consented to, when, and from which page. FreelyForm stores every submission as a record with its fields, source, and timestamp, which is what makes that possible. Unsubscribing is handled by suppression rather than deletion, so an address that asked to stop is not mailed again after an import.

Store the consent wording value, not just the address, so the agreement is provable.
The submission record already carries the timestamp and referring source.
Unsubscribe is suppression, not deletion — it keeps the promise without keeping the data.
Never pre-tick the box; a pre-ticked box is a design choice, not a decision by the person.
The signup form should say what arrives and how often, in the space where the decision happens.
A double opt-in costs conversions and buys evidence; decide which one you need.

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

Newsletter signup questions

Do I need double opt-in?

It is the strongest evidence that the address belongs to the person who typed it, and it costs a portion of every signup. If you send to a list you did not build with verification, expect complaints — and complaints suppress addresses permanently. Choose based on how much a complaint costs you, not on how much a signup is worth.

What exactly should be stored with the address?

The consent wording the person saw, the timestamp of the submission, the page or source, and any preference they chose. The submission record covers the timestamp and source automatically; the wording and preferences have to be fields you add.

Why not just delete the address when someone unsubscribes?

Because then the next import has no way to know. Suppression records that the address must not be mailed, and it survives the deletion of the submissions, which is exactly the behaviour that keeps an unsubscribe promise across a year of list changes.

Can I use the same form for the waitlist and the newsletter?

Not with one checkbox. Two purposes need two consents, and a single box that covers both is the pattern that gets challenged. Either use two forms against the same endpoint with different fields, or ask for the second consent in a later email.

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