How to Beautify Code and Export as Image for Presentations

Set your export resolution to 2x your slide width before you do anything else

If your presentation slide is 1920px wide, your code image needs to be at least 3840px on its longest edge. That single decision eliminates 90% of the pixelation problems developers complain about when they drop code screenshots into Keynote, PowerPoint, or Google Slides. Most code snippet tools default to screen resolution — usually around 1440px — which looks fine on your laptop and turns to mush the moment a projector stretches it across a 10-foot screen.

This article is written for the specific workflow of developer advocates, tech educators, and conference speakers who regularly present code to live audiences. Every tip here addresses a mistake I've watched derail otherwise excellent talks. Each section follows the same pattern: the mistake, why it kills your presentation, and the concrete fix.

Stop using your IDE's default theme — it was never designed for slides

The mistake

You write code in VS Code with One Dark Pro, so you export a snippet using that exact theme. The syntax highlighting looks great on your monitor. Then you project it. The dark background becomes a muddy gray. The subtle color differences between tokens — the exact thing syntax highlighting exists to communicate — vanish under projector bulbs that wash out contrast.

The fix

Use a presentation-optimized theme. Dracula and Night Owl survive projection reasonably well, but the safest choice is a light theme with high-contrast token colors. GitHub Light works because its background is pure white (#ffffff) and its keyword color is a saturated red (#d73a49) that cuts through even a dim projector bulb.

When you beautify code in a snippet tool, switch themes deliberately. Do not export with the theme you code in. Export with the theme your audience can read from 40 feet away.

Trim your snippet before you beautify — not after

The mistake

You paste a 60-line function into a code beautifier, hit format, then export the whole thing as an image. The result is a wall of text no one in the audience will read. Conference attendees give a code slide about 8 seconds of attention. If they cannot parse the key logic in that window, you've lost them.

The fix

Cut your snippet to 15 lines or fewer before you even open your beautifier. If the concept requires more context, split it across multiple slides. Here is a concrete approach:

• Identify the single line or block that demonstrates your point.
• Remove all boilerplate — imports, type annotations that don't add clarity, error handling that isn't the topic.
• Replace removed context with a comment: // ... setup omitted
• Beautify the trimmed version so indentation and spacing are perfect.
• Export at your 2x resolution.

A 12-line snippet exported at 3840px width with a 28pt-equivalent font size is readable from the back row. A 60-line snippet at the same resolution is not. The math is that simple.

Cap your line length at 48 characters for projection

The mistake

Your beautifier wraps long lines at 80 characters because that's the standard. On a slide, 80 characters at a readable font size will overflow the width of a standard 16:9 presentation canvas. The line wraps, breaks your syntax highlighting layout, and makes the code look broken.

The fix

Set your line length cap to 48 characters when preparing code for slides. Most code snippet tools and beautifiers let you configure the print width. In Prettier, for example, you'd set printWidth: 48. This forces earlier line breaks at natural points — after operators, at function arguments — and keeps every line visible without horizontal scrolling or image cropping.

If a line genuinely cannot be shortened to 48 characters without losing meaning, that line probably needs its own slide with an annotation callout.

Never screenshot code from your editor — export it properly

The mistake

You select code in your IDE, take a OS-level screenshot, and paste it into your slide. This captures window chrome, cursor blinkers, linting squiggles, and sometimes your file tree. It also captures at your monitor's resolution, which we've already established is too low for projection.

The fix

Use a dedicated code snippet tool that exports clean images. The workflow should be:

1. Paste your trimmed, beautified code into the tool.
2. Select your high-contrast presentation theme.
3. Set the background to transparent or a solid color matching your slide deck.
4. Export as PNG at 2x your slide width (minimum 3840px for a 1920px deck).

Transparent backgrounds matter more than people realize. If your slide background is #1a1a2e and your code image has a white background, you've created a visual box that fights your deck's design. Transparent export lets the code sit naturally on your slide.

Add window chrome only when it serves the narrative

The mistake

Either you add no visual context at all — bare code floating on a slide with no indication of language or environment — or you add full macOS window chrome with traffic-light buttons that contribute nothing and waste 15% of your image's vertical space on decorative pixels.

The fix

Add a minimal filename tab or language label. The most effective approach is a simple filename bar: auth.service.ts in a small monospace font at the top of the image. This tells the audience the language and the file context without eating screen real estate.

Skip the traffic lights. Skip the sidebar. Skip the status bar. Every pixel you devote to fake editor UI is a pixel stolen from font size.

Test your exported image on a real screen — not your laptop

The mistake

You review your code slide on your 27-inch monitor at arm's length. It looks sharp. You ship the deck. At the venue, you discover the projector is 1024x768, the room is 60 feet deep, and your 28pt code is unreadable from row 15.

The fix

Run a pre-presentation checklist:

• View your slide on a TV or projector at the approximate audience distance (minimum 15 feet).
• Confirm that you can read every character without squinting.
• Check that syntax highlighting colors are distinguishable — especially red vs. orange and blue vs. purple, which projectors frequently merge.
• Verify that no line is clipped at the right edge.
• Ensure the code image background matches or complements your slide background.

If you cannot test on a real projector, at minimum view your slides on a phone held at arm's length. If you can't read the code on your phone, the back row can't read it either.

Keep a reusable export preset

The mistake

You configure your snippet tool from scratch every time you make a new code slide. You forget the resolution setting, pick a different theme, and your deck ends up with inconsistent code styling across slides. Audiences notice this even when they can't articulate why the presentation feels unpolished.

The fix

Save a preset in your code snippet tool with these locked settings:

• Theme: GitHub Light (or your tested high-contrast choice)
• Font: JetBrains Mono or Fira Code, 16px base
• Line length: 48 characters
• Background: transparent
• Export resolution: 3840px width
• Window chrome: filename tab only

Every code slide in every deck uses this preset. Consistency is what separates a professional talk from an amateur one, and your audience reads visual inconsistency as a credibility signal — even if they don't know it.

The full checklist, condensed

Before you export any code image for a presentation, run through this sequence:

1. Trim to 15 lines or fewer.
2. Set print width to 48 characters.
3. Beautify with proper indentation and spacing.
4. Apply a high-contrast presentation theme — not your coding theme.
5. Add a filename tab. Skip everything else.
6. Export as transparent PNG at 2x slide width.
7. Test readability at 15+ feet on a real screen.

Seven steps. Roughly 90 seconds per snippet once you have your preset saved. The difference between a code slide that communicates and one that confuses is not your code — it's the export pipeline you run it through.