Turning Markdown notes into slides

If you write in Markdown, you already have most of a deck. Headings, lists, tables and emphasis map neatly onto slides. The catch is that notes written for yourself are rarely ready for an audience. They wander, they repeat, and the most important point is often buried in the middle.

This guide closes that gap with a few structural changes, keeping your Markdown as it is.

How Markdown maps to a deck

It helps to see the translation before you start editing.

In your notes	On the slides
## heading	A new slide, with the heading as its title
### heading	A section within that slide, or a slide of its own if it’s long
Bulleted list	Slide points
Numbered list	Steps or a sequence
Table	A table slide, or the data behind a chart
Bold text	Emphasis, used sparingly
Blockquote	A callout or key line
Long paragraph	Something you’ll need to cut down

The last row is where most of the effort goes. Once the structure is right, a Markdown to PPT converter can produce the first version of the slides for you to edit.

Pick one heading level for slides

Notes often use headings loosely. A ## here, a ### there, sometimes a bold line pretending to be a heading. Decide which level will mean “new slide”, usually ##, and go through the notes making that consistent.

Then read only your ## headings from top to bottom. If they tell the story in order, you have an outline. If they read like a filing system (“Misc”, “More notes”), rename them.

Writing headings as short statements helps a lot. “Search is slow on large projects” tells the audience something. “Search” doesn’t.

Put the point at the top of each section

In notes, we tend to write in the order we thought: context, then detail, then the conclusion. On a slide, the conclusion should come first. For each ## section, make the first line the one thing someone should remember. Everything after it is support.

If you can’t write that first line, the section probably isn’t one idea. Split it into two headings, or merge it with its neighbour.

Shrink paragraphs into lists

Paragraphs are fine in notes. They’re hard to read on a screen. For each long paragraph, ask what the two or three separate claims are, and turn those into list items.

For example, a paragraph like:

We tested the new onboarding flow with a handful of users. Most of them finished setup without help, but several got stuck on the permissions step, and nobody noticed the import option.

becomes:

• Most testers finished setup without help
• The permissions step caused confusion
• Nobody found the import option

Keep list items parallel and short. If an item needs a sentence of explanation, put the explanation in your speaker notes, not on the slide.

Keep tables small

Markdown tables are easy to write and easy to overdo. A table with eight columns and twenty rows is fine in a file you’ll scroll through. On a slide, it’s unreadable.

Before converting, cut each table down to what the audience needs. Three or four columns, five or six rows is a sensible ceiling. If the table is really about one trend, consider whether a simple chart would make the point faster. Move the full table to the end of the notes so it’s there if someone asks.

Separate what you’ll say from what you’ll show

Notes usually mix the two. A useful habit is to add a short “Notes” sub-section, or a blockquote, under each heading for things you want to say but don’t need on screen: an example, a caveat, a story.

Those parts become speaker notes, so the slide stays clean.

Add a start and an end

Notes rarely open with a summary or end with an ask, because you knew both when you wrote them. Your audience doesn’t. Add two sections:

• At the top: a short summary of the whole talk in three lines. What it’s about, what you found or decided, and what you want from the room.
• At the bottom: a “Next steps” or “What we need” section, with names and dates if there are actions.

People who drift off in the middle will still leave knowing the main point.

Park the extra material

Links, raw data and alternatives you considered don’t belong in the talk, but don’t delete them. Move them under a final ## Appendix heading, where they can become backup slides.

A quick worked example

Say your notes for a team update look like this, in outline:

• ## Context (two paragraphs about the quarter)
• ## Search (long paragraph, a table of query times)
• ## Things to fix (a list of twelve items)
• ## Misc (links and a few thoughts)

This is an illustrative example.

After an editing pass, they might read:

• ## Summary (three lines)
• ## Search is slow on large projects (three points, a three-row table)
• ## Three fixes we'll ship this month (three items, owners)
• ## What we need from you (one ask)
• ## Appendix (full table, all twelve items, links)

Same content, but each heading is now a slide with one clear point.

Before you present

Run through this short check:

• Do the ## headings read as a story on their own?
• Does each section open with its point?
• Are long paragraphs now short lists?
• Are tables small enough to read from the back of a room?
• Is there a summary at the top and an ask at the end?
• Is everything else under the appendix?

For more writing habits that help any page present well, see writing pages that turn into good slides. The guide to turning a document into a presentation covers the full process.