Format Code Snippets: Fix Ugly Presentation Themes Fast

The Back Row Can't Read Your Code

You're nine minutes into your talk at a regional dev meetup. The room holds 120 people. You click to your next slide—a critical code snippet showing the core pattern of your library. From the third row, someone squints. From the back row, three people just checked their phones. They can't read it.

The code is there, technically. But it might as well be wallpaper.

I've watched this exact scenario play out at dozens of conferences. The speaker did the hard work—built the demo, wrote the talk, rehearsed the timing—but the code snippet itself is a visual disaster. A dark theme designed for a 27-inch monitor, now projected onto a screen washed out by venue lighting. Font size 14pt. Line numbers running off the edge. Syntax highlighting tuned for an IDE, not a stage.

Here's the truth nobody tells you: formatting code snippets for presentation slides is a completely different discipline than formatting code for your editor. The context changes everything. And most developers never learn the difference because there's no class on it.

If you're a developer advocate, a tech educator, or anyone who puts code on slides, this guide will walk you through the mistakes that kill your presentations—and how to fix them with custom themes built specifically for projection.

The Problem: Why Code Snippets Die on Stage

Let's name the mistakes. I see them at almost every conference I attend, and I've made most of them myself.

Mistake #1: Screenshots of Your IDE

This is the most common offense. You write clean code in VS Code or IntelliJ, take a screenshot, and paste it into Google Slides or Keynote. Done. Easy. Wrong.

Your IDE theme was designed for a screen viewed at arm's length, not a projector viewed from 15 meters away. The contrast that looks crisp on your laptop turns muddy under stage lighting. And if you ever need to edit that code? You're re-screenshotting the whole thing.

Mistake #2: Default Syntax Highlighting Themes

Most code snippet tools ship with themes like "Monokai," "Dracula," or "GitHub Dark." These are beautiful in an editor. On a projector, they're a problem. Dark backgrounds absorb light from the projector, making your code dim. Blue and purple syntax tokens—the colors these themes lean on heavily—become nearly indistinguishable under typical conference hall lighting.

Mistake #3: Too Much Code, Too Little Slide

You paste a 40-line function into your code snippet tool, pick a theme, and drop it onto a slide. The tool auto-sizes the font to fit. Now your code is 12pt. Nobody past row two can read a single character.

A 120-person room typically has a back row about 15 meters from the screen. At that distance, 14pt code subtends roughly 0.3 degrees of visual angle—below the threshold where most people can reliably distinguish characters. You need at least 28pt, ideally 32pt, for a room that size. That means your slide can hold about 12 to 15 lines of code maximum. Not 40.

Mistake #4: Ignoring the Code-Slide Relationship

Your code snippet sits on a white slide with a title at the top and nothing else. Or worse: it sits on a slide with three bullet points, a logo, and a footer. The code competes with everything else on the slide for attention—and loses.

The Cause: Code Snippet Tools Default to the Wrong Context

Here's why these mistakes happen: code snippet tools are built primarily for documentation, blog posts, and README files. Their default themes, font sizes, and padding assume the reader is sitting close to a screen, reading at their own pace, with the ability to zoom in.

A presentation is none of those things.

Your audience is far away, viewing at a fixed size, and you control the pace. They have about 30 seconds to absorb each code slide before you move on. That means every element—font size, color contrast, line length, background—needs to be optimized for rapid comprehension at a distance, not for careful study up close.

The good news? Most modern code snippet tools let you create custom themes. You just have to know what to change.

The Fix: Building Custom Themes for Presentation Slides

Let's walk through this step by step. I'll use the workflow I've refined after speaking at 30+ conferences over the past four years.

Step 1: Choose a Code Snippet Tool That Supports Custom Themes

Not all tools are equal here. Some, like Carbon and Ray.so, give you preset themes but limited customization. Others—like Snappify, CodePNG, and self-hosted options like Prism.js or Shiki—let you define your own color tokens, backgrounds, and typography.

For presentations, you want a tool that lets you control:

- Background color (solid, not gradient) - Token colors for each syntax type (keywords, strings, comments, functions, numbers) - Font family and font size - Padding and border radius - Window chrome (the little dots, title bar, etc.)

If your tool doesn't expose these, switch tools. Seriously. This matters.

Step 2: Design a Light Theme for Projection

This is counterintuitive for a lot of developers. We love dark themes. But here's the math: projectors push light. A dark background means the projector is pushing less light to that area of the screen, which means your code—the thing you want people to read—gets less luminance.

Switch to a light background. Off-white (#FAFAFA) works better than pure white (#FFFFFF) because pure white can glare under strong projection. Your text should be near-black, not pure black—something like #1A1A1A reduces harshness while maintaining contrast.

Here's a concrete token color scheme I use for my presentation theme:

- Keywords: #D33682 (a strong magenta—reads well at distance) - Strings: #2AA198 (teal—distinct from magenta) - Comments: #586E75 (medium gray—visible but de-emphasized) - Functions: #268BD2 (blue—pops without being electric) - Numbers: #CB4B16 (burnt orange—separates from strings) - Background: #FAFAFA - Base text: #1A1A1A

These colors are adapted from Solarized Light, but I've bumped the saturation on keywords and strings to compensate for projector washout. Test them on a real projector if you can—what you see on your laptop is not what the audience sees.

Step 3: Set Font Size Based on Room Size

This is where most people guess wrong. Here's a simple rule I use:

- Small room (under 40 people, under 8 meters deep): 24pt minimum - Medium room (40–150 people, 8–15 meters deep): 28pt minimum - Large room (150+ people, 15+ meters deep): 32pt minimum

When in doubt, go bigger. If your code doesn't fit at 28pt, your code is too long for one slide. Split it.

For font family, use a monospace font designed for screens at small sizes. Fira Code, JetBrains Mono, and SF Mono are all excellent choices. Avoid fonts like Courier Prime that were designed for print—they thin out when projected.

Step 4: Trim Your Code Ruthlessly

This isn't a formatting step—it's a content step, but it directly affects your formatting. A presentation slide is not a documentation page. Your audience doesn't need to see imports, boilerplate, error handling, or every parameter.

Cut your code to the essential idea. If you're showing a React hook, show the hook. Not the imports. Not the component that uses it. Not the TypeScript types. Just the 8–12 lines that demonstrate the concept.

If you need to show context, use a second slide. Don't cram.

Step 5: Remove Visual Noise from the Snippet

Many code snippet tools add window chrome—those three colored dots at the top, a title bar, a filename. For presentations, this is noise. Turn it off. Every pixel of attention spent on window chrome is a pixel not spent on your code.

Same goes for line numbers. In a presentation, line numbers are rarely useful. If you need to reference a specific line, say it out loud: "Look at the third line here." Your voice is faster than someone scanning numbers from the back row.

Step 6: Test on a Projector Before Your Talk

This step sounds obvious and is skipped by 90% of speakers. Find a projector—any projector—and test your slides. You will discover that some colors you thought were distinct look identical when projected. You'll find that your font is smaller than you thought. You'll notice that the off-white background looks more yellow than expected under a warm bulb.

Every venue is different, but the general issues are consistent. Build a 30-minute buffer into your prep to test on real hardware.

The Workflow That Ties It Together

Here's my actual process, start to finish, for every talk:

1. Write the code snippet in my editor, then trim it to 10–12 lines. 2. Paste it into my code snippet tool (I use Snappify for this). 3. Apply my custom presentation theme (the light theme with the token colors above). 4. Set font size to 28pt. If it doesn't fit, trim more code. 5. Export as a high-resolution PNG (2x scale minimum—projectors need sharp edges). 6. Place it on a slide with a plain background matching the snippet background. 7. Add a short title above the code. Nothing else. 8. Test on a projector. Adjust if needed.

Total time per slide: about 5 minutes once your custom theme is saved. The theme is the upfront investment—build it once, reuse it forever.

Your Code Deserves to Be Read

You spent hours writing the code. You spent hours building the talk. Don't let a default theme and a 14pt font throw that work away.

The difference between a forgettable code slide and one that lands is not about being a designer. It's about understanding the context—projection, distance, lighting, attention—and adjusting your formatting to match. Custom themes in your code snippet tool are the lever that makes this possible.

Build a light theme. Bump the font size. Cut the code. Test on hardware. It's not glamorous, but the back row will thank you.