A static page has no backend and no secrets, which sounds like it rules out forms, payments and bookings. It doesn't. The line isn't 'frontend versus backend' — it's whether the credential you'd have to publish is designed to be published. How to tell, in one question, before you build.
Someone with a paid account told us last week that he had assumed a static page could not collect form submissions. He was building exactly the kind of thing that should — a one-page site for a client — and had written off half of what he wanted because the page had no backend behind it.
He was wrong, and he was wrong for a good reason. "No backend" sounds like it should rule out anything that involves other people's data. It rules out much less than that, and the line is in a different place than the intuition puts it.
The intuition goes: my page is just files, files cannot do anything, therefore anything involving a database or a payment or another person's inbox is out of reach.
Every step of that is true except the last one. Your page cannot do those things. It does not have to — it can ask something else to do them, and an enormous amount of infrastructure has been built specifically to be the thing it asks. Those services expect to be called from a browser they do not control, belonging to a person they have never met. That is not a workaround they tolerate; it is the product.
Once you see it that way the question stops being about your page's capabilities and becomes a question about the credential.
Anything your page does involves handing over some identifier that says which account the request belongs to. The entire question is whether that identifier is safe for the world to read, because on a static page the world will read it.
Services that have thought about this split their credentials into two kinds and make the difference visible. Stripe is the clearest example to point at because their documentation says it outright — "Only publishable keys are safe to expose outside your application's backend." The publishable key is a real credential that identifies your account, and it can only perform the narrow set of operations that are safe for an anonymous stranger to perform. The secret key is a different object entirely, with a different prefix, and it must never leave a server.
That split is the whole answer. A publishable credential in a public page is not a leak — it is the design. A secret credential in a public page is a serious incident, and the reason it happens is almost never recklessness. It is someone following a tutorial written for a server and not noticing which key it used.
So the test is not "am I allowed to put a key in this page". It is "which of the two kinds am I holding, and does the vendor say so".
Running down the categories, with the mechanism rather than a list of brands — the brands change, the mechanism does not:
Collecting things from visitors. A form does not need your server, it needs a destination. Form-endpoint services give you a URL to point the form's action at and collect submissions on their side. Nothing about that is secret, because the endpoint's entire job is receiving posts from browsers belonging to people the service has never met. Embedded form builders solve the same problem with an iframe: the form is somebody else's application, rendered inside your page.
Taking money. Two shapes, and it is worth knowing which you want before you start. A hosted payment link is a URL you generate in a dashboard — Stripe describes this as accepting payments online without writing code — and your page simply links to it, so the whole transaction happens somewhere else. An embedded checkout runs inside your page using the publishable key. The link is close to zero effort and takes the visitor away from your page; the embed keeps them on it and asks more of you.
Letting someone book time. Scheduling tools are almost all embed-first, because the common case has always been putting a booking widget on a site the tool does not control. The widget is an iframe pointing at their calendar application.
Measuring, discussing, showing. Analytics, comment systems, maps, fonts, and libraries from a CDN are all the same shape: a script or an iframe, with a public site identifier at most. These have worked on static pages since long before anyone called them static pages.
The pattern across all of it: if a service was built to be embedded in websites its authors do not control, it works. That covers a lot more ground than "no backend" suggests.
This is the shorter list, and it is worth stating plainly rather than hedging, because it is where the real limit is.
You cannot keep a secret. Whatever is in the file is readable by everyone who receives it, including things you would rather they did not see — API credentials, a hidden price, an email address you did not want scraped, a comment you left in the markup. This is also true of pages you think of as private: an unguessable link is a key, not a wall, and anyone holding it can read the source.
You cannot enforce a rule. Validation in the page is a courtesy to honest users, not a constraint on dishonest ones. If a visitor can change your page — and they can — then any check that lives only there is advisory.
You cannot own state that must be consistent. Real accounts, sessions, inventory that must not oversell, anything where two people acting at once must not produce a contradiction.
You cannot receive a webhook, or run something on a schedule. Both require a thing that is listening when nobody has the page open.
When you need any of those, you need somewhere that runs code, and the honest recommendation is to go and get one rather than build an elaborate workaround. Vercel and Netlify both take a repository and give you server-side routes, environment variables and a place for secrets to live. That is a genuinely different tool from a page host, including this one, and picking it early is much cheaper than discovering the need halfway through.
Before adding anything to a page that has no backend:
What does this service hand me first — something meant to be read by anyone, or something meant to be hidden?
An embed snippet, an iframe, a form action URL, or a key the vendor calls publishable, public or client-side: it is designed for this, use it. A secret key, a request you have to sign, or a webhook you have to receive: it wants a server, and no arrangement of your page will change that.
The vendor has already answered this in their own documentation. The failure mode is not getting it wrong after checking — it is not checking, and assuming from the phrase "no backend" that the answer must be no.
Worth reading next if you are building this way: what to do with a page a coding agent just generated, and why the output tends to vanish before you have moved it anywhere.
A static page can post form submissions into a Sheet you already own, using a Google Apps Script web app as the endpoint. The fourth shape most 'form without a backend' guides leave out — how it works, the two settings that trip everyone up, and when a form service is still the better call.
The iframe snippet works on your laptop because the PDF is sitting next to the HTML. The moment the page travels, it's two files — and only one of them arrives. What actually survives the trip.
A Claude artifact looks self-contained inside the chat and often isn't. The five things that quietly stay external — CDN scripts, Tailwind, fonts, images, fetch calls — and how to inline each.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.