Split one image into a numbered grid of PNG tiles and download them together as a ZIP. The grid covers the whole picture — leftover pixels from an odd width or height are spread across the boundaries instead of being trimmed off the edge. Everything runs in this browser, so nothing is uploaded and nothing costs credits.
One image. Every tile.
Local onlyUpload a PNG, WebP, or JPG to begin. Nothing leaves this browser.
Numbered grid preview
Reading orderTiles are numbered left to right, then top to bottom.
Three splits
A landscape storyboard, a long product detail image, and an odd-pixel illustration with transparent edges. Each row shows the source on the left and the tiles it produces on the right, in the order they export.
A 1500 × 500 banner becomes three 500 × 500 slides in one pass. Because 1500 divides evenly by 3, every tile is identical in size, and the numbered preview confirms that the left panel is published first.
1500 × 500 source · 1 row × 3 columns · 500 × 500 per tile
A 1200 × 1810 detail page becomes four panels read top to bottom. 1810 does not divide by 4, so the boundary stays at whole pixels and the extra pixels alternate: 452, 453, 452, 453. Nothing is cropped and the four heights still add up to 1810.
1200 × 1810 source · 4 rows × 1 column · 1200 × 452, 1200 × 453, 1200 × 452, 1200 × 453
A 301 × 181 illustration with transparent edges splits into tiles of 150 or 151 pixels wide and 90 or 91 tall. The odd pixel in each axis is absorbed at the boundary instead of being dropped, and the transparent areas stay transparent because the alpha channel is copied, not flattened.
301 × 181 source · 2 rows × 2 columns · 150/151 × 90/91 per tile
The arithmetic
The grid covers the entire original image. Leftover pixels from an odd width or height go to the block boundaries, so the last row or column is never cropped.
x_i = floor(i × W ÷ C)
y_j = floor(j × H ÷ R)
301 ÷ 3 → 0, 100, 200, 301 → 100, 100, 101
301 ÷ 2 → 0, 150, 301 → 150, 151
Each boundary sits at a whole pixel: the i-th vertical line is at floor(i × width ÷ columns) and the j-th horizontal line is at floor(j × height ÷ rows). The first boundary is always 0 and the last is always the full width or height, so the outer edges of the grid are the outer edges of the picture.
Take a 301-pixel-wide image split into three columns. The boundaries fall at 0, 100, 200, and 301, which gives tiles 100, 100, and 101 pixels wide. Split the same image into two columns instead and the boundaries are 0, 150, and 301, giving 150 and 151. In both cases the widths add up to 301 exactly — no pixel is discarded. With more divisions the extra pixels can be spread across several tiles rather than only the last one; a 1810-pixel height split four ways gives 452, 453, 452, and 453.
The same rule applies on the vertical axis, and the two axes are independent, so a 2 × 2 grid of a 301 × 181 source gives four tiles of 150 or 151 by 90 or 91. That is the whole reason a split image can be reassembled: every pixel belongs to exactly one tile, and every tile holds at least one pixel. The workbench checks the grid against the pixel dimensions before you export, so a grid larger than the picture is refused rather than producing blank files.
Export order
Upload, set rows and columns, check the numbered preview, export the whole ZIP or a single tile, then publish in row-major order.
Reading order is row-major: the tool walks the first row left to right, then the second row, and so on. The preview numbers every cell in that same order, and the filenames match — row-01-col-01.png is the top-left tile, row-01-col-02.png sits immediately to its right, and row-02-col-01.png starts the second row. When you upload a ZIP to a scheduling tool, sort the files by name and they will arrive in the order the grid shows.
The convention matters most for carousels, where the first image is the hook and the last one carries the call to action. If your grid is 1 row and 3 columns, the three files upload in one predictable sequence. If your platform stacks images vertically instead, split with 3 rows and 1 column so the reading order matches the way the post is scrolled.
Zero-padded numbers are not cosmetic. Sorting row-1, row-10, row-2 alphabetically puts row-10 between row-1 and row-2, which silently shuffles a ten-row grid. Padding every index to the width of the largest number keeps lexical and numeric order identical, and a single tile can be downloaded from the preview whenever you only need to replace one panel.
Where it fits
A wide horizontal design becomes a sequence of square or portrait slides. Split the finished artwork rather than rebuilding each slide, so the type and the illustration stay pixel-identical across the set.
Marketplaces that cap image height accept a tall graphic as several stacked panels. A 4 × 1 split keeps each section whole and lets you reorder or replace a single panel later.
Panel-by-panel delivery needs each frame as its own file at its own size. An uneven grid gives wider panels more pixels instead of forcing every frame into an equal box.
A seamless pattern can be cut into tiles that a page or a press lays out edge to edge. Because the split is lossless, the seams line up and no tile is resampled.
A single sprite sheet becomes individual icons. Filenames encode the row and column, so a developer can map each file to a state without opening them.
Printable puzzles, badges, and sticker sheets are laid out as a grid first. Splitting after design keeps the bleed and the cut marks exactly where the designer put them.
Commercial comparison
Every route below ends with the same picture in pieces. They differ in whether the grid is arbitrary, whether the pixels survive unchanged, and how much of the work you repeat for each tile. The comparison describes workflow categories rather than ranking named products.
| Decision | IMG AI image splitter | Fixed-grid web splitters | Desktop editor, one crop at a time |
|---|---|---|---|
| Grid you can choose | Any combination from 1 × 1 to 10 × 10, landscape, portrait, or square | Often limited to a preset such as 2 × 2 or 3 × 3 | Whatever you draw by hand, once per tile |
| Odd sizes | Integer boundaries spread the remainder across the tiles; nothing is cropped | Varies; some trim the trailing strip or pad it with background | You decide where each edge lands, one tile at a time |
| Pixel fidelity | Tiles are copied from the decoded source, alpha included, with no resampling | Usually a canvas re-encode, which can flatten transparency | Depends on the export settings you choose for each save |
| Where the file goes | Stays in this browser tab; nothing is uploaded | The source is uploaded to a server you do not control | Stays on your machine |
| Export shape | One ZIP in row-major order plus any single tile from the preview | Usually individual downloads, sometimes a ZIP | One save dialog per tile |
| Cost and access | Free, no account, no credits, no file-count limit per visit | Free tiers commonly gate file size, resolution, or daily count | Requires installed software and the skill to use it |
| Repeat work | Change rows or columns and split again in one step | Re-upload for each new grid | Redraw every selection for each new grid |
Be honest about the trade-off: if you already work in a terminal, a scripted ImageMagick crop with a computed offset does exactly the same job, and it can be looped over a whole folder of files. The splitter is for the case where you want that result now, on a machine without the toolchain, with a preview that shows the reading order before you commit to an export.
Adjacent IMG AI tools
These three tools sit next to each other in search because all of them deal with image dimensions. The useful distinction is direction: this page takes one image apart, one page builds a wide image from a brief, and one page merges several photos into a single scene.
| The problem | Image Splitter | AI Banner Generator | AI Image Combiner |
|---|---|---|---|
| Direction | One image in, many tiles out | A brief in, one wide image out | Two or three photos in, one scene out |
| What happens to pixels | Copied exactly; no redraw, no resampling | Generated from scratch as a new composition | Regenerated into one new, unified image |
| Typical sizes | Any source; the grid follows its real width and height | 16:9, 21:9, or 3:2 from 1K to 4K | 4:3 landscape or 1:1 square at 1K |
| Cost on IMG AI | Free; runs in the browser | 20–40 credits per banner | 20 credits per combination |
| Account needed | No | Yes | Yes |
| Pick it when | You already have the finished artwork and need it in pieces | You need a banner and do not have artwork yet | The subject and the setting live in different photos |
What it does
Each tile is copied out of the decoded source, so RGB and alpha values are unchanged and no resampling happens at a boundary.
The preview, the filenames, and the ZIP entries use the same row-major order, so what you check is what you publish.
One source buffer and one tile at a time are held in memory, so a 10 × 10 grid does not allocate a hundred canvases.
The ZIP is written and read back before the download appears, so a finished archive is never announced early.
Clear answers
Upload the image, set rows to 3 and columns to 3, and check the numbered preview. Nine cells appear with row-01-col-01 through row-03-col-03 in reading order. Press split and download the ZIP; the archive holds nine PNG files named to match the preview. The image must be at least 3 pixels wide and 3 pixels tall, which any real photo is.
No. Boundaries are whole pixels from the first edge to the last, so the grid covers the entire picture. When the width or height does not divide evenly, the leftover pixels are absorbed into the tile boundaries instead of being trimmed off the edge, so some tiles are one pixel taller or wider than their neighbours. Every tile is at least one pixel, and together they reproduce the original exactly.
Row-major: left to right across the first row, then left to right across the next. The numbers in the preview and in the filenames use the same order, so sorting the ZIP contents by name gives you the reading order. Indices are zero-padded to the width of the largest number, so row-02 sorts before row-10.
Yes, and it is the most common use. A wide banner usually splits best into 1 row and several columns, which keeps every panel the full height of the artwork. If the panorama is very wide and you plan to publish the pieces as stacked slides, use several rows and 1 column instead so the reading order matches how the post scrolls.
Transparent PNGs keep their alpha channel. The splitter copies RGBA bytes rather than re-encoding through a canvas, which is the step that normally rounds semi-transparent edges, so a soft shadow or an anti-aliased outline stays intact. WebP and JPG sources are converted to PNG tiles, which is lossless for the decoded pixels.
The limit is memory, not upload bandwidth, because the file never leaves the browser. The workbench accepts images up to 40 megapixels and refuses larger ones with a message telling you the exact dimensions it saw. A 40-megapixel photo is roughly 160 MB once decoded, which is why the ceiling exists on phones in particular.
No. The file is read into this browser tab, decoded locally, and split into tiles in memory. There is no upload step, no server-side processing, no account, and no credit charge. Closing the tab discards everything, so download the ZIP before you navigate away.
Yes. After a split, every cell in the numbered preview becomes a download button, so you can save a single panel without taking the archive. That is useful when one slide needs replacing and the rest of the set is already published.
Move to the workflow that matches the asset you actually need.
Choose a file, set the rows and columns, and take the whole grid as one ZIP. No upload, no account, no credits.
Open the splitter