I Built a Browser-Based Sprite Toolchain (Video → Atlas, Packing, Compression, No Backend)
Most sprite workflows are fragmented.
You end up using one tool to extract frames, another to pack atlases, another to compress, and something else to convert formats. On top of that, most tools require uploads or paid features.
I wanted a single pipeline that handled everything, without a backend.
So I built a browser-based sprite toolchain that runs entirely client-side and didnt charge an arm and a leg
What It Does
The tool covers the full sprite workflow:
Input and Conversion
Atlas and Packing
Editing and Utilities
Output and Optimization
The Stack
This is essentially a full asset pipeline implemented in the browser.
Video and GIF Processing
For video and GIF decoding, the system uses:
FFmpeg.wasm handles:
Canvas is used for:
Frame Extraction
Frames are extracted either via:
Key considerations:
Image Processing Pipeline
Once frames are extracted:
This stage is optimized to:
Atlas Packing
Packing is handled using multiple strategies:
MaxRects is used for:
Additional features:
Duplicate Detection
To reduce atlas size:
This enables:
Optimization Layer
Several optimization passes are applied:
These are especially useful for:
Export System
Exports are designed to plug directly into engines and frameworks:
Supported formats:
Output includes:
Performance Strategy
Running entirely in the browser introduces constraints:
To handle this:
Privacy and Architecture
All processing is done locally:
This is enabled by:
Benefits:
Use Cases
What I’m Looking For
Feedback on:
Next Steps
Try It
If you run into edge cases or have workflow suggestions, I’m interested in hearing them.
More...
Most sprite workflows are fragmented.
You end up using one tool to extract frames, another to pack atlases, another to compress, and something else to convert formats. On top of that, most tools require uploads or paid features.
I wanted a single pipeline that handled everything, without a backend.
So I built a browser-based sprite toolchain that runs entirely client-side and didnt charge an arm and a leg
What It Does
The tool covers the full sprite workflow:
Input and Conversion
- Convert video or GIF to a sprite sheet with configurable FPS and scale
- Convert video to GIF or MP4
- Extract frames from video or GIF and download as a ZIP
Atlas and Packing
- Pack multiple images into a single texture atlas
- Supports MaxRects, Shelf, and Grid packing
- Duplicate sprite detection (alias packing)
- Optional power-of-two sizing, padding, extrusion, and trimming
Editing and Utilities
- Split sprite sheets into individual frames (grid or margin-based)
- Bulk resize sprites (scale or max constraints)
- Generate normal maps from height maps or images
Output and Optimization
- Convert sprite sheets into animated GIFs
- Convert GIF to MP4 or WebM
- Compress GIFs with control over:
- color count
- dithering
- scaling
- FPS
The Stack
This is essentially a full asset pipeline implemented in the browser.
Video and GIF Processing
For video and GIF decoding, the system uses:
- FFmpeg.wasm for decoding and format conversion
- HTML5 video element and Canvas for frame extraction
FFmpeg.wasm handles:
- video to GIF/MP4 conversion
- GIF to video conversion
- frame extraction pipelines
Canvas is used for:
- pixel-level access
- frame capture
- final atlas generation
Frame Extraction
Frames are extracted either via:
- FFmpeg.wasm (for precise decoding pipelines)
- or video element + Canvas (for faster interactive workflows)
Key considerations:
- accurate frame stepping
- handling variable framerate inputs
- avoiding frame duplication or skipping
Image Processing Pipeline
Once frames are extracted:
- Converted to ImageBitmap where possible
- Normalized to consistent dimensions
- Optionally trimmed to remove transparent bounds
This stage is optimized to:
- reduce memory allocations
- avoid unnecessary redraws
- keep processing responsive
Atlas Packing
Packing is handled using multiple strategies:
- MaxRects (primary)
- Shelf
- Grid
MaxRects is used for:
- optimal space utilization
- irregular frame sizes
- minimizing wasted texture space
Additional features:
- multi-atlas output when limits are exceeded
- padding and extrusion to prevent bleeding
- optional power-of-two constraints
Duplicate Detection
To reduce atlas size:
- pixel data is hashed
- identical frames are reused instead of duplicated
This enables:
- smaller atlases
- more efficient memory usage
- faster runtime performance in engines
Optimization Layer
Several optimization passes are applied:
- PNG quantization for reduced file size
- multi-resolution scaling
- trimming of transparent pixels
These are especially useful for:
- mobile games
- web delivery
- memory-constrained environments
Export System
Exports are designed to plug directly into engines and frameworks:
Supported formats:
- Unity
- Godot
- Phaser
- PixiJS
- Spine
- Starling XML
- CSS sprites
- generic JSON
Output includes:
- atlas image(s)
- metadata (positions, sizes, offsets)
Performance Strategy
Running entirely in the browser introduces constraints:
- limited memory
- device-dependent performance
To handle this:
- OffscreenCanvas is used where available
- buffers are reused
- operations are batched
- unnecessary allocations are avoided
Privacy and Architecture
All processing is done locally:
- no file uploads
- no server round trips
- no storage of user data
This is enabled by:
- FFmpeg.wasm
- Canvas-based processing
Benefits:
- immediate results
- zero infrastructure cost
- full user privacy
Use Cases
- generating sprite sheets from gameplay recordings
- preparing animation atlases
- optimizing assets for mobile or web
- converting between sprite formats and pipelines
What I’m Looking For
Feedback on:
- additional export formats
- performance edge cases
- engine-specific improvements
Next Steps
- Unity package export
- animation preview inside the browser
- CLI version for build pipelines
- browser extension for extracting sprites
Try It
If you run into edge cases or have workflow suggestions, I’m interested in hearing them.
More...