# SpineViewer: opening Spine skeletons, exporting them, and pinning them to your desktop

> SpineViewer is a C# desktop tool for the Spine 2D animation format that does three jobs in one application: it previews skeleton files and their animation tracks, exports them as still frames, GIFs, videos or layered PSD files, and doubles as a live desktop wallpaper driven by the same preview. It reads Spine versions from 2.1.x up to 4.2.x, and the export path leans on ffmpeg.

**ww-rm/SpineViewer** — 一个简单好用的 spine 文件查看&导出&壁纸工具。A simple and easy-to-use spine file viewer & exporter & wallpaper.

- Repository: https://github.com/ww-rm/SpineViewer
- Website: https://ww-rm.top/posts/2025/03/04/spineviewer/
- Stars: 561 · Forks: 55
- Language: C#
- License: not declared
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/ww-rm-spineviewer

## What the tool does in three jobs

SpineViewer is described as a Spine file viewer, exporter and wallpaper program, and the Chinese title puts it the same way: a Spine file viewing and exporting program that is also a dynamic wallpaper program supporting Spine.

The three jobs share one engine, which is the reason the tool exists at all. A Spine file is a skeleton with bones, slots, attachments, animation tracks and skins, and to render one correctly you need the runtime, the atlas and the texture. If you already have a viewer that renders it, you already have everything needed to export it, and if you can export it, you have everything needed to animate it on your desktop.

So the same preview canvas that you scrub through to inspect an animation is the canvas that gets exported, and the same canvas is what gets projected onto the desktop as a wallpaper. The feature list makes the breadth explicit: support for multiple Spine file versions, list-style multi-skeleton viewing with render layer management, importing with no overlapping arrangement, focus and centre on the selected model, multi-track animation and skin group settings, debug rendering, time speed settings for the view, the model and the track, per-track alpha blending parameters, export to single frame, animated image or video files, export to multi-layer PSD, custom export through FFmpeg, support for texture image formats other than PNG, and running as a persistent wallpaper that starts with the system.

The primary language is C#, the licence field is not a standard identifier, the default branch is main, and the homepage is a project post on the author's site. The recent releases are v0.16.34 from 2026-09-17, v0.16.33 from 2026-09-02 and v0.16.32 from 2026-08-20, and the last push was on 2026-09-27 with the project not archived.

The version numbering matters more here than in most projects, because Spine is a commercial format with a long history of file format revisions. The supported range is 2.1.x and 3.4.x through 4.2.x, which is stated in the feature list and is a specific claim about which revisions the loader can read.

## Installing it, and the two runtime options

Installation is a download from the Releases page, and the runtime requirement is stated in one line: the software needs the .NET desktop runtime 8.0.x installed.

There is a second option for people who do not want to install a runtime. A package with the SelfContained suffix in its name can be downloaded and runs independently, which is the .NET self-contained deployment model where the framework travels with the application.

So the choice is between a small download that needs a runtime you probably already have if you develop on Windows, and a larger one that needs nothing. For a tool that many people will install once and forget, the self-contained package is the friendlier option, and the fact that both are offered is a sign the author thought about the non-developer case.

The export path has one extra dependency. Exporting to animated image and video formats requires the ffmpeg command line tool to be installed locally and added to the environment variable path. The README links the FFmpeg Windows downloads page and also a direct archive of the latest full release.

That is a sensible division of labour rather than an inconvenience. Bundling ffmpeg would make the download large and would freeze a version of ffmpeg that goes out of date, and the ffmpeg invocation is only needed for the video and animated output paths, not for viewing, not for single frame export and not for the wallpaper. So a user who only wants to look at skeletons needs none of it.

The interface language is a separate small decision and it is documented clearly. The project supports three interface languages, listed as ZH for Chinese, EN for English and JA for Japanese, and you change it through the window menu under the file entry, then preferences, then language, and confirm the change. The badge in the header says the same thing: Chinese, English, Japanese. A tool built for a Chinese-speaking audience with an English interface option is a reasonable default, and a Japanese option suggests the author has users who need it.

## The three panels, and how the canvas behaves

The layout description is precise and worth following, because a tool like this is only usable if you can find things.

The program is broadly a left-right layout, with a function panel on the left and the canvas on the right. The left side has three sub-panels. The Model panel records the list of models that have been imported and rendered, and it is where you set the model rendering parameters and the render order, along with model-related functions. The Browse panel is used to preview the contents of a chosen folder without actually importing the files into the program, and it is where you can generate webp format preview images for models or import the selected ones. And the Canvas panel sets the parameters of the preview area on the right.

So Browse is a file browser that does not mutate state, and Model is the loaded set. That separation is the thing that makes it possible to look at a folder of two hundred skeletons before deciding which to import, and the webp preview generation is a small thoughtful addition, since a contact sheet of thumbnails is how you decide what to open.

Almost every button, label and input field can produce a help text on hover, which is a low-cost approach to discoverability that many desktop tools skip.

The canvas itself supports direct manipulation, and the mouse bindings are listed. Left click selects and drags a model, and holding Ctrl enables multiple selection, which is linked to the selection in the list on the left. Right click drags the whole canvas. The scroll wheel zooms the view, and holding Ctrl scales the selected models in bulk, while Shift toggles the zoom step. There is a render-selected-only mode, in which the preview contains only the selected models and the selection can then only be changed from the list.

That last mode is worth noting, because it is the one you would use when compositing: a clean canvas with exactly the models you want in the shot, and no accidental drag of a model that was not meant to be included.

Below the canvas there are buttons for adjusting the view time, and the documentation describes it as a simple player.

## The export parameters, and the one that changes everything

Export is done from the model list: right click a selected model and the menu offers export operations for the selection. The document names three key parameters, and the third one is the interesting one.

The output folder. This parameter is optional in some cases. When it is not given, the output is written into each model's own model folder, and when it is given, all the output products are written to the folder you provided.

Export single. By default each model is exported independently, which means a batch operation over the model list. If you choose to export only as one, then all the models being exported are rendered on the same canvas, and there is only one output product.

So the second parameter is a layout decision, not a batching decision. Exporting a folder of characters as individual files and exporting them as one composed image are two different jobs, and this is the flag that distinguishes them.

The third is auto resolution. In this mode the canvas resolution and viewport parameters are ignored, and the resolution of the exported product matches the actual size of the exported content, and for an animated image or video it matches the size needed to show the whole animation.

That is a small feature with a large effect on output quality. If you export a single character frame at the preview window size, you get a canvas-sized image with the character somewhere in it. If you export with auto resolution, you get an image cropped to the character. For a workflow where exported frames are composited into something else, the difference is between a usable asset and a manual crop step.

The export formats are listed separately and cover the cases people actually need: single frame, animated image, video file, multi-layer PSD, and custom export through FFmpeg. The PSD multi-layer option is the one that stands out, because a layered PSD is a production file rather than a picture, and producing one from a Spine skeleton lets you keep the parts separated for editing in a painting application.

Export is also where the FFmpeg dependency earns its place, since the custom export path and the video output both go through it.

## The wallpaper mode and the command line tool

The dynamic wallpaper works by projecting to the desktop, and the content currently on the preview canvas can be projected to the desktop in real time.

The controls are in the application preferences or in the tray icon right-click menu, where you enable or disable the desktop projection. Once the model and canvas parameters are adjusted, you can save the current parameters as a workspace file, which makes it convenient to restore that configuration later.

There is also an autostart option for the wallpaper to run persistently at boot, and you set which workspace file to load after startup. So the workflow is: arrange the scene in the preview, save it as a workspace, and have it come back on every login.

The command line tool is a separate binary, SpineViewerCLI, and it is described as a pure command line tool that currently supports a few simple operations on a single model, such as querying parameter values and exporting. The Release page provides binaries for Windows and Linux.

```bash
$ SpineViewerCLI -h
Description:
  Root Command

Usage:
  SpineViewerCLI [command] [options]

Options:
  -q, --quiet     Suppress console logging (quiet mode).
  -?, -h, --help  Show help and usage information
  --version       Show version information

Commands:
  query <skel>    Query information of single model
  preview <skel>  Preview a model
  export <skel>   Export single model
```
```

So the three commands are query for information about a single skeleton, preview for a model, and export for a single model. The flags are the standard set for a .NET command line tool built with a library that follows the System.CommandLine conventions: quiet mode to suppress console logging, help, and version.

The presence of a CLI is what makes the tool usable in a pipeline rather than only by hand. Rendering a batch of game assets from a folder of skeletons is exactly the kind of job you want to script, and a viewer with no command line would leave you clicking through a dialog for each file.

The final section points to the wiki for more detailed usage instructions, and to the issue tracker for problems and bugs. The acknowledgements list the spine-runtimes project from Esoteric Software, which is the official runtime the tool builds on, and then a set of libraries that map neatly onto the feature set: SFML.Net for rendering, FFMpegCore for the video path, HandyControl for the desktop UI, NLog for logging, SkiaSharp for 2D drawing, and Spectre.Console for the command line output.

## How to evaluate it, and what to check first

There are four things to consider.

First, whether your Spine files are in a version the loader reads. The supported range is 2.1.x and 3.4.x through 4.2.x, which covers most of the format's life, and if you are working with files from a newer revision or from the 2.x-to-3.x gap the tool may not open them. This is the first thing to verify, because everything else depends on it.

Second, what you actually need from it. If you are an artist checking a rig, the viewer alone may be enough and you can skip the ffmpeg dependency entirely. If you are extracting assets for a game or a video, the export side is the reason to use it, and then the PSD layer export and the auto resolution mode are the two features worth checking against your workflow.

Third, the export layout decision. The default is one file per model, and the alternative renders all selected models on one canvas, so if your pipeline expects either behaviour you should set it deliberately rather than discovering it after a batch run.

Fourth, the runtime and platform picture. It is a Windows-first desktop application built on WPF, with a .NET 8 desktop runtime requirement, a self-contained package if you would rather not install one, and a CLI for Windows and Linux. The project directory listing includes a NLog.Windows.Wpf/ module and a SpineViewer/ directory, which is consistent with the Windows focus. If you are on macOS, the CLI binaries are not offered for that platform in the documented releases, so check before planning around it.

What you get is a tool that does the unglamorous work of looking at a proprietary binary format without a licence to the official editor, and does the export as well. The wallpaper mode is the odd one out, but it is the same preview canvas projected to the desktop, which is the kind of feature that only makes sense if the two halves share a renderer. The version number at 0.16.x with releases every few weeks suggests active work on the format compatibility, which is the part that matters most to you over time.

## Conclusion

Adopt SpineViewer if you work with Spine 2D animation files and need to inspect rigs, extract assets or run an animation as a desktop wallpaper, and if your files are within the supported 2.1.x and 3.4.x to 4.2.x range. Do not adopt it expecting a cross-platform tool, because the application is a WPF desktop program and the documented CLI binaries cover Windows and Linux only. Before you commit, check your Spine file versions first since the loader range excludes some revisions, decide whether to take the self-contained package or install the .NET 8 desktop runtime, and set the export layout and auto resolution deliberately, because the default writes one file per model at the preview resolution and the useful combination for compositing is a single canvas with the output sized to the content.

## FAQ

### What is SpineViewer?

It is a C# desktop tool for the Spine 2D animation format that previews skeleton files, exports them, and runs as a live desktop wallpaper. The primary language is C#, the homepage is a project post on the author's site, and the recent releases are v0.16.34 from 2026-09-17, v0.16.33 from 2026-09-02 and v0.16.32 from 2026-08-20.

### Which Spine file versions does SpineViewer support?

The feature list states support for multiple Spine file versions, specifically 2.1.x and 3.4.x through 4.2.x. It also supports texture image formats other than PNG and per-track alpha blending parameters.

### How do I install SpineViewer?

Download the archive from the Releases page. The software needs the .NET desktop runtime 8.0.x, or you can download a package with the SelfContained suffix in the name and run it independently. Exporting to animated image and video formats additionally requires the ffmpeg command line tool installed locally and on the environment variable path.

### What export options does SpineViewer offer?

Export can produce a single frame, an animated image, a video file, a multi-layer PSD, and custom output through FFmpeg. Three key parameters govern it: the output folder, whether to export each model separately or all selected models rendered onto one canvas, and auto resolution, which ignores the preview resolution so the output matches the actual size of the exported content.

### What can the SpineViewerCLI command line tool do?

It is a pure command line tool for simple operations on a single model, with three commands: query for information of a single model, preview for a model, and export for a single model. It has quiet, help and version flags, and the Release page provides binaries for Windows and Linux.

## Sources

- [Issues](https://github.com/ww-rm/SpineViewer/issues)
- [Project website](https://ww-rm.top/posts/2025/03/04/spineviewer/)
- [README](https://github.com/ww-rm/SpineViewer/blob/main/README.md)
- [Releases](https://github.com/ww-rm/SpineViewer/releases)
- [ww-rm/SpineViewer on GitHub](https://github.com/ww-rm/SpineViewer)

---

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