HTML export: your page as one self-contained file
Anticode can hand you any page it builds as one HTML document with its CSS written inline: no build step, no framework and no scripts. A site of several pages comes as a zip of folders instead. The file is the design and the content; the parts that need a server, such as form handling, stay with Anticode or move to the Next.js export.
Where the download lives
To export website as single HTML file, open the Code tab. It's part of Pro mode (the interface mode, not the plan; see Simple and Pro modes). The bar above the code shows the file name, its line count, its size in kilobytes and, for a page, 0 scripts. Two buttons sit beside it: Copy puts the page's HTML on your clipboard, and HTML downloads it.
- A one-page site downloads as a single file named after the project, for example
harbour-bakery.html. - A site with separate pages (Work, About, Pricing, Contact and so on) downloads as
<name>-site.zip: anindex.htmlat the root and one folder per page, each holding its ownindex.html. The links between pages are relative, so the folder works from any web host without rewriting. - An app build downloads as the one HTML document the model wrote, with its JavaScript inside it.
What's inside the file
A design-engine page is a complete document you could open from your desktop. Reading it top to bottom, you'll find:
- A doctype and
<html lang="en">, a viewport tag for phones, a title and a meta description. - A Content-Security-Policy in a meta tag with
script-src 'none', so even the copy on your own host refuses to run scripts, plus a referrer policy. - One link to Google Fonts for the design system's typeface. That's the only stylesheet loaded from elsewhere.
- Every rule of the design system in a single
<style>block: colour tokens on:root, type scale, spacing, the layout of each section. - The markup of the header, each section and the footer. Photos from Anticode's curated library load from images.unsplash.com and carry their alt text.
That's why the file is self-contained in the useful sense: there's nothing to install or compile, and any server that hands out static files can serve it. It also means the file is plain enough to read and edit by hand.
What doesn't come with it
A published Anticode site is more than its HTML. Several things are worked out by Anticode's servers each time someone visits, and a downloaded file can't carry them:
| Part of the site | Published on Anticode | Downloaded HTML |
|---|---|---|
| Contact, booking and newsletter forms | Posted to /api/contact, /api/bookings and /api/subscribe, validated, stored sealed and passed to your connectors | The forms still point at those paths. On another host there's nothing there to receive them |
| Booking calendar days | Rewritten as the page is served, so visitors always see the coming days | Frozen at the days it had when you downloaded it |
| robots.txt, sitemap.xml, llms.txt, Privacy and Terms | Generated per site from what's published | Not included |
| CMS collection pages and the security report | Served from the database on request | Not included |
| Visit counts | Counted without cookies in your dashboard | Whatever your new host offers |
The page's own policy also limits forms to its own origin, so if you host the file elsewhere and want working forms you'll need to build handlers at those paths on that host, or swap the forms for links (a mailto: address, or a booking page elsewhere).
Where you can host it
Anywhere that serves static files: object storage with a public bucket, a static hosting service, the web space that came with a domain, or a folder on your own server. Upload the file (or the unzipped folder) and point your domain at it. For a broader look at when a plain file is the right shape for a site, see static websites, and for the step-by-step, the guide to downloading a website as HTML.
When to pick a different export
If the site needs to keep taking bookings, messages or sign-ups away from Anticode, the Next.js export is the better fit: it's a standard project with server routes for bookings, contact, newsletter and email sign-in, a Postgres database through Prisma and an admin area. If you only want to edit a project on your own machine and keep publishing through Anticode, the CLI is closer to what you need.
Limits of the HTML export
- It's a snapshot. Edits you make later in the builder don't reach a file you've already downloaded. Download again after a change.
- Hand edits don't come back. Changing the downloaded file doesn't change your project. To keep one source of truth, edit in the builder and re-export.
- No server features. Forms, the CMS, site functions, analytics and the per-site files listed above need Anticode or another server.
- Interface mode. The download button lives in the Code tab, so switch to Pro mode to see it.
Questions people ask
Does the exported HTML contain any JavaScript?
Not for design-engine pages. They ship with no scripts at all and a policy that refuses them. An app build is different: it is a program, so its file includes the JavaScript the model wrote.
Will my contact form work after I move the file?
Not by itself. The form posts to a path on Anticode's servers. On a new host you'd need your own handler at that path, or the Next.js export, which includes the server routes.
Can I export a site with several pages?
Yes. It downloads as a zip with one folder per page and relative links between them, ready to upload as it is.
Can I edit the downloaded file and load it back into Anticode?
No. The download is a copy. To change the project itself, use the builder, or the code editor in Pro mode, which keeps changes to text, section order and colour tokens.