Write a report or proposal in Markdown and export a PDF

By Fazt · Updated October 7, 2026

Reports and proposals are read by busy people who have to decide something: approve a budget, pick a supplier, sign off a project. They need a clear structure and a document that looks cared for. Markdown lets you spend your time on the first and get the second almost for free. Below are two templates and everything you need to turn them into a professional PDF.

Why write business documents in Markdown

Focus on content. You type headings, lists and tables instead of formatting them.
Reusable templates. Save a skeleton once and every report starts with the same sections in the same order.
Version control. Plain text means Git or any diff tool shows exactly which sentence or figure changed between versions.
Consistent styling. The look comes from a theme, and the editor remembers your style settings in this browser, so every report matches the last one.

Template: project report or proposal

Copy this into the Markdown to PDF editor, replace the example content and delete the sections you don’t need:

# Field Service Scheduling Review

**Proposal to the Operations Committee, Calder Facilities**

Dana Whitfield, Operations · October 7, 2026 · Version 1.0 · Confidential

<!-- pagebreak -->

## 1. Executive summary

Technicians spend almost a third of each shift driving, because routes are planned by hand. We recommend a scheduling tool with automatic routing, piloted in two regions from November. The pilot costs $48,400 and should cut driving time by about 20%.[^1]

> **Decision needed:** approve the pilot budget by October 31.

## 2. Context

Dispatchers plan the day for 46 technicians in a spreadsheet designed for 15. Overtime has risen for two quarters.

## 3. Findings

Dispatch data show the same pattern in every region:[^2]

| Metric, Jan–Jun 2026 | North | South | East | West |
| --- | ---: | ---: | ---: | ---: |
| Jobs per technician per day | 4.1 | 3.6 | 4.4 | 3.8 |
| Driving time, % of shift | 27% | 34% | 24% | 31% |

- **Travel is the biggest loss.** South and West drive the most and complete the fewest jobs.
- **Plans break by mid-morning.** One urgent call means re-planning the day by phone.

## 4. Recommendations

1. Adopt a scheduling tool with automatic route optimization.
1. Pilot it in South and West, where the gain is largest.
1. Keep the spreadsheet as a fallback until the review.

## 5. Timeline

| Phase | Dates | Outcome |
| --- | --- | --- |
| Setup and data import | Nov 2–20, 2026 | Dispatchers trained |
| Pilot | Nov 23, 2026 – Feb 26, 2027 | Weekly travel figures |
| Review | March 2027 | Go/no-go for all regions |

## 6. Budget

| Item | Type | Cost |
| --- | --- | ---: |
| Licenses, 12 users × 4 months | Subscription | $9,600 |
| Implementation | One-off | $18,000 |
| Training | One-off | $6,400 |
| Internal project time | Internal | $10,000 |
| Contingency (10%) | Reserve | $4,400 |
| **Total** | | **$48,400** |

<!-- pagebreak -->

## Appendix A. Method

We re-planned two sample weeks in the vendor's trial account, compared total driving time and interviewed 8 dispatchers and 12 technicians.

[^1]: Simulation on March 2026 data; see Appendix A.
[^2]: Dispatch spreadsheet, January–June 2026, 9,812 jobs.

Note the decision that closes the summary, and the sentence telling readers what to look for in the findings table. For a visual timeline, a mermaid block can draw a Gantt chart; see the syntax guide.

A shorter template: meeting minutes

Minutes and weekly status updates need no cover: decisions first, then actions with an owner and a date. The - [ ] lines print as empty checkboxes.

# Steering meeting — October 6, 2026

**Attendees:** Dana Whitfield, Luis Ortega, Priya Shah · **Minutes:** Luis Ortega

## Decisions

- Pilot regions confirmed: South and West.
- The budget request goes to the committee on October 14.

## Action items

- [ ] Dana: send the final proposal — Oct 10
- [ ] Priya: review the contract with Legal — Oct 17
- [ ] Luis: book training rooms — Oct 24

**Next meeting:** October 20, 10:00

The cover page

The cover is the title block followed by a line containing only  (\pagebreak and \newpage also work). Everything after it starts on a new page; a second marker before the appendix does the same for it. The preview shows markers as dashed lines.

Keep the cover to a title that says what the document is about, a line saying who it is for, and a metadata line with author, date, version and confidentiality. The first # heading also becomes the PDF’s suggested file name.

Numbering, footnotes and callouts

Number sections by hand. The editor doesn’t number headings, build a table of contents or add page numbers, so write ## 3. Findings. Readers can then say “see section 5”.
Let lists number themselves. Only the first number of an ordered list counts, so writing 1. on every line lets you reorder items freely.
Right-align figures. ---: in a table’s separator row right-aligns that column so amounts line up.
Cite sources in footnotes. Write [^1] after the claim and [^1]: source on its own line. Notes print together at the very end of the document, after the appendix, not at the foot of each page. If you need sources before the appendix, write a Sources section by hand.
Use quotes as callouts. Blockquotes (>) print in italics with a rule in the heading color: good for an interview quote, or for a callout that opens with a bold label like Decision needed:. One or two per document is plenty. GitHub’s > [!NOTE] syntax isn’t supported and prints as text.
Mind line breaks. Consecutive lines merge into one paragraph; leave a blank line between them, or end the line with a backslash (\).

Pick a theme that suits the document

In the Style panel, the theme sets the tone before anyone reads a word:

Classic (Libre Baskerville, a serif) feels formal: board proposals, legal or financial reports. Its wide letters lengthen documents, so try 10.5 pt.
Modern (Inter) is a neutral default for internal reports.
Clean (Roboto) is compact and suits documents full of tables.
Editorial (serif text, sans-serif headings) reads like a publication: research summaries, white papers.
Technical (monospaced headings) fits engineering reports and post-mortems.
Friendly (warmer colors) suits education or non-profit documents better than a budget request.

Set the Headings color to your brand color and keep the text dark. Wide margins leave room for handwritten comments on a printed review copy.

Write a report that gets read

Lead with the conclusion. The summary says what you found, what you recommend and what you need from the reader, by when. Many readers stop there, so write it last.
Make it scannable. Open key bullets with a bold sentence that carries the point; reading only the bold text should still tell the story.
One idea per paragraph, stated in its first sentence.
Tables for comparisons, prose for reasoning. Four regions and two metrics are hard to follow in a sentence and easy in a table.
Be precise: units on every figure, a year on every date.
Push detail to the appendix, where methods and raw data support the argument without slowing it down.

Starting from a Word document

If last quarter’s report is a .docx, drop it on the Word to Markdown converter: headings (from Word’s heading styles), lists, tables and footnotes become Markdown. Turn on Include images, then click Open in editor → PDF. Images travel embedded in the Markdown; if they are too large for the browser’s storage, the document opens without them.

Export, hand over, keep the source

Click Download PDF and choose Save as PDF in the print dialog.
Turn off Headers and footers.
Check the print preview before saving: the editor’s preview is one continuous sheet that marks your manual breaks, not the automatic ones.

The editor doesn’t add page numbers; the browser’s Headers and footers option does, along with the date, the document title and the web address. Avoid More → Quick PDF for reports: it saves pages as images, so nobody can search the text or copy a figure.

Then use More → Download .md and keep the Markdown next to the PDF, with the version in both names. The editor holds only one draft per browser, and a new document or a converted file replaces it. With the source saved, version 1.1 is a quick edit, and the file becomes your next template: the same master-copy habit as in the Markdown resume guide.

Troubleshooting

A heading is stranded at the bottom of a page

The stylesheet asks the browser to keep headings with the text that follows, but browsers treat that as a preference. Put  on the line before the heading.

Images don’t show or are too big

A web page can’t read your disk, so ![Chart](chart.png) won’t load; use an image at a public URL. To shrink an image, use HTML: <img src="https://…/chart.png" width="320" alt="Driving time">. Images, code blocks and diagrams are never split, so a tall one that doesn’t fit jumps to the next page and leaves a gap; put it at the start of a section or in the appendix.

Long or wide tables

Long tables continue across pages without splitting a row, and Chromium-based browsers and Firefox normally repeat the header row. Width is harder, because pages are always portrait. Keep tables to five or six columns, shorten headers, swap rows and columns, or lower the font size and choose Narrow margins. Full data sets belong in an appendix.

A dollar amount turns into italic letters

Text between two dollar signs is read as math, as in “$500, or US$ 20 a month”. Write \$ for a literal dollar sign.

Everything runs in your browser, so budgets and client names are never uploaded.