5 Steps Client-Side Code To Image Generators Workflow

Start with a DOM-to-canvas library, not a screenshot API

Here's the thing I wish someone told me three years ago: if you're running a technical blog and embedding code snippets as images, you don't need a server-side screenshot service. I spent $19/month on one before realizing the browser already does everything I need. A client-side code to image generator using dom-to-image or html2canvas renders your syntax-highlighted code block to a PNG right in the browser tab. Zero API calls. Zero latency beyond render time. Zero ongoing cost.

Let me walk you through the exact workflow I use for every tutorial post I publish, from raw code to embedded image.

Pick your highlighting engine first

Your code to image pipeline starts with the syntax highlighter, not the image generator. I use Prism.js because its token classes are predictable and map cleanly to explicit CSS rules. Highlight.js works too, but I've found Prism's class structure easier to theme consistently across 40+ blog posts.

Here's the decision tree I actually use: if you need 200+ language support out of the box, grab Highlight.js. If you want fine-grained control over token colors and you're only writing about 5-10 languages, Prism is the better fit. For most technical bloggers writing tutorials in a handful of languages, Prism wins.

Lock your theme down with explicit hex values

This is non-negotiable. Create one CSS file that defines every Prism token class with actual hex codes. Not CSS variables referencing another variable—literal hex values. When you're generating images months apart, indirection in your theme CSS will bite you. I learned this the hard way when a "Dracula-inspired" theme drifted across posts because I'd tweaked a variable six months earlier and forgotten about it.

My locked theme file is 47 lines. It covers keywords, strings, functions, numbers, comments, operators, punctuation, and the background/foreground pair. That's it. Every code image on my blog uses exactly these colors, whether I generated it last Tuesday or last year.

Build the rendering container

Structure your code block for clean capture

The container matters more than people think. Here's the HTML structure I render every snippet into before generating the image:

<div class="snippet-wrapper">
  <div class="snippet-container" style="width:680px;padding:20px;background:#282a36;">
    <div class="window-controls">
      <span class="dot red"></span>
      <span class="dot yellow"></span>
      <span class="dot green"></span>
    </div>
    <pre><code class="language-javascript">
      // your highlighted code here
    </code></pre>
  </div>
</div>

The key details: fixed width of 680px to match my blog's content column, explicit 20px padding, and a monospace font with a declared fallback stack. The window-controls div isn't decorative—it gives the image immediate visual context so readers recognize it as a code snippet while scanning through a long tutorial.

Font sizing that survives scaling

Set your font-size in pixels, not rem or em. When dom-to-image captures the node, it reads computed styles. A 14px font at 2x device pixel ratio renders crisp text at 28px effective resolution. If you use rem units, the captured image inherits the root font size at capture time, which can vary if you've changed your base font for accessibility testing or switched browsers.

I use 14px JetBrains Mono. At 2x capture scale, that's effectively 28px—sharp on retina displays, readable on standard displays, and small enough that 68-character lines fit within my 680px container without wrapping.

Choose your capture method

dom-to-image vs. html2canvas: real benchmark numbers

I've timed both libraries across dozens of snippets. For a typical 30-line JavaScript snippet with full syntax highlighting:

dom-to-image averages 340ms per capture and produces a 47KB PNG at 2x resolution. html2canvas averages 680ms and produces a 62KB PNG at the same resolution.

dom-to-image is faster and produces smaller files because it serializes the DOM node to an SVG first, then rasterizes. html2canvas rebuilds the DOM inside a canvas element, which is slower but handles some edge cases better—specifically CSS gradients in backgrounds and certain pseudo-elements.

I use dom-to-image for 95% of my snippets. The one case where I switch: snippets with complex background gradients that dom-to-image's SVG serialization occasionally chokes on.

The capture function I use

Here's the actual function I run from my browser console or bookmarklet when generating images:

function captureSnippet(selector, filename) {
  const node = document.querySelector(selector);
  domtoimage.toPng(node, {
    quality: 0.95,
    width: node.offsetWidth * 2,
    height: node.offsetHeight * 2,
    style: {
      transform: 'scale(2)',
      transformOrigin: 'top left'
    }
  })
  .then(function(dataUrl) {
    const link = document.createElement('a');
    link.download = filename + '.png';
    link.href = dataUrl;
    link.click();
  })
  .catch(function(error) {
    console.error('Capture failed:', error);
  });
}

Two things to notice: the scale factor of 2 doubles resolution for retina sharpness, and I'm capturing the inner container, not the wrapper. The wrapper exists for blog layout context during drafting; the inner container is what becomes the final image.

Handle edge cases before they handle you

Long lines and the 68-character rule

Code images can't scroll. If a line exceeds your container width, it either wraps awkwardly or gets clipped silently—both look unprofessional. I set a hard rule for my blog: no line in a code snippet image exceeds 68 characters. When writing tutorials, I format code examples to fit this constraint. If a line genuinely needs to be longer, I break it across multiple lines with continuation indentation.

This sounds restrictive until you realize GitHub's own code view wraps at roughly 120 characters in a full-width browser window. 68 characters in a 680px image at 14px monospace is actually comfortable, readable width. Readers aren't missing anything.

Special characters and emoji in comments

If your code contains emoji—increasingly common in modern JavaScript comments and log statements—test the capture before publishing. dom-to-image sometimes renders emoji as black-and-white glyphs or missing tofu boxes because the SVG serialization doesn't always inherit the system's color emoji font fallback. The fix is to explicitly declare an emoji font in your container's font stack: append "Segoe UI Emoji", "Apple Color Emoji", "Noto Color Emoji" to your monospace declaration. Test with a single emoji in a comment first. If it still rasterizes wrong, switch to html2canvas for that specific snippet—it handles color emoji reliably because it renders directly to canvas rather than going through SVG serialization.

Background gradients and the dom-to-image choke

I mentioned this earlier, but it deserves its own treatment because it's the most common reason a capture silently fails or produces a corrupted PNG. If your snippet container uses a CSS linear-gradient or radial-gradient as its background, dom-to-image's SVG serialization can produce a blank or partially rendered image. The symptom is usually a PNG that's the right dimensions but missing the background entirely, leaving transparent areas where you expected color.

The workaround I use: flatten gradients into a solid hex color for the container background, then layer any gradient effect as a separate absolutely-positioned div inside the wrapper. Capture the inner container (solid background) and let the gradient div exist only for on-page styling. If the gradient is essential to the image itself, switch to html2canvas for that capture. It's slower but it reconstructs gradients correctly.

Step 5: Automate the batch workflow

Once you've captured a few snippets manually, you'll want to batch-generate images for an entire tutorial. Opening the console and calling captureSnippet() ten times gets old fast. Here's the bookmarklet approach I use to generate every image in a post without touching the console:

Save a bookmark with this URL. When you're on a draft page with multiple snippet containers, click the bookmarklet once per snippet. It auto-increments the filename based on how many snippet-container elements exist on the page, so you get snippet-01.png, snippet-02.png, and so on without naming collisions.

The bookmarklet wraps the same capture function but adds a small delay between captures if you're generating multiple images in sequence. Without the delay, some browsers throttle rapid download triggers and silently skip files. A 300ms gap between clicks solves this reliably in Chrome, Firefox, and Safari.

Versioning your generated images

I append a short hash to every generated filename based on the code content inside the snippet. When I update a tutorial and regenerate images, the hash changes if the code changed and stays the same if it didn't. This makes it trivial to diff which images actually need re-uploading to my CDN versus which ones are unchanged. The hash is generated client-side using a simple string hash on the text content of the code element—no server needed.

The Bottom Line

A client-side code to image workflow eliminates a dependency I didn't need and a subscription I shouldn't have been paying. The five steps—pick a highlighter, lock the theme, build the container, choose the capture method, handle edge cases—cover everything from a one-off snippet to a 40-post tutorial archive. The entire toolchain lives in the browser: Prism.js for highlighting, a 47-line CSS file for theming, dom-to-image for capture, and a bookmarklet for batch generation. No build step, no API key, no per-image cost.

The constraints I've described—the 680px width, the 68-character line limit, the pixel-based font sizing, the explicit hex theme—aren't arbitrary. Each one solves a specific problem I hit in production. Adopt them or adjust them to your blog's layout, but don't skip the thinking behind them. The goal is consistency across every code image you publish, whether it's the first or the hundredth. Once your pipeline is locked, generating a code image takes about two seconds: paste code into the container, click the bookmarklet, drop the PNG into your post. That's the whole workflow.