Getting started with Prompt to Page.

Download the installer for your platform from the Download page — .dmg on macOS (Apple Silicon) or .msi on Windows 10/11 (64-bit).

On macOS: drag Prompt to Page to Applications and open it. Since 0.2.5, builds are signed with an Apple Developer ID and notarized by Apple, so the app opens with no warnings and no Terminal step.

Upgrading from 0.2.4 or earlier? Those builds needed a one-time xattr command to clear the download quarantine. That step is gone — replace the app in Applications with the new download, or accept the in-app update.

On Windows: run the .msi. If SmartScreen shows “Windows protected your PC”, click More info → Run anyway and follow the installer. Launch Prompt to Page from the Start menu.

Prompt to Page needs a local language model. On first launch you'll be offered three routes:

• Built-in. One-click. Downloads an open-weight model the first time, then generates offline.
• Ollama. Point Prompt to Page at your local Ollama instance and pick any model you've pulled.
• LM Studio. Connect to a running LM Studio server on your machine.

After the one-time download, generation, preview and checks all happen on your machine — you can work on a plane. When you are online the app also checks for updates and sends two usage events unless you turn those off; the privacy notice lists everything that connects.

Keep prompts plain. Verbs lead. Real services beat made-up ones. Examples:

• Start page for applying for a Blue Badge
• Report a pothole — pick a location step
• Check your State Pension age — answer page
• Register a birth — choose a registrar step
• Request a copy of a Carer's Allowance decision letter

You'll see live progress as the model writes — a percentage and tokens-per-second. Once it's done, the finished page renders in the GOV.UK style inside the preview panel. Generation never streams partial markup into the preview; you get a clean, finished page.

The marketing site you're reading uses our Inter + zinc design language. The GOV.UK preview inside the app — and inside the hero demo on the home page — uses GOV.UK styling. These two visual worlds never blend.

Six patterns to start from:

• Apply — straightforward application service.
• Apply with an eligibility check — pre-screen before the form.
• Report — report an issue or incident.
• Check — look something up.
• Register — register a person, vehicle, or event.
• Request — request a copy, replacement, or change.

Every generated page is checked with axe-core, using its WCAG 2.2 AA rule set, against the rendered page. Findings are listed by severity, with separate items that need manual review (axe is explicit about what it cannot automate). Fix issues, regenerate, or hand-edit — the check re-runs.

What a clean result means. “0 critical” means axe found no automatically detectable critical issues. It is not a statement of WCAG conformance, and it isn't one the app could make: automated tools reach a minority of the success criteria, and the rest need keyboard testing, screen-reader testing, zoom and reflow checks, content judgement and — before a service goes live — testing with disabled people and an accessibility audit. Treat the check as a floor that catches mechanical failures early, not as a sign-off.

• Download ZIP — a self-contained, testable prototype with local font-stripped frontend assets you can open or hand off. Kit and Nunjucks hand-offs use the receiving project's dependencies; restricted fonts and protected marks are not bundled.
• Copy HTML — paste into any editor.
• Copy as Nunjucks — drop into a GOV.UK Prototype Kit project, which supplies its own frontend dependency.

Kit and Nunjucks hand-offs use the receiving project's dependencies. Restricted fonts and protected marks are not bundled in any export.

You can also share for testing: Prompt to Page serves the prototype on your local network and shows a QR code so a teammate on the same Wi-Fi can open it on their phone. Nothing is uploaded.

Prompt to Page produces prototypes, not production code. The output is real design-system markup and it is meant to be edited, tested and thrown away — it has none of the security, performance or content assurance a live service needs.

• It doesn't make a page accessible. The automated checks find mechanical defects. Manual testing, assistive-technology testing and research with disabled people are still yours to do — see accessibility checks.
• It doesn't do content design. Generated wording is a placeholder for a content designer's judgement, not a replacement for it.
• It doesn't check that the component is the right one. Validation catches classes and structures the design system doesn't have. Whether a radio should have been a checkbox, or a journey should branch where it does, is a design decision.
• It doesn't review clinical or policy safety. NHS.UK output in particular still needs the clinical-safety and content review the NHS service manual asks for. Keep early prototyping to non-clinical patterns — contact preferences, appointment admin, general information — rather than triage, symptoms or anything advising urgent care.
• It isn't a source of real data. Use synthetic content. See the privacy notice for what not to paste in.

Prompts, generated pages, and exports stay on your machine. The outbound traffic the app can make is the one-time model download, update checks (on by default, switchable in Settings → Updates) and two beta usage events (on by default, switchable in Settings → Privacy). See the privacy notice for full details.

A short list of the most common questions lives here; for the full set see the FAQ page.