Photoshop to Spine script not working? Three ways around it
If the PhotoshopToSpine script stopped working after a Photoshop update, you are not alone — and your layered art is not stuck. Below: what the script does, where the breakage is tracked, and three ways to get the same layers into Spine that do not depend on the script at all — starting with the one built into Spine itself.
What the script does
PhotoshopToSpine is the official export script from Esoteric Software, published in the spine-scripts repository under the BSD-3-Clause license. It runs inside Photoshop, saves every layer as a PNG and writes a JSON file with the layer positions and draw order, which the Spine editor then imports. Tags in layer names such as [bone], [slot] and [ignore] control how layers map to bones and slots. Rigging and animation are still done by hand in the editor afterwards.
The Photoshop 2026 report
The script failing in Photoshop 2026 is reported in the Spine editor issue tracker: EsotericSoftware/spine-editor, issue 944. We do not maintain the script and cannot tell you what has changed since the report — check the issue for the current status before trying anything else.
Workaround 1: let Spine import the PSD itself
Since version 4.2 the Spine editor reads PSD files directly: in Import Data, choose the PSD instead of the script's JSON. Photoshop is not involved at all, so a Photoshop update cannot break it, and the tags from the PhotoshopToSpine script are supported — a file already marked up for the script imports as is. See the PSD import documentation and the announcement on the Spine forum.
If you have Spine 4.2 or later, this is the first thing to try. Rigging and animation are still done by hand in the editor afterwards — the two workarounds below are for doing that part with Riggy instead.
Workaround 2: export layers as canvas-size PNGs
Export each layer as its own PNG at the full size of the canvas, without trimming. The empty transparent area around each part is exactly what records where it sits, so nothing about the layout is lost.
Riggy builds a rig from such a set directly: one part and one bone per image, the relative positions kept from the transparent margins, each image trimmed to its pixels. The draw order follows the numbers in the file names — the lowest number is drawn at the bottom, and part2 comes before part10. Trimmed images of different sizes also load, but their positions are not written anywhere, so they start in the centre and the AI arranges them.
Workaround 3: upload the PSD to Riggy
Riggy reads the PSD file itself, without Photoshop: layers and groups, layer and group masks, clipping groups, opacity and the same [bone] tags the script uses, so a file already marked up for PhotoshopToSpine reads as is. The result is plain Spine 4.2 data — skeleton.json, an atlas and its page — and the animations come from a sentence instead of the editor. How Riggy reads a PSD covers the details and what does not carry over.
Before you ship
Whichever way the data is made, the official Spine runtimes that play it in a game are licensed by Esoteric Software. Spine runtime licensing explains what that means for exported files.