PDF to Website: Turn the Document Into a Page People Can Read

Convert the content, not the layout

A PDF is a fixed-layout format: every line sits at a coordinate, which is why it looks identical everywhere and why it does not reflow on a phone. A web page is the opposite, with text flowing into whatever width it is given.

Converters translate between the two by keeping the positions, which produces the familiar result: technically HTML, unreadable at 390 pixels wide, headings that are not headings, a table that is a picture of a table.

An agent does something different. It reads the document, then writes a page that says the same things in HTML a browser understands. Six steps, and you keep the PDF.

Step 1: Decide what the page is for

Not the whole document. One page, one job. A pitch deck becomes a page that gets a reply; a price list becomes a page someone can scan and act on; a report becomes a page that states its finding first.

Write one sentence: "This page exists so that [who] can [do what]." Everything in the next step is judged against it.

Step 2: Hand the agent the document and the sentence

For an agent that can read files (Claude Code, Claude Cowork, Cursor, Codex):

Read [path/to/document.pdf].

This page exists so that [who] can [do what].

Rebuild it as a single static bundle: index.html plus one style.css, no build
step, no framework, no client-side router. Real content from the PDF, no
placeholder text.

Rules:
- Use real headings, lists and tables, not images of them.
- Keep the reading order the document intends, not the visual order of the page.
- Drop anything that only made sense on paper: page numbers, "see page 4",
  headers and footers, the cover page.
- Tell me what you dropped and what you could not read.

The last line is the one people leave out. Charts, scanned pages and anything drawn as vector art will not survive as text, and you want that list before you go looking for it yourself.

Step 3: Read what it dropped

Two things need your judgement:

• Charts and diagrams. The agent can describe them in text or you can export them as images from the PDF and drop them in. A chart as a caption plus a number is often better than a screenshot nobody can read on a phone.
• The cover and the closing slide. They usually contain the one sentence from step 1 and nothing else worth keeping.

Step 4: Check it at phone width before anything else

Open the draft and narrow the window to about 390 pixels. This is where a converted PDF fails and a rebuilt page holds:

• No horizontal scrolling.
• Tables either fit or scroll on their own, without pushing the page sideways.
• Text is the browser's size, not a fixed pixel size scaled down from A4.
• Every link is tappable, and email addresses are real mailto: links.

Step 5: Publish it

Connect Birta to the agent once:

claude mcp add --transport http birta https://birta.dev/mcp

The endpoint is https://birta.dev/mcp, and the setup is in the Claude Code guide. Then:

Create a Birta project, write the files into a draft, publish it, and give me
both addresses: the live site and the version address I can send for remarks.

You get the live page and a version address. The second one is what you send to whoever has to approve the wording.

Step 6: Collect remarks without sending a new file

Send the version address. Whoever opens it marks remarks straight onto the page, pinned to the element they mean, and they need no account to do it. Then:

Read the remarks with list_version_comments, make each change in this same
draft, and publish a new version. Tell me which thread numbers you addressed.

Your agent reads and edits. It cannot reply in a thread or mark one resolved, so closing them stays with you, in the browser.

Keep the PDF where the PDF belongs

Some documents should stay documents, and putting them on the web as a page is the wrong move:

A good pattern for those: a short page stating what the document is and who it is for, with the PDF linked from it. The page is findable and readable on a phone; the file stays exactly as it is.

The limits of this path

Static output only: no server, no database, no authentication. Taking payments on your own site is not something Birta does yet, and lead form submissions arrive in the project panel plus an email digest, not in Slack or a webhook.

On the free tier the page gets a Birta subdomain and keeps the "made in Birta" badge; a custom domain needs Solo or Pro. A PDF's images count against the project's 25 MB, so a scan-heavy document is worth compressing before it goes in.

Frequently asked questions