Code Screenshot Beautifier

Why you screenshot code instead of pasting it

Pasting code as text is almost always correct — it's copyable, diff-able and accessible. So an image of code only earns its place where text can't go, and there are a surprising number of those places. Social posts (X, LinkedIn, Mastodon) strip indentation and mangle angle brackets, so a snippet pasted as text arrives unreadable; an image preserves the exact formatting and the syntax colours that make structure legible at a glance. Slide decks, conference talks, course thumbnails, README hero images, and changelog announcements all want a self-contained visual rather than a code block that depends on the platform's renderer. The honest test: if the reader needs to copy the code, give them text; if they need to look at it, give them an image.

Syntax highlighting is the whole point. The colours aren't decoration — they encode meaning, separating keywords from strings from comments so the eye parses the shape of the code before reading a single token. A flat monochrome paste throws that away. Highlighting here is computed locally in your browser from the language grammar, so even private or unreleased code never leaves the device to be prettified.

Theme, padding and the settings that read well

• Language — set it explicitly rather than trusting auto-detection on short snippets. Five lines of JSON and five lines of JavaScript can look identical to a guesser; the wrong grammar gives you wrong colours.
• Theme — a dark theme reads best on social and in dark-mode feeds, but a light theme prints better and embeds more cleanly in light documentation. Match the destination, not your editor's habit.
• Padding — generous background padding around the code is what makes these images look intentional rather than cropped. It also gives the window shadow room to breathe.
• Window chrome — the little traffic-light dots signal 'this is code' instantly and frame the snippet. Skip them only when you'll place the image inside another frame already.
• Line length — keep lines short. The number-one cause of an ugly code image is a 140-character line that forces a tiny font or an awkwardly wide canvas. Refactor or wrap before you capture.

Versus Carbon and ray.so — and what an image can't do

Carbon and ray.so popularised the beautiful-code-image genre and they're excellent. The substantive difference here is where the work happens: those are server-rendered, so your snippet is posted to someone else's backend to be turned into a picture. For throwaway public code that's fine; for anything proprietary, a config with a hostname in it, or a snippet from an unreleased product, sending it off-box is a needless leak. This tool renders the highlight and the canvas entirely in your browser, so the snippet stays with you.

Two limits worth stating plainly. An image of code is not accessible — screen readers can't read it, and nobody can copy it — so in real documentation you should pair the image with the actual text in a code block, using the picture for the eye and the block for everything else. And these images are for snippets, not files: a 200-line source file shrunk to fit becomes an unreadable postage stamp. Show the ten lines that matter. When you want the snippet to sit inside a faked browser or app for a landing page, hand it to the window mockup or wrap a whole UI screenshot in a device frame instead.