markdown.style

HomeClaude Markdown to PDF or HTML

From an AI assistant

Turn a Claude answer into a styled checklist or document

Claude often answers a request like an onboarding plan with headings, task lists, a table and a code block already in place. Style that Markdown and export it to PDF or HTML instead of asking for a finished file.

Open this example in the editorStart with your own

Copy the Markdown, not a screenshot

  1. Ask Claude for the checklist, plan or document you need. It answers in Markdown.
  2. Copy the answer and paste it into the source pane at /editor.
  3. If the pasted text opens with a line describing the document rather than being part of it, delete just that line.

Everything from the first heading down is the document: keep the headings, the task lists, the table and the code fence exactly as Claude wrote them.

Headings become the page's structure

A long answer like a three-week plan stays readable because each ## becomes a styled section heading, not another paragraph in a wall of text. The # at the top becomes the document title. A plan with three weeks or six sections renders the same way, each one scannable on its own.

Task lists render as checkboxes

A line written as - [ ] becomes an unchecked box in the preview, and - [x] becomes a checked one. Every week's list in the example below keeps its own checkboxes, so a fifteen-item plan reads as fifteen separate steps instead of fifteen bullets that look the same.

Code blocks keep their highlighting

The setup commands below are fenced with bash, so the editor highlights them the way a terminal or a code host would. The same fence works for a Python script or a SQL migration. Tag the fence with its language and it highlights on its own, in the same document as the rest of the checklist.

Worked example

A three-week onboarding checklist of the kind Claude writes for 'draft an onboarding checklist for a new backend engineer', with the lead-in sentence already trimmed.

# Backend engineer onboarding checklist

A three-week plan for a new backend engineer joining the payments team. Check items off as you complete them, and ask your manager if a step does not apply.

## Week 1: access and environment

- [ ] Get GitHub, AWS and PagerDuty accounts provisioned (see the table below)
- [ ] Clone the `payments-api` and `payments-worker` repositories
- [ ] Run the local setup script and confirm the test suite passes
- [ ] Read the on-call runbook and shadow one incident review
- [ ] Meet your manager to agree on 30, 60 and 90 day goals

## Week 2: first changes

- [ ] Fix one issue labelled `good-first-issue` in `payments-api`
- [ ] Open a pull request and get it reviewed by two teammates
- [ ] Deploy the change to staging and check it in the staging dashboard
- [ ] Attend the weekly architecture review as an observer
- [ ] Pair with a teammate on a production deploy

## Week 3: ownership

- [ ] Take ownership of one small service or module
- [ ] Write or update its README with setup and deploy steps
- [ ] Join the on-call rotation as a shadow for one week
- [ ] Present a five-minute summary of what you have learned so far
- [ ] Set 90-day goals with your manager for the quarter ahead

## Accounts to request

| System | Requested by | Access level |
| --- | --- | --- |
| GitHub | Manager | Write on payments-api, payments-worker |
| AWS | Team lead | Read-only, payments account |
| PagerDuty | On-call lead | Responder, payments schedule |
| Datadog | Manager | Standard |
| Vault | Security team | Read, payments secrets path |

## Local setup

Run these commands after cloning both repositories.

```bash
git clone git@github.com:brightlane-labs/payments-api.git
git clone git@github.com:brightlane-labs/payments-worker.git
cd payments-api
cp .env.example .env
docker compose up -d postgres redis
bun install
bun run db:migrate
bun test
```

If the test suite passes, the environment is ready for the first pull request in Week 2.

Rendered in the Slate theme. Open it in the editor to change the theme or the text.

Slate for an internal document

Slate uses cool greys and a tighter 16px base than the serif themes, suited to a document with many tables and lists like this one. For a checklist that leans more heavily on the code fence, Repo gives it the look of a README on a code host. It sets code in JetBrains Mono and draws rules under the top two heading levels. Mono sets everything, including the table, in monospace on a wider column that keeps long command lines whole.

Exporting the checklist

Open the export menu on the preview header. "Print or save as PDF" opens the browser's print dialog, and picking "Save as PDF" there turns the checklist into a file ready to send or attach. "Download .html" packages it as one standalone file, styling and fonts bundled in, so a new hire can open it without the editor.

One prompt, as many exports as you need

Asking Claude to produce a finished PDF or HTML page directly spends output tokens on the markup itself. It spends them again for every change: a fourth week added, a different theme, a wider table. Ask for the checklist in Markdown once, then style and export it here as many times as the plan changes.

Questions

Do the checkboxes I tick in the source show as checked in the PDF?

Yes. Change - [ ] to - [x] in the source pane and the box renders checked in the preview and in every export, including print and Download .html.

Can the new hire click the checkboxes once the checklist is exported?

No. The checkboxes render as disabled controls in the preview and in every export, so they show checked or unchecked state but are not clickable. Track progress by editing the source and re-exporting.

Does a Markdown table keep its columns when I print it?

Yes. A GitHub-flavoured Markdown table renders as an HTML table with a header row, and printing, Download .html and Copy styled HTML all carry the same columns and rows.

Does every code fence in a document need the same language tag?

No. Each fenced block highlights on its own language tag. Tag a Python migration script python or a config file yaml and it highlights independently in the same document.