Birta vs HTML Pub: What Happens After You Publish

The short answer

HTML Pub and Birta both promise a fast route from an AI conversation to a live page, but they start from different places. HTML Pub has its own AI built in: you describe a page and its generator produces it, spending AI credits along the way. Birta doesn't generate anything. It publishes what an agent you're already using, in whatever chat or coding tool you already work in, has built.

If you want the AI generation and the hosting to be the same product, HTML Pub is a real answer. If you already have an agent producing the site and just need it published, versioned, and given a working lead form, that's Birta's job.

On the one thing this page keeps coming back to, HTML Pub has already answered for itself. The guidance it publishes for AI assistants lists the jobs it is the wrong tool for, and version-controlling pages is on that list, with anyone who needs it pointed at GitHub Pages, Netlify or Vercel. No argument this page could make about version history would be stronger than the vendor's own sentence.

So the split isn't who runs a connector, and it isn't who writes the HTML. It is what one connection reaches once the page exists: a draft, a version with its own address, a way back to an earlier publish, and the remarks somebody left on the page.

Where Birta's job starts

Birta has no import button, no file picker, and no field where you paste a link to pull a page in. It doesn't read a folder off your disk, it doesn't turn a Word file or a Markdown draft into HTML, and none of that is on the way.

That reads like a shortfall until you look at what is already sitting in front of it. The agent you talk to does the whole input side. Claude Code, Cursor and Codex read your project folder; Claude Desktop, Claude Cowork and ChatGPT fetch a document or a public page from a link and hand back HTML. Birta starts one step later, at the part none of them can do on their own: a real address, a record of what was published, a way back to it, a declared lead form, a domain, a visitor count.

HTML Pub covers that same input side from the other direction, and it covers it well. Its own AI writes the page inside the product, spending AI credits, and it also runs a connector so an outside assistant can publish into it. The connector documentation puts the endpoint at mcp.htmlpub.com/mcp and signs in over OAuth rather than an API key. It is on every plan including the free one, although the free plan still won't put a page live.

It is a bigger connector than its own docs page makes it look. That page walks through nine tools for pages, sites and assets, then says in passing that there are 37. HTML Pub's machine-readable reference puts the server at 48 and describes 36, adding organizations, a URL analyser, four more asset tools, and a whole blog surface of posts, templates, landing pages and images. Read on 7 September 2026, the vendor gives three different counts, so treat the number as approximate. The shape is not in doubt.

Every one of those tools acts on something already sitting in HTML Pub's dashboard, because that is the dashboard the connector was wrapped around. There is a draft in there now. An edit made with edit_page or update_page is held back unless its publish flag is set, and a separate publish_page promotes the pending draft to the live URL.

What there isn't is a record. That is the redirect from the top of this page seen in context: the vendor's own guidance sends anyone who needs version control to GitHub Pages, Netlify or Vercel, and its FAQ shuts the same door from the other side, warning that deleting a page "is immediate and cannot be undone, so make sure you have a backup if needed".

So nothing lists what was published before, nothing gets yesterday's HTML back, and the draft, real as it now is, has no address of its own to send to anybody. Checked on 7 September 2026 across the connector documentation, the REST API reference, the plan comparison, the FAQ and both of HTML Pub's AI-context files: no version list, no restore, no rollback. The backup is your own copy.

Birta is built the other way round. Its connection was never wrapped around an existing dashboard, it is the way the product is used, so one connection reaches the whole thing: open a draft from a stored version, write files into it, publish it, list earlier versions, roll one back, read the remarks somebody left on a version.

Send a version out for review

Before a page is public, somebody usually has to look at it and say what is wrong. That round trip is where the two products stop resembling each other.

On Birta a version has its own address. The agent is handed it when it opens a draft and again when it publishes, and the address keeps working after the site goes live. You send that link to whoever signs the work off.

They don't need an account. Version access defaults to a plain link, so a guest who opens the address passes a signed handoff in the background and gets a nickname to sign remarks with. Closing a thread stays with a project member, and that is enforced on the server rather than hidden in the interface.

Then they mark up the page in the browser. Click the heading, the button or the price that's wrong, type the remark, and it lands pinned to that element. Each thread comes back with its number, the page and element it sits on, whether it is still open, and every message with an author and a time. Numbers are not recycled, so "fix number three" still points at the same pin next week.

Your agent reads the threads with list_version_comments, changes the same draft, and publishes a new version. It cannot post a reply into a thread or mark one resolved, and an attempt to write is refused. Birta's own instruction to the agent says the owner "may mark remarks on the page", and that it should then read them, "make the changes in this same draft, and tell them to refresh the same page".

Everyone with project access also gets one email digest of new remarks, roughly 15 minutes after the first one lands, with their own remarks left out of it. No plan gates any of this, so it works on the free tier. The versions and remarks guide walks the loop end to end.

Two limits, so this isn't oversold. The address belongs to the version rather than to the live site, and link access is a default a project can be moved off.

Now HTML Pub, checked on 7 September 2026 across its FAQ, its forms page, its pricing page, its connector documentation and both AI-context files. There is nothing for commenting on, annotating or reviewing a page. A draft does exist, since an edit can be held back until publish_page promotes it, but it has no address of its own and nothing pins a remark to it.

The nearest equivalent is real and shaped differently. You can build a feedback or survey form and HTML Pub collects the submissions, so a reviewer types their notes into a form. That arrives as a row in a dashboard instead of a pin on the element it is about, with nothing tying it to the version of the page that was open when it was written.

Compare the work after the first publish

Three rows are worth pulling out of the table instead of letting them blend in. HTML Pub POSTs a form submission to any endpoint you name, on every paid plan, and Pro and Business add five live connections to Slack, Zapier and a long list of email platforms including Mailchimp, Kit, Klaviyo and ActiveCampaign. Read on 7 September 2026, HubSpot and Pipedrive are not among them: HTML Pub's own reference puts CRM integrations on the Leadpages plans rather than its own. Birta does none of it. Leads reach the project panel and one email digest, nothing else, and no webhook is announced, so read it as a standing gap rather than a queue.

Payments are the second. HTML Pub connects Stripe or Shopify and puts a checkout on a published page. Birta cannot take a payment from your site's visitors today, and that is a planned module rather than a boundary, but planned is not shipped and this row belongs to them.

The row going the other way is the free tier. HTML Pub's own FAQ calls the free plan "a build-and-preview sandbox: you can design and preview pages as drafts, but publishing them live requires a paid plan". Birta's free tier publishes live. Neither product should get credit it hasn't earned.

Stay on HTML Pub when...

Stay when you want the AI generation itself, not just the hosting after it. HTML Pub's whole pitch is doing both in one product, and if that's the workflow you want, it delivers it.

Stay when a webhook matters right now. If a lead needs to land in Zapier, Slack or Mailchimp the moment it arrives, HTML Pub already does that on a paid plan. Birta's lead delivery is a project panel and one email digest, nothing more.

Stay when the page has to take money. HTML Pub puts a Stripe or Shopify checkout on a published page. Birta has no way to charge your visitors yet.

And stay if you're testing the idea and don't mind a preview-only free tier. Publishing live requires a paid plan starting at $10 a month.

Birta fits better when...

Birta fits once you already have an agent building the site, whether that's a chat assistant or a coding tool, and the job left is publishing it, keeping a real version history, and handling what happens when someone fills out a form.

Choose it when a bad update needs to be reversible. Every successful publish becomes a version, the last 10 stay available, and any of them can go live again with the original files intact. Each version also downloads as one archive, useful for a backup or a clean copy.

Choose it when somebody other than you has to approve the page first. You send the version's address, they open it without signing up, they mark the wrong heading where it is wrong, and your agent reads the list and fixes it in the same draft. On HTML Pub that conversation happens in chat or in a feedback form, away from the page it is about.

Choose it when a real form belongs on the site and you want it live even before you're ready to pay for anything. Birta's free tier publishes the site and the form, capped at 10 leads a month per project, which is different from a tier that won't publish at all until you subscribe.

The honest tradeoffs are the two rows above, the webhook and the checkout. If routing a lead automatically into another tool or charging a visitor is the actual requirement today, those are real reasons to choose HTML Pub instead. Weigh them against the rest of this list, though. Everything else here happens after the page is live, and that stretch is what a single Birta connection covers.

Moving from HTML Pub

This is a short migration, because the two products don't diverge much at the file level once a page exists.

1. Step 1Recover the published HTMLSave the live page's HTML, CSS, JavaScript, and assets from the current HTML Pub project.
2. Step 2Rebuild anything webhook-dependentIf a form pushes submissions to a webhook, Zapier or Slack, have your agent recreate that logic separately, since Birta's form delivery is the project panel and an email digest, not a webhook. Do the same for a Stripe or Shopify checkout, which Birta has no equivalent for.
3. Step 3Publish and verifyPublish through Birta, check every page and the form submission, then move an owned domain's DNS once the new site passes review.

If the webhook integration is doing real work in your process, replace it before you rely on the new site for anything time-sensitive.

The decision

HTML Pub is the right call when you want its own AI to generate the page and you need a webhook-connected form or a checkout immediately.

Birta is the better fit when an agent you already use builds the site and you want it published with real version history and a working lead form, including on the free tier.

That last row is the one nobody in this category has closed. An agent connection is normal now, several products will let somebody comment on a page, and among the hosts Birta gets compared with, not one of those connections reaches a version list and a rollback. HTML Pub is unusual only in saying so out loud and telling you where to go instead. It is the row one Birta connection was built to carry.

Frequently asked questions