Home/Markdown to PDF, styled, in your browser
Convert
Turn Markdown into a styled PDF
The conversion is your browser's own print dialog. The styling is whichever theme you pick, and the print dialog turns that styled page into a PDF.
Three steps
There is no conversion step separate from styling: the theme is the design, and printing is what turns it into a PDF.
- Paste your Markdown into the editor. The preview updates as you type.
- Choose a theme from the theme menu. Each theme restyles the same document differently, and only that theme's fonts load.
- Open the export menu on the preview header and choose "Print or save as PDF". Your browser's print dialog opens; pick "Save as PDF" as the destination and save the file.
What the print dialog controls
Once the print dialog is open, the browser controls the paper, not the site. Most browsers let you choose the paper size and the margins, and let you turn off the page header and footer. Turning that off stops the URL, date and page number your browser would otherwise print on each sheet. None of that changes what the document itself contains, only how the paper looks around it.
There is usually a background-graphics option too, and it needs to stay on. Otherwise the print keeps only the text and drops the theme's page colour, table shading and code block backgrounds, leaving plain white behind everything.
Tables and code keep their styling
The table and the Python code fence in the worked example below are not a separate rendering for print. They are the same HTML and CSS the preview already shows. The table's row lines, the code block's background and its syntax colours print exactly as they appear on screen, as long as background graphics stays on.
Worked example
A short migration report: a table, a Python script, a blockquote, a task list and a footnote, rendered in the Paper theme.
# Branch office network migration
The Denver and Austin branch offices moved from the old MPLS circuits to SD-WAN
over the first two weeks of March. This report covers the cutover window, the
throughput numbers we measured before and after, and the open items left for
the helpdesk team.
Both sites kept the legacy circuit live in parallel for 72 hours after cutover
as a fallback path. Neither site needed it: the SD-WAN link held for the full
window with no failover events logged.
## Throughput before and after
| Site | Old link (Mbps) | New link (Mbps) | Packet loss (old) | Packet loss (new) |
| ------ | ---------------- | ---------------- | ------------------ | ------------------ |
| Denver | 42 | 380 | 0.8% | 0.1% |
| Austin | 38 | 350 | 1.1% | 0.2% |
Both sites more than doubled again after the second week, once the local ISP
finished provisioning the full circuit.[^1]
The health check script below ran every five minutes during the cutover
window and logged the round-trip time and loss to the monitoring bucket:
```python
import subprocess
import time
def ping_stats(host: str, count: int = 20) -> tuple[float, float]:
result = subprocess.run(
["ping", "-c", str(count), host],
capture_output=True, text=True, timeout=30,
)
loss_line = next(l for l in result.stdout.splitlines() if "packet loss" in l)
loss = float(loss_line.split("%")[0].split()[-1])
rtt_line = [l for l in result.stdout.splitlines() if "min/avg/max" in l][0]
avg_rtt = float(rtt_line.split("=")[1].split("/")[1])
return loss, avg_rtt
if __name__ == "__main__":
loss, rtt = ping_stats("10.4.0.1")
print(f"loss={loss}% rtt={rtt}ms")
time.sleep(300)
```
> The old circuit's contract runs until June 30. Cancel it only after both
> sites have logged four clean weeks on the new link, per the change board's
> standing rule.
## Open items
- [x] Confirm SD-WAN failover order with the carrier
- [x] Update the branch office runbook with the new gateway addresses
- [ ] Retire the old MPLS circuit once the 30-day watch period ends
- [ ] Train the helpdesk team on the new SD-WAN dashboard
- [ ] Schedule the same cutover for the Raleigh office in April
[^1]: Measured on March 17 after the ISP moved both sites from a 500 Mbps to a
1 Gbps port, at no change in the monthly cost.
Branch office network migration
The Denver and Austin branch offices moved from the old MPLS circuits to SD-WAN
over the first two weeks of March. This report covers the cutover window, the
throughput numbers we measured before and after, and the open items left for
the helpdesk team.
Both sites kept the legacy circuit live in parallel for 72 hours after cutover
as a fallback path. Neither site needed it: the SD-WAN link held for the full
window with no failover events logged.
Throughput before and after
| Site |
Old link (Mbps) |
New link (Mbps) |
Packet loss (old) |
Packet loss (new) |
| Denver |
42 |
380 |
0.8% |
0.1% |
| Austin |
38 |
350 |
1.1% |
0.2% |
Both sites more than doubled again after the second week, once the local ISP
finished provisioning the full circuit.
The health check script below ran every five minutes during the cutover
window and logged the round-trip time and loss to the monitoring bucket:
import subprocess
import time
def ping_stats(host: str, count: int = 20) -> tuple[float, float]:
result = subprocess.run(
["ping", "-c", str(count), host],
capture_output=True, text=True, timeout=30,
)
loss_line = next(l for l in result.stdout.splitlines() if "packet loss" in l)
loss = float(loss_line.split("%")[0].split()[-1])
rtt_line = [l for l in result.stdout.splitlines() if "min/avg/max" in l][0]
avg_rtt = float(rtt_line.split("=")[1].split("/")[1])
return loss, avg_rtt
if __name__ == "__main__":
loss, rtt = ping_stats("10.4.0.1")
print(f"loss={loss}% rtt={rtt}ms")
time.sleep(300)
The old circuit's contract runs until June 30. Cancel it only after both
sites have logged four clean weeks on the new link, per the change board's
standing rule.
Open items
Rendered in the Paper theme. Open it in the editor to change the theme or the text.
Dark themes print as dark text on white
A dark theme such as Terminal or Carbon looks inverted on screen. The PDF export swaps that to dark text on a white page rather than printing a dark page background. Tables, code blocks and the Python syntax highlighting in the worked example below keep their colours and spacing; only the page ground changes.
Nothing in the document is uploaded to print it. Rendering, theming and the print step all run on your device, with no document content sent anywhere. The PDF is written by your browser's own PDF engine, the same one it uses for any page you print. Fonts embed the way that browser embeds them, and the file never passes through a server. There is no watermark added and no cap on how many pages the document runs to.
When the .html download fits better
Choose "Download .html" over printing when the person reading the file will resize the window, zoom the text, or read it on a phone. That download packages the page as one file, styling and fonts included. The layout adjusts to the reader's screen instead of staying fixed at the paper size a PDF locks in.
Questions
Does the PDF get a watermark or a page limit?
No. markdown.style adds no watermark and sets no page limit; the browser writes the PDF, the same way it would for any page you print.
Can I remove the page header and footer from the PDF?
Yes. The print dialog has a "Headers and footers" option; switch it off before saving and the URL, date and page number stop printing.
Will a dark theme print with a dark page background?
No. Dark themes print as dark text on a white page, so the PDF stays readable and does not use a page of ink or toner per copy.
When should I download the .html file instead of printing?
When the reader needs to resize text or the window themselves. The .html download is one file with the theme's CSS embedded, so it stays styled and adjustable, where a PDF is fixed at the page size you chose.