pixel-paint is a 32x32 sprite editor in a single static page

A whole editor in index.html and a js directory

Pixel Paint is described as an art tool for making 32x32 sprites, and the repository is built in vanilla JavaScript with the stated goal of being 100% vanilla javascript. The top level listing makes the shape of it clear: an index.html, a js/ directory, a main.css, a LICENSE.md, and image and gif directories holding the artwork and the animated demonstrations. There is no package.json, no lockfile, no bundler configuration and no build directory, and there are no GitHub releases. That absence is the main design fact. The tool runs by opening a page, which means you can read the entire implementation in one sitting, and you can host it anywhere that serves static files, including from a USB stick on a machine with no toolchain at all. The site is published at kully.github.io/pixel-paint, and the project topics list javascript, nes, pixel-art, sprites, vanilla-javascript and website, which tells you the intended output is retro console sprite work rather than general illustration.

Opening the tool, and why there is nothing to install

The documentation does not describe an installation step, and that is because there is nothing to install. The repository is a static site: an index.html, a js/ directory and a main.css, with no package manifest, no dependency list and no build step, so the way to run it is to serve those files and open the page. The published version lives at kully.github.io/pixel-paint, which is the fastest route to a working tool. If you want your own copy, cloning the repository and opening the index.html from disk is enough for the drawing tools, and the origin directory is not published as an installable package. The only unusual requirement is that the hotkeys assume a desktop keyboard, since five of the tools are single letter keys and two more use modifier combinations, so the tool is aimed at a machine with a keyboard rather than a tablet.

The tool set, and what each hotkey does

The feature list is short enough to enumerate and the hotkey table is the real documentation, because every tool has a single key. Pencil mode is P, bucket mode is B, eraser mode is E, colourpicker mode is V, and selection mode is S. Copying a selection is not a key but a gesture, ALT+click and drag. Deleting the selected area is Del or Backspace, and removing the selection is Esc. The grid toggle is G, undo is Z, redo is X, and colour swap is C. Two of these deserve comment. The ALT+click and drag copy gesture is unusual for a pixel editor, where copy is usually a menu item, and it means the mouse is doing double duty for both selection and duplication, which is efficient on a small canvas and slightly awkward if you are used to a selection marquee in a conventional image editor. The colour swap key is the other one, because swapping a pixel to the previous colour in one keystroke is the kind of detail that shows the tool was made by someone who draws sprites regularly.

Undo and redo as a stack of canvas states

The README states that undo and redo are implemented with a stack of canvas states, and that phrasing is worth reading carefully because it describes an approach with a known cost. Storing canvas states means each history entry keeps a copy of the drawing surface rather than a list of edit operations. The result is a straightforward implementation where undo is a matter of popping a stored image back onto the canvas, and it has the pleasant property that every operation is undoable by construction, including the ones you might not have thought to record. The cost is memory, since each state is a full canvas rather than a diff, and that cost grows with the size of the canvas and the number of steps you keep. At 32x32 that is small enough to be irrelevant, which is one of the places where the fixed resolution pays off. It also means the history is bounded by whatever the implementation caps it at, and the README does not document a maximum number of states or a way to clear the history, so for a long session the practical question is whether the stack keeps growing.

A fixed NES and Game Boy palette, not a free colour picker

The palette comes from the NES and the Game Boy, and the colour picker tool draws from that palette rather than from an arbitrary RGB space. That is a design decision with real consequences in both directions. On the useful side, it guarantees that anything you draw in the tool will display correctly on the hardware it is meant for, because there is no way to pick a colour the console cannot show, and a palette constrained to a few dozen entries makes deliberate colour choice easier rather than harder. On the limiting side, it means the tool cannot be used for a project with its own colour scheme without leaving it, and that any design decision that depends on a subtle gradient is out of scope. For sprite work at this scale, restricted palettes are usually a help, since the constraint is the aesthetic anyway. The tool also includes original 32x32 cursors and button icons of its own, which is a nice touch: the interface is drawn in the same visual language as the artwork it is for.

Export is a PNG, and there is no project format

The export path is the clearest signal about the scope of the tool. The feature list says you can save your pixel art to PNG, and that is the whole of the persistence story. There is no project file, no layers, no frame timeline and no palette editor, because there is nothing to persist beyond a single image. This is the right design for the stated purpose, where a 32x32 sprite is a single image and a PNG is what the game engine or the tile editor downstream will want. It is also the reason the tool will not scale past its niche. A sprite that animates needs a sequence of images and a naming scheme, a character with variations needs layers, and a project with a dozen sprites needs some way to keep them together and to keep the palette consistent across them. None of that is here, and for anything beyond a handful of individual frames, you need a different tool or a real pixel art editor with a file format.

Where the tool stops, and what a real editor gives you

The honest limitations are the ones a professional pixel art editor exists to solve. There is no selection of a region to move, no copy and paste of a block into another position, no rotation or flip, no tiling support for repeating backgrounds, no onion skinning for animation, and no configurable canvas size. The ALT+click and drag gesture copies a selection, but the README describes no way to then move that selection around, so the copy gesture is closer to stamping a pattern than to a clipboard workflow. If your work needs any of those, the practical alternative is a full pixel art editor or a general image editor, and the difference in approach is exactly that those tools keep an editable document with layers and frames while this one keeps a canvas and a PNG. The case for pixel-paint instead is speed of start-up and readability of the code. Opening a page and drawing immediately, with a codebase small enough to read, has value for a beginner learning how a drawing tool is put together, and for a hobbyist who wants to sketch a sprite in a browser tab on a locked-down machine.

Contribution and the shape of the project

The contributing section is unusually warm for a small tool, and it tells you something about how the project is run. The author writes that one of the joys of posting the project on GitHub is to get people excited and wanting to contribute, invites pull requests for any changes the app could benefit from or something a person would like to use, and points at the issue tracker for ideas and comments, closing with an invitation to have fun and be creative. The licence is MIT, and the LICENSE.md file at the root is the licence text. With no build system, no dependency file and no test suite in the listing, the barrier to a first contribution is low, and so is the ceiling on what a contribution can look like, since a change is a change to a canvas drawing tool in plain JavaScript rather than a change to a pipeline. The README also carries animated demonstrations of the selection and copy behaviour, which is a better way to understand the ALT+click gesture than the sentence describing it.

Editorial conclusion

Adopt pixel-paint if you are making sprites for an NES or Game Boy style project and you want a drawing tool you can read in one sitting, because the whole thing is index.html, a js directory and a stylesheet with no build step and no dependencies. Do not adopt it for larger tiles, for animation with multiple frames, or for any project that needs layered files, since the canvas size is fixed at 32x32 and the feature list stops at a single canvas with a PNG export. Verify two things before you start drawing: that your target really is 32x32, because that number is baked into the tool rather than a setting, and that the palette you need is one of the NES or Game Boy colours, since the palette comes from those two systems rather than being free-form. The practical first step is to open the hosted page and draw something in the wrong colours deliberately, because switching a pixel with the colour picker is the fastest way to see how the tool behaves before you commit to a sprite.

Frequently asked questions

Official sources

1. Issues
2. Kully/pixel-paint on GitHub
3. License: MIT
4. Project website
5. README