# codesnap.nvim renders Neovim buffers as shareable code images

> codesnap.nvim is a Neovim plugin that turns a buffer into a styled image with syntax highlighting, optional breadcrumbs, line numbers, a watermark and a choice of themes, then copies it to the clipboard or saves it. The current major version delegates the rendering to a Rust library called CodeSnap, which is precompiled for five platforms and downloaded on first install.

**mistricky/codesnap.nvim** — 📸 Snapshot plugin with rich features that can make pretty code snapshots for Neovim

- Repository: https://github.com/mistricky/codesnap.nvim
- Stars: 922 · Forks: 41
- Language: Lua
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/mistricky-codesnap-nvim

## Why a screenshot instead of a paste

The pitch is in the repository description: a snapshot plugin with rich features that can make pretty code snapshots for Neovim.
The problem it solves is a small but real one. When you paste code into a chat window, a ticket or a document, you lose everything your editor was showing: the colour theme, the line numbers, the indentation structure, the file header that tells the reader what they are looking at. A screenshot carries all of that, and it looks deliberate rather than pasted.
The audience is Neovim users who share code often. That could be someone posting a snippet in a team chat, writing a blog post with code examples, preparing a bug report, or producing documentation. It is a presentation plugin, not a development tool, and it does not touch your workflow otherwise.
The plugin is written in Lua with the badges to prove it, Neovim 0.9+ and Made with Lua, and it also has a Written in Rust badge because the rendering itself is a native library rather than Lua.
The repository layout backs that up. There is a lua/ directory for the plugin code, a generator/ directory for the Rust renderer, a template/ directory for the image templates, a plugin/ directory, a flake.nix and flake.lock for Nix users, a makefile, stylua.toml for formatting the Lua, and a project.toml that appears to describe the project metadata.

## v2 moved the renderer into the Rust CodeSnap library

The v2 release is a rewrite of the screenshot generator, and the README says so plainly.
The most important change is that the screenshot generator was rewritten using CodeSnap, a separate Rust library, which makes CodeSnap.nvim faster and more stable than before.
The visible consequence is the removal of a build step. There is no need to set up a Rust environment to compile CodeSnap.nvim anymore, because a precompiled generator shared file is shipped for common platforms.
Those platforms are listed in the README.
```
x86_64-unknown-linux-gnu
aarch64-unknown-linux-gnu
x86_64-apple-darwin
aarch64-apple-darwin
windows-x86_64-msvc
```
The five targets cover Linux on Intel and ARM, macOS on Intel and Apple silicon, and Windows on x86_64. If you are on one of them, the plugin works out of the box.
The configuration follows the same library. The README states that the configuration is completely different between v1 and v2, and that it follows config.rs in CodeSnap, which means the same configuration works in both the CodeSnap CLI and CodeSnap.nvim. That is a deliberate design choice, and it is the reason the v1 to v2 upgrade is disruptive rather than incremental.

## The migration notes say your configuration will break

The README has a migration section, and it is unusually blunt about the breakage.
Upgrading from v0.x to v1 removed the CodeSnapPreviewOn command. If you want live preview, the README tells you to pin CodeSnap.nvim to version v0.0.11 to keep it. The opacity and preview_title config options were removed in v1.0.0, and editor_font_family was renamed to code_font_family.
The v1 architecture is different and performs better than v0.x, and it can generate screenshots directly without opening a browser, which is why the README recommends upgrading to v1.x.
Then v2 changes the configuration format entirely, as described above, and the build option was removed because the Rust code no longer needs to be compiled locally. The precompiled files are published on the releases page, and the plugin downloads the right one automatically the first time you install v2. The README asks for patience while that first download happens.
In other words, there are two separate breaks here, one at v1 and a larger one at v2. If you are on v1 today, read the configuration mapping in the CodeSnap repository before you upgrade, because the option names you have been using are not the option names v2 expects.

## Installing with Lazy.nvim and the Nix flake

Lazy.nvim is the recommended plugin manager, and the install spec is a single line.
```lua
{ "mistricky/codesnap.nvim", tag = "v2.0.5" }
```
The plugin manager itself does not matter, the README says you can still use another one you prefer. The Neovim requirement is 0.9.0 or later.
For Nix users there are two routes, and the README is clear about which is which. CodeSnap.nvim is already packaged in nixpkgs as vimPlugins.codesnap-nvim, which is the easiest way to install it. The flake in this repository is intended for when you would rather build from source, for example to track main, a fork or a specific commit.
The flake builds the plugin together with the generator library from source, so there is no runtime download and everything is reproducible, which is the point for a Home Manager setup.
```nix
{
  inputs.codesnap.url = "github:mistricky/codesnap.nvim";
}
```
The flake output is then used as a Home Manager plugin.
```nix
programs.neovim = {
  enable = true;
  plugins = [inputs.codesnap.packages.${pkgs.system}.default];
};
```
It also exposes packages.${system}.generator for the Rust cdylib alone, checks.${system}.plugin-loads, a headless Neovim smoke test that loads the plugin and native library and is run with nix flake check, and devShells.${system}.default, a Rust plus stylua dev shell for working on the generator.

## What the snapshot can contain

The feature list in the README is a set of composable decorations rather than a single rendering mode, and the sections map closely onto what a reader of a shared snippet wants to see.
There are two ways to consume a snapshot. It can be copied into the clipboard, including a separate recipe for Linux Wayland, or it can be saved to a file.
There is an ASCII snapshot mode, which is the interesting one for text-only destinations such as a terminal, a commit message body or a plain text channel.
A code block can be highlighted separately, so a snippet embedded in a larger document gets its own rendering rather than inheriting the editor theme.
Beyond that there are breadcrumbs, line numbers, a watermark, and theming: a custom code theme and a set of built in more beautiful themes. The breadcrumbs and the watermark are the two that go beyond what any editor theme would give you, since a breadcrumb path tells the reader where in the project the snippet came from and a watermark identifies the author or the environment.
The README section on Consume Snapshot covers the clipboard and save paths, and each of the remaining sections documents one decoration, so the plugin reads as a set of small independent features rather than a single pipeline with switches.

## Gaps in the documentation and a partially tested Windows path

Two honest limitations stand out.
The first is that the Keymappings section of the README consists of the single word TODO. The plugin therefore has commands, listed in their own section of the README, but the documented keymap story is not written. If you rely on a specific key to trigger a snapshot, expect to read the source or bind the command yourself.
The second is Windows. The README announces Windows support in the v2 migration notes and adds that it is less tested than it could be, asking that issues be filed if there are problems. The precompiled binary list includes windows-x86_64-msvc, so the artifact exists, but the support is explicitly younger than the macOS and Linux paths.
A third consideration is the runtime download. On the first install of v2 the plugin fetches the precompiled generator for your platform, which the README notes may take a few seconds. In a locked down environment, or on a machine without outbound network access, that download is a problem, which is exactly the case the Nix flake is designed to solve by building the generator from source instead.
Finally, the badge in the README declares support for Neovim 0.9+, so a version of Neovim older than 0.9.0 is out of scope entirely.

## MIT licensed, released steadily, with a conventional contributor workflow

The licence field on the repository says MIT, and there is a LICENSE file at the root of the tree. The README has a License section and a Contribution section, and the repository carries a CONTRIBUTORS.svg, a CODE_OF_CONDUCT.md and a commitlint.config.js, which together with the GitHub workflows for release and lint tells you this project has a conventional contributor workflow rather than a single maintainer pushing commits.
The release cadence is regular. v2.1.1 was released on 2026-09-14, v2.1.0 on 2026-08-10 and v2.0.5 on 2026-06-04. The last push was on 2026-09-14, the same day as the v2.1.1 tag, and the repository is not archived.
That consistency is worth something for a plugin that downloads a native library, because the mapping between a plugin version and a precompiled artifact is the kind of detail that drifts. The v2 line has moved from 2.0.5 through 2.1.0 to 2.1.1 in a few months, and the Lazy.nvim spec in the README still pins tag = v2.0.5, so the pinned tag in the documentation is older than the newest release.
For an evaluation, the practical checks are these: confirm your Neovim version is 0.9 or newer, confirm your platform is one of the five with a precompiled generator, and read the configuration mapping before moving from v1 to v2, because that is where your setup will actually change.

## Conclusion

Adopt codesnap.nvim when you regularly share code from Neovim, for example in a chat message or a pull request comment, and you want the output to look like an editor rather than a pasted monospace block. Do not adopt it as a general image tool, since it targets code buffers specifically, and do not expect a stable configuration across major versions, because v2 changed the configuration format completely. Before upgrading from v1, note that the build option was removed in v2, so a Rust toolchain is no longer needed on your machine.

## FAQ

### How do I install codesnap.nvim?

The README recommends Lazy.nvim with the spec { "mistricky/codesnap.nvim", tag = "v2.0.5" }, and any other plugin manager works too. Neovim 0.9.0 or later is required. On the first install of v2 the plugin downloads the precompiled generator for your platform automatically.

### Do I need Rust to use codesnap.nvim?

Not since v2. The screenshot generator was rewritten using the Rust CodeSnap library and precompiled generator files are shipped for x86_64 and aarch64 Linux, x86_64 and aarch64 macOS and windows-x86_64-msvc, so no Rust environment is needed to install the plugin.

### What changed between codesnap.nvim v1 and v2?

The configuration is completely different between v1 and v2 and follows config.rs in CodeSnap, so the same configuration works in the CodeSnap CLI and in the plugin. The build option was also removed in v2 because the Rust code no longer has to be compiled locally.

### Is codesnap.nvim available through nixpkgs?

Yes. The README says CodeSnap.nvim is already packaged in nixpkgs as vimPlugins.codesnap-nvim, which is the easiest route for Nix users. The flake in this repository is for building from source, which avoids the runtime download of a precompiled generator.

### Does codesnap.nvim work on Windows?

The v2 migration notes announce Windows support and include a precompiled windows-x86_64-msvc generator, but the README says the support is less tested than it could be and asks that any problems be reported as issues.

## Sources

- [Issues](https://github.com/mistricky/codesnap.nvim/issues)
- [License: MIT](https://github.com/mistricky/codesnap.nvim/blob/main/LICENSE)
- [mistricky/codesnap.nvim on GitHub](https://github.com/mistricky/codesnap.nvim)
- [README](https://github.com/mistricky/codesnap.nvim/blob/main/README.md)
- [Releases](https://github.com/mistricky/codesnap.nvim/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mistricky-codesnap-nvim