CodeSnap: code screenshots rendered by a graphics engine, not a browser

Rendering without a browser is the whole idea

The README states the design decision plainly: CodeSnap is a pure Rust tool for generating code snapshots that directly uses a graphics engine to generate them, which means the entire process is a matter of computation and rendering, without needing the network or something like a browser-based rendering solution. That is a real operational difference, not a detail. The common alternative for producing a syntax-highlighted code image is to run a headless browser and screenshot it, which drags in a browser runtime, a font loading strategy, a rendering wait and often a network fetch for a theme. CodeSnap removes all of that by doing the drawing itself, and the consequence is that the output is deterministic and cheap to produce in CI. The audience is anyone who needs attractive code images as a build artefact, a README asset or a documentation figure, and the project backs it with a CLI, a library, and editor integrations listed among the topics for Neovim, VS Code and Zed.

Syntect gives you every Sublime Text theme

The theming story is the part that makes the output look like the tool people expect. CodeSnap uses Syntect as its syntax highlighter, and Syntect uses Sublime Text syntax definitions, which means you can use any theme that Sublime Text supports rather than being limited to the ones the project ships. The feature list also mentions a line number option, described as genuinely useful if someone wants to know the position of the code snippet, a watermark to make a snapshot more personalised, a scale factor so you can control the size of the output, and a background you can customise with a solid colour or a gradient. The default scale is treble size, which the README says is to ensure the quality of the snapshot, so the tool defaults to oversampling and lets you bring it down. Output formats are wide too: PNG, SVG, HTML, and an ASCII code snapshot for anyone who wants the terminal aesthetic.

The CLI, and four ways to install it

The getting started section gives two routes, the CLI and the library, and the CLI has installation instructions for four platforms, each behind a collapsed section in the README. On Arch Linux the package is in the extra repository.

pacman -S codesnap

On Nix and NixOS it is in nixpkgs.

nix-env -i codesnap

With Cargo you install the CLI crate.

cargo install codesnap-cli

There is also a precompiled binary path through cargo-binstall, which the README presents as an alternative to building from source.

cargo binstall codesnap-cli

And Homebrew has its own formula.

brew install codesnap

The crate names differ from the product name in a way worth noting, since the binary is codesnap while the CLI crate is codesnap-cli and the library crate is codesnap.

Generating your first snapshot from the command line

Running the tool is a single command with an input file and an output path, and the help flag is the reference for everything else.

# Run codesnap to generate code snapshot by providing code file
codesnap -f ./code_snippet.hs -o "./output.png"

# Run codesnap --help to see more information
codesnap -h

The clipboard is part of the interface too, since the feature list says CodeSnap can copy a snapshot to the clipboard directly, or read a code snippet from the clipboard to generate snapshots. That second direction is the one that matters for editor plugins, because a plugin can select code and hand it to the tool without touching the filesystem. The examples live in the cli/examples directory of the repository, and the README links to them.

The library API, and a builder that mirrors the config file

For use inside your own project, the library is added with Cargo.

cargo add codesnap

The API is builder based. You build a Content value from a CodeBuilder, hand it to a CodeSnap builder, and create the snapshot.

let code_content = Content::Code(
  CodeBuilder::from_t
  .content(r#"print "Hello, World!""#)
  .language("python")
  .build()?,
);

let snapshot = CodeSnap::from_default_theme()
  .content(code_content)
  .build()?
  .create_snapshot()?;

// Copy the snapshot data to the clipboard
snapshot.raw_data()?.copy()

The interesting detail is that from_default_theme and from_config are two entry points into the same builder, so the JSON config file and the programmatic API converge on one rendering path rather than two implementations that can drift. The workspace layout reinforces that. The Cargo.toml declares a workspace with resolver 2 and four members, cli, core, wasm and xtask, where core holds the rendering logic, cli the command line front end, wasm a web assembly target, and xtask the task runner. The presence of a wasm member is what makes the editor plugins possible, since a Neovim, VS Code or Zed extension can call into the same renderer without linking a native binary.

Configuration is JSON, and the precedence order is documented

Codesnap can receive a JSON config as input, and the config is used to customise the snapshot, with theme, background and watermark among the things it covers. The shipped default config is worth reading in full because it shows the whole visual vocabulary. There is a window block with a mac style window bar, a shadow with a radius and an alpha colour, margins in pixels, a border with width and colour, a title config with its own colour and font family, and a corner radius. There is a code config with a font family and a breadcrumbs block that can be enabled, with its own separator, colour and font. There is a watermark block and a background block defined as a gradient with a start point, an end point using the literal max, and a list of colour stops with positions. The README also documents the precedence rule for line number colour, scale factor, window border, breadcrumbs and title: built-in defaults, then JSON config values, then explicitly provided CLI arguments, and omitting a CLI option preserves the config value. Two feature flags, --has-breadcrumbs and --has-border, accept explicit booleans as well, so they can be turned off from the command line as well as on.

Where CodeSnap is the wrong choice

Two cases stand out. The first is when you need pixel-identical output to what a browser produces, because rendering through a graphics engine is a different rasterisation path with different font hinting and antialiasing, and the whole point of the project is to avoid the browser. If your pipeline already has a headless browser in it, CodeSnap is a replacement for that dependency rather than an addition, and the migration is a rendering difference you have to accept. The second is the configuration verbosity. The JSON config is long, it names specific fonts, and the defaults depend on a bundled font set, so a team with a strict brand palette will spend time on that file rather than on the tool. The alternative worth naming is the many web services and editor extensions that do the same job with a browser or a remote renderer, which trade local execution for a smaller setup. The honest comparison is that CodeSnap wins on being self-contained and fast, and loses on output fidelity and on the fact that its config is a design document rather than a flag. The project is MIT licensed, the newest release is v0.14.0 from 2026-10-08, and the last push to the repository was on 2026-10-13, so it is actively developed at a fast pace.

Editorial conclusion

Adopt CodeSnap if you publish code snippets in README files, blog posts or issue reports and want images that are not produced by a headless browser, because a graphics engine approach is faster and does not need a browser installed. Do not adopt it if you need a full browser rendering pipeline, since that is exactly what it is built to avoid, and note that its configuration is JSON and somewhat verbose. Verify first which themes and fonts you have available, because the default configuration references specific bundled fonts, and check how the CLI and the library differ in their default output.

Frequently asked questions

Official sources

1. codesnap-rs/codesnap on GitHub
2. License: MIT
3. Project website
4. README
5. Releases