Code in PowerPoint: Font Size, Short Examples and Export Checks

When showing code in PowerPoint, check how the snippet looks from the back of the room rather than only in your editor. A forty-line function that is readable on a laptop may be too small when projected. Start with the lines needed to explain the example, choose a readable font size and move supporting code to notes or a repository link.

How much code fits on one slide

For an initial draft, try roughly ten to twelve lines, then test the projected result. The useful amount depends on line length, font size, room distance and the time you give people to read; there is no fixed line count that guarantees readability. If the example needs thirty lines to make sense, the slide is trying to do the job of a handout or a repository link.

Remove imports, logging or setup only when they are irrelevant to the explanation. Keep error handling when it is part of the point, and label any omitted implementation so the example is not mistaken for a complete program. Replace the boring middle with a comment such as // ...validate input... so the shape stays honest. Long lines are the other enemy, because wrapped code is much harder to read than wrapped prose. Rename a variable, break a call over two lines, or shorten a string literal before you shrink the font.

Font size and contrast for the back row

Monospaced fonts give characters equal width, which helps preserve indentation. Depending on the fonts used, the same line may occupy a different width from body text. That pushes people to lower the size, which is the wrong fix. Pick the size the room needs first, then trim the code until it fits. The presentation font size calculator gives a minimum readable size based on room depth and screen size, and code deserves at least the same treatment as your bullet points.

Contrast matters more than colour. Projectors wash out pale tones, so light grey comments and the soft pastels of many editor themes can vanish entirely. Light text on a dark box tends to hold up well, as long as the room is not brightly lit. Test the deck on the actual projector if you can, and look at it from the back.

Pointing at the one line that matters

Almost every code slide has one line that carries the idea, and the audience should not have to hunt for it. The simplest approach is visual: make that line bold or give it an accent colour, and dim the rest. Saying "the third line" out loud helps too, so readers know where to look while you explain it.

For a change between two versions, a before/after pair usually explains more than a unified diff with plus and minus signs, which takes practice to read quickly. Put the old version on the left and the new one on the right, or show the old version on one slide and the new one on the next, keeping everything else identical so the eye catches the difference.

Splitting a long example across slides

When an example really cannot shrink, spread it out instead of squeezing it. Give each slide one step: the function signature and its input, then the core loop, then what it returns. Repeat a line or two of context at the top of each slide, such as the signature, so people who glanced away can find their place. Keep indentation consistent between slides; if the code jumps sideways from one slide to the next, it looks like a different program.

Writing code in PowerPoint as Markdown fenced blocks

Laying out code by hand in text boxes is fiddly, and pasting from an editor drags along fonts and background colours you did not ask for. Writing the slides in Markdown avoids both. In the Markdown to PPTX converter, three dashes start a new slide, the first heading becomes the title, and a fenced code block stays a code block:

## Retry with backoff

```python
for attempt in range(5):
    if send(request):
        break
    sleep(2 ** attempt)
```

Note: Point at the sleep line. Doubling the wait is the whole idea.

---

On export, the fenced block becomes monospaced text on a dark box. It is native PowerPoint text, not a screenshot, so you can still fix a typo in PowerPoint, bold the key line, or recolour a keyword by hand. The current code exporter starts at 11-point text and may shrink it further to fit its box. That can be too small for projection. Increase the font in PowerPoint and split long blocks across slides rather than assuming the export has chosen a suitable presentation size. The Note: line goes to the speaker notes pane rather than the slide. For code next to an explanation, a <!-- layout: two-col --> comment splits the slide into two columns, which suits the before/after pattern above. You can preview everything live in the Markdown slide editor before exporting.

When to switch to a live demo

Static slides are good at showing the shape of code. They are poor at showing behaviour: how fast something runs, what an error message looks like, how a UI responds to a click. If the point of the section is "watch what happens", switch to the terminal or browser and let it happen.

Prepare a fallback for a demo that cannot run as planned. Keep a slide with the code and its expected output right behind the demo, so you can continue explaining the result if the network or a dependency is unavailable. Bump the terminal font well past what feels comfortable on your laptop, and close notifications before you start.

What this can't do yet

Code blocks export as editable monospaced text, initially 11 points with possible further shrinking. They have no syntax highlighting, line numbers, diff highlighting or line-by-line reveal, and do not run code. Adjust emphasis and font size in PowerPoint. ToSlides uses four themes without animated transitions or a free-positioning canvas; AI generation separately requires sign-in and credits.