Supported Formats and Image Loading
The CSS sprite generator combines multiple selected or dropped PNG, JPEG, GIF, or WebP images into a single transparent PNG image and generates the corresponding positioning CSS.
The file picker includes an accept attribute for four standard image formats as an input selection hint, rather than enforcing strict MIME type or file extension validation.
When files are imported, the browser decodes each image independently, and successful items are placed into the asset list strictly in their original file-selection order regardless of varying asynchronous decoding speeds.
If decode errors occur, failures are reported individually by filename, and entirely failed batches register no assets.
The file picker includes an accept attribute for four standard image formats as an input selection hint, rather than enforcing strict MIME type or file extension validation.
Because acceptance ultimately depends on whether the browser engine can successfully decode the provided binary data, unsupported or corrupted files as well as zero-dimension images are rejected during decoding.
Individual decode failures are reported directly by filename, ensuring that one faulty file does not block other valid images in the same selection from being registered, while an entire batch containing only invalid files will add nothing.
The list holds your loaded assets, and images are drawn at their natural dimensions. These boundaries and capacities are practical constraints within the browser rather than fixed universal limits defined by image specifications, depending on browser memory and Canvas execution.
Object URLs created to decode selected images are now promptly revoked for each file immediately upon either successful loading or decode failure, preventing orphaned blob references from accumulating in browser memory when importing batches.
These temporary internal URLs serve solely to parse image data within the client-side session and must not be used as external upload destinations or permanent asset links.
While this immediate cleanup prevents memory leakage from unreleased decoding blobs, browser resources still scale with total loaded asset volume and dimensions during sprite layout processing.
Coordinate Calculation for Vertical, Horizontal, and Grid Layouts
Loaded images can be arranged in three layouts: vertical, horizontal, or grid. Each layout positions items according to the current asset list order.
You can reorder images one by one using the list buttons to recalculate coordinates and CSS classes. The tool does not perform automatic packing optimization by size or bin packing into vacant spaces.
In a vertical layout, all images are aligned to the left edge at X=0. Starting with the first image at Y=0, each subsequent image is placed at a position that adds the preceding image height and the specified margin.
The total sprite width equals the maximum width among the images, and the total height is the sum of all image heights and intermediate margins.
No margin is added below the final image.
The horizontal layout applies this calculation along the horizontal axis. Images are aligned to the top edge at Y=0, and each image is positioned at an X coordinate that adds the previous image width and margin.
The total height equals the maximum image height, and the total width is the sum of image widths and intermediate margins. When images have differing dimensions, transparent areas remain along the right in vertical layouts or along the bottom in horizontal layouts.
The grid layout allows selecting between 2 and 10 columns, wrapping to a new line after the specified column count. Within a row, image widths and margins are sequentially added to the X coordinate, while the next row Y coordinate is determined by the tallest image in the preceding row plus the margin.
Consequently, images of varying heights on the same row will not overlap the next row, though transparent gaps appear beneath shorter images.
The margin between images can be adjusted from 0 to 50px. Rather than enforcing uniform cell column widths across the grid, the layout adds margins directly following the natural width of each image in that row.
Because this does not create a rigid grid of identical cells, you should equalize source image dimensions beforehand if a uniformly aligned appearance is required.
Natural Dimension Canvas Rendering and PNG Output Limits
Once coordinates are determined, each image is rendered onto a transparent Canvas at its natural dimensions. Each image uses its decoded input dimensions, and no scaling or resizing occurs during sprite generation.
There are no controls for quality sliders, compression ratios, color reduction, cropping, or background removal. If you need to alter image dimensions or backgrounds, prepare them with external editing tools prior to importing.
While GIF and WebP inputs are accepted, the output is always a single static PNG image. The timeline and multi-frame animations of animated GIFs or animated WebPs are not preserved.
Only a static frame—corresponding to the browser default or initial frame—is captured onto the Canvas. The tool cannot be used for tasks requiring combined animated assets.
The final combined output is rendered onto a Canvas and exported as a PNG Blob. Keep in mind that extremely large dimensions or high pixel counts may exceed browser memory allocations, so layouts, columns, margins, and asset counts should be adjusted to remain within practical system capacities.
Canvas rendering capacity is not universally identical across platforms. Depending on the browser and device memory state, allocating a Canvas, acquiring a 2D rendering context, drawing images, or generating a PNG Blob may fail even at modest dimensions.
When an export fails, reducing image counts or asset dimensions allows you to retry the generation process.
Constructing the Base Class and background-position
The generated CSS is structured into a base class shared by all images and individual classes for each asset. If the default prefix is sprite-, the shared class is .sprite-base.
This class groups common declarations: background-image: url('sprite.png'), background-repeat: no-repeat, and display: inline-block.
Each individual class outputs the natural width and height of the original image, along with a background-position value using inverted coordinate signs.
For example, if an image upper-left corner is located at X=48px and Y=32px, its background-position is -48px -32px. Axes with a coordinate of 0 are output as 0 rather than -0px.
This structure exposes the corresponding region of the background image through an element sized to that image.
When implementing the sprite, apply both the base class and the individual image class to the target element, such as class="sprite-base sprite-arrow".
This two-class structure is an output convention designed to avoid repeating identical background-image declarations across every selector rather than a mandatory CSS specification requirement.
The CSS is generated with the background image filename set to sprite.png. If you save the downloaded PNG under a different name or serve it from a CDN or separate directory path, update the background-image URL to match your deployment environment.
The tool provides the CSS code and PNG file directly on screen rather than generating HTML templates, downloadable CSS files, ZIP bundles, or Data URIs.
Class names derived from filenames undergo NFKD normalization, where characters outside ASCII letters, digits, hyphens, and underscores are replaced with hyphens, consecutive hyphens are collapsed, and leading or trailing hyphens and underscores are trimmed.
If a normalized name is empty, it falls back to 'image', and names beginning with a digit are prepended with item-. Custom prefixes allow empty strings or undergo similar ASCII normalization; if a non-empty prefix normalizes to empty, it falls back to 'sprite-', prepending item- if it begins with a digit.
Prefixes are normalized rather than preserved literally or processed with CSS.escape, non-ASCII characters are not transliterated, and collisions with external stylesheets are not detected.
Final names shown in the asset list match generated CSS and are made unique with numeric suffixes like -2.
Invalidation of Results, Copying, Saving, and Errors
Successfully adding, removing, or reordering images, as well as modifying layout orientation, column count, padding spacing, or class prefixes, immediately invalidates and clears both the generated PNG preview and the CSS output from the display.
Previous outputs are not retained across configuration changes or asset list edits, and the tool does not automatically generate sprites upon setting updates.
You must manually click the generate button after completing your configuration adjustments to produce an updated sprite sheet and its matching stylesheet.
PNG generation is an asynchronous operation managed by internal generation tokens, ensuring that outdated canvas export tasks are discarded if inputs change or the component unmounts mid-process.
Generated CSS rules and the previewed PNG are published atomically only after the matching image Blob is fully finalized, preventing synchronization mismatches between styling and graphics.
If rendering encounters an error, the busy state clears so you can immediately retry generation. General processing constraints still depend on browser canvas capabilities.
Once generated, you can inspect the combined PNG on the sprite image tab and review class definitions on the CSS code tab. The save button downloads the PNG file as sprite.png.
Copies the exact generated CSS rules with trailing newlines directly to the clipboard. The status confirms when the copy operation succeeds, or displays a selectable manual copy field if clipboard access is denied or unavailable.
Modifying layout settings or generating a new sprite immediately invalidates active copy feedback and clears the manual fallback.
The temporary Object URL generated for the PNG sprite preview is revoked whenever the asset list or generation settings change, a replacement sprite sheet is generated, or the page component unmounts.
Because this client-side reference has a transient lifecycle tied strictly to your active editing session, it cannot serve as a permanent hosting URL or remote asset link on production websites.
Download and save your finalized PNG file locally before altering layout settings or navigating away, and upload the image file to your intended static file server or content delivery network.
Performance Considerations, Unsupported Features, and Pre-Release Checklist
Because CSS sprites consolidate multiple small images into a single resource, they reduce the number of separate image requests. However, this consolidation does not automatically improve actual page rendering speed.
Under HTTP/2 and HTTP/3, multi-resource multiplexing behaves differently than under HTTP/1.1, and serving individual files can sometimes offer more granular caching and modular updates.
Pages that display only a fraction of the sprited icons still require downloading the entire combined PNG. Consequently, although request counts decrease, transferring unused image data may increase overall payload size and decoding overhead.
Evaluate usage frequency, cross-page sharing, update cadence, caching policies, and total file size. This tool does not guarantee improvements to LCP or Core Web Vitals.
This tool does not generate SVG sprites, <symbol> definitions, icon fonts, automated Retina @2x variants, background-size properties, responsive picture elements, or media queries.
Automated 2D bin packing, layout area minimization, and intelligent whitespace compaction are likewise unsupported. You can preview the combined sprite sheet, but there is no preview screen that automatically renders and compares individual icons using the generated CSS.
Before deploying, verify that the PNG and CSS originate from the same generation run, that the background-image URL points to the correct deployment path, that both base and individual classes are assigned, and that class names do not collide with existing styles.
If high-DPI displays must be supported, design accompanying CSS tailored to your physical and display dimensions. Keyboard accessibility, color contrast, and icon text alternatives must be handled in your HTML and UI design rather than via sprite CSS alone.
This tool does not verify copyright, trademark status, licensing terms, or personality rights for input images. The ability to generate CSS and PNG files does not grant permission to publish or redistribute the source graphics.
Confirm that you hold appropriate usage rights and meet all publishing criteria before deploying assets.