Explode Image Into Pieces

Splitting (sometimes “exploding”) slices one image into a rectangular grid of smaller pieces. Common uses: Instagram “grid posts” (3 × 3 or 3 × N rows that visually align across the profile), jigsaw puzzle previews, sprite sheets for 2D game animations, tiled CSS backgrounds, large posters that need to be printed across multiple sheets, and educational materials that introduce parts of an image incrementally.

Extend floors the piece size for the first N−1 columns and lets the last column absorb whatever pixels are left over. Same for rows. So a 100-px image cut into 3 columns gives pieces 33, 33, 34 px wide – every pixel kept. Truncate uses the same floored size for every column; the last 1-2 pixels on the right (and bottom) are dropped. Extend is the natural choice for anything where you’ll reassemble the pieces or compare to the original; truncate matches certain legacy tools that expect identical-sized tiles.

Input: anything the browser can decode (JPEG, PNG, WebP, GIF, BMP, SVG-rasterised). Output (per-piece): PNG (default, lossless), JPEG (smaller, no alpha), or WebP (smallest, alpha supported but Safari needs 14+). The download-all ZIP uses each piece’s selected format internally.

Yes – both rows and columns are sliders from 1 to 20. Asymmetric grids like 1 × 4 (a horizontal panorama strip) or 6 × 2 (a tall Instagram series) work the same as square 3 × 3. The compute-grid logic accepts any positive integer up to 100 if you call it programmatically; the UI caps at 20 to keep the preview readable.

The ZIP is built in your browser using a tiny pure-JS encoder included in this tool – no library is loaded. It emits a “store-only” archive (no compression), since each piece is already a compressed PNG/JPEG/WebP. Each file gets a CRC-32 checksum, a local file header, and a central directory entry per the PKZIP spec. Standard unzip programs (Windows Explorer, macOS Archive Utility, unzip on Linux) all accept the output.

The upload cap is 20 MB. Practical limits are about 100 megapixels (browser canvas size limit) and how much memory the preview can hold – a 9 × 9 grid of large pieces is fine, but a 20 × 20 grid of 4K pieces would lag on lower-end devices. Reduce the grid or downscale the source for huge inputs.

For PNG output: yes, byte-for-byte lossless re-encoding (PNG itself is lossless). For JPEG/WebP: the canvas re-encodes at 92% quality – visually indistinguishable from the original but technically lossy. If you started from a JPEG and pick JPEG output, you’re double-encoding once, which adds a small additional loss. Pick PNG if you care about that.

No. The page loads three static files (HTML, CSS, JS) and then everything runs in your browser – the File API decodes the image, canvas draws the pieces, the in-browser ZIP encoder packages them. Your image bytes never leave the device. No fetch, no XHR, no analytics, no cookies.

Yes – free, unlimited, no signup, no watermark. The pieces are yours to use anywhere. Attribution to is appreciated but not required.