The browser's toolbox

Every browser comes with a large set of built-in tools that a page's own script can use, with no server and nothing to pay. Developers call them web APIs: ready-made functions a script can call.

A page can remember small things on this device, such as your chosen language or dark mode, in what's called local storage. It can fetch data from other services, such as a public weather or transport feed, straight from the visitor's browser. It can copy to the clipboard, like the button next to a promo code, and notice what comes into view, so pictures load or fade in as you scroll down a long article. It can draw charts, animate transitions, play sound and, once the visitor agrees, use the camera, as Doctolib does for a video consultation.

All of this works on a free static host such as GitHub Pages, where nothing runs on a server. What the browser remembers stays in that browser, on that device, so it won't follow a visitor from laptop to phone, which is fine for a preference. And a well-made animation respects the visitor's "reduce motion" setting.

Ask who the data is for, and the line becomes clear. Your flat-share wants a page for the shopping list. If each person keeps their own list, the browser can store it on their own phone, and no server is needed. If the four of you must see the same list, with each other's additions, it has to live in one place that every browser asks, which means a server. A browser only knows what happens on its own device.

Two more things need a server. Secrets, such as the key to a paid translation service, can't sit in the page, since anyone can read the page's code. And a rule that must hold whatever the visitor does, such as "one sign-up per person" or "twenty places at most", can't be enforced by the visitor's own browser, which the visitor controls.

That server doesn't have to be your own. A form service or a booking tool is a server someone else runs, often free for small uses.

A small theatre company has a few static pages on a free host, and a list of wishes for the new season: a countdown to the premiere, the dates and seats left from its ticketing service, a newsletter sign-up and a guestbook. Someone quotes a server and a database at €30 a month. Sort the wishes first.

The countdown runs in each visitor's browser. The dates and seats can be fetched straight from the ticketing service if it offers a public feed that needs no secret key. The page then depends on that service, so check its terms, its limits and what the page shows on the day it's down. The newsletter sign-ups have to be collected in one place, but the email service the company already uses has a ready-made form for that. Only the guestbook needs somewhere to keep everyone's messages, and a ready-made comments service might do. The honest answer may be no server at all, or one small outside service, and the site stays on free hosting.

A volunteer builds a quiz for your association's welcome week with an AI agent: one page, with the questions kept in a separate data file. It worked in the agent's preview. You double-click the page: the title and the buttons appear, and the questions never do. The address bar starts with file://, which means the browser read the file straight from your disk, with no web server.

The title and buttons are written in the page itself. The questions are in the other file, which the page's script asks for once it has loaded, and browsers refuse that kind of request from a page opened from the disk. It's a security rule: otherwise any page you downloaded and opened could read the other files on your computer and send them away. The agent had started a small local web server, at an address beginning with http://localhost, so the request was allowed there.

Nothing is broken: the page only needs to be served by a web server, any web server, with no back end at all. Drop the folder on a free static host such as Netlify Drop or GitHub Pages, and you get a link that works on any device.

Ask these before paying for a server, and whenever someone sends you a prototype.

When a feature comes with a server and a monthly fee, ask which part needs one: what's shared between visitors, what's secret, which rule has to be enforced. If the answer is none of them, the browser can probably do it on the static site you already have. If one part does need a server, ask whether a ready-made service would do, what it costs as you grow, and what happens if it changes its terms or closes.

When something works on its builder's computer and not on yours, ask how they open it: through a local server, or straight from the disk. Ask for prototypes as links on a static host from now on, so everyone sees the same version on any device, phones included. Before anything goes on a free host, check what's in its data files, since those hosts are public and real customer or project data doesn't belong there. And remember that a list loaded by a script stays empty online too, whenever that request fails.