A 1001 pixel wide image cut into three does not give three tiles of 333. It gives 333, 334 and 333, and which tile gets the extra pixel decides whether the picture goes back together. The obvious way to write this, dividing the width by the count and using that size for every tile, drops 2,333 pixels off a 1001 by 667 image without reporting anything. The tiles look fine on their own. The damage only appears when they are back beside each other, as a thin line of the wrong thing down the seam, which on a nine-piece Instagram grid is the one place every visitor looks.
TL;DR: Splitting an image is one arithmetic decision repeated: where does each cut fall when the image does not divide evenly. Computing every boundary from a single rounded sequence makes tile N's right edge tile N+1's left edge by construction, so the pieces reassemble exactly. Verified by hashing: a 1001x667 image split into nine tiles and pasted back produced raw pixels with the same MD5 as the original,
6fc1f790a418dc1ed3ee3d11747f1c20. The naive approach drops 2,333 pixels from the same image. The image splitter runs in the browser and hands back a ZIP.
What does splitting an image mean here?
Cutting one picture into a set of smaller ones that tile it exactly, with no overlap and nothing left over.
Two ways to say what you want. Grid mode takes a number of rows and columns, so a 3 by 3 gives nine tiles whatever the image size. Size mode takes a tile width and height in pixels, and the grid is however many of those fit, with the right-hand column and bottom row being whatever remains.
The jobs behind it are specific. A nine-piece Instagram grid from one picture. A large map or poster broken into printable sheets. A sprite sheet cut back into frames. A panorama divided for a carousel post. In every one of them the pieces will end up adjacent again, which is why the seams matter more than anything else about the operation.
Why does a grid not divide evenly?
Because image dimensions are whatever the camera produced, and three rarely goes into them.
Pixels are integers, so a cut either falls on a pixel boundary or it does not exist. An image whose width is not a multiple of the column count has a remainder that must go somewhere, and the only question is where.
Measured on the sequence the splitter produces:
| Image width | Cut into | Tile widths | Sum |
|---|---|---|---|
| 1000 | 3 | 333, 334, 333 | 1000 |
| 1080 | 3 | 360, 360, 360 | 1080 |
| 1001 | 7 | 143 x 7 | 1001 |
| 4032 | 5 | 806, 807, 806, 807, 806 | 4032 |
The remainder is spread rather than dumped. A 1000 pixel image in three parts gives 333, 334, 333, not 333, 333, 334, because each boundary is computed as round(total * i / count) from the same sequence. The difference is invisible on one image and matters on a grid, where an extra pixel on the final tile makes the last column visibly wider than the rest.
Note the third row. 1001 divided by 7 is exactly 143, and plenty of dimensions do divide cleanly. The arithmetic only shows itself when they do not.
How do you know nothing is lost at the seams?
By splitting an image and putting it back together, then comparing the pixels rather than looking at them.
I generated a 1001 by 667 image of deterministic noise, so that every pixel differs from its neighbours and any duplicated or dropped column would be obvious to a hash. Then I split it into a 3 by 3 using the tool's own plan, extracted each tile, and pasted each one back at the coordinates it came from:
source 1001x667 raw md5 6fc1f790a418dc1ed3ee3d11747f1c20
reassembled 9 tiles raw md5 6fc1f790a418dc1ed3ee3d11747f1c20
Identical. Not similar, not visually indistinguishable: the same bytes. No pixel was lost and none was duplicated.
The tiles that produced it are not all the same size, which is the point:
334x222 333x222 334x222
334x223 333x223 334x223
334x222 333x222 334x222
Nine tiles, three different widths and two different heights between them, covering 667,667 pixels, which is exactly 1001 times 667.
Now the naive version of the same job. Take floor(1001 / 3) and floor(667 / 3), use 333 by 222 for every tile, and you cover 999 by 666. A strip two pixels wide and one pixel tall never makes it into any tile. That is 2,333 pixels silently discarded, and on a photograph it is the right edge of the picture.
Grid mode or fixed tile size?
Grid when the number of pieces matters. Size when the dimensions of each piece matter.
| You want | Mode | Why |
|---|---|---|
| Nine posts for a feed grid | Grid, 3 x 3 | The count is the requirement |
| A poster across A4 sheets | Size | The sheet size is the requirement |
| A sprite sheet cut into frames | Size | The frame size is fixed and known |
| A panorama into a carousel | Grid, 1 row | The count is the carousel length |
The two modes disagree about the leftovers, and that is the real difference between them. Grid mode distributes the remainder, so every tile is within one pixel of every other. Size mode gives you exactly the size you asked for and puts the whole remainder in the last row and column.
What happens to the last row and column in size mode?
They come out smaller, and that is deliberate.
Splitting a 1000 by 800 image into 300 by 300 tiles gives a 4 by 3 grid. Twelve tiles, of which six are not 300 by 300:
r0c3 100x300 r1c3 100x300 r2c3 100x200
r2c0 300x200 r2c1 300x200 r2c2 300x200
Those cover 800,000 pixels, exactly the source. The alternative would be to crop the image down to a whole number of tiles, which means quietly throwing away a 100 pixel strip on the right and a 200 pixel strip along the bottom. A tool that does that is deciding for you that the edge of your picture does not matter.
If you want equal tiles, use grid mode. If you want tiles of a given size and the image does not divide by it, the undersized edge pieces are the honest answer.
Why are the files named r01-c01?
So that a file manager sorting by name gives you the reading order, which it will not do otherwise.
Sorting is alphabetical, so tile-10 sorts between tile-1 and tile-2. A twelve-piece grid listed that way reassembles in the wrong order, and anyone working from the filenames puts row ten where row two belongs.
The numbers are padded to the width of the largest index, so the padding appears only when it is needed:
3 x 3 grid shot-r3-c3.png
12 x 12 grid My-Holiday-Photo-r01-c01.png ... My-Holiday-Photo-r12-c12.png
The original name is kept, with spaces and anything that is not a word character turned into hyphens, so a file that came from a phone still tells you what it was.
PNG or JPG for the tiles?
PNG unless the tiles are photographs and the total size is a problem.
Splitting is lossless in itself: the pixels in a tile are the pixels from the source. Saving as PNG keeps it that way, because PNG is a lossless format. Saving as JPG re-encodes each tile, which on a photograph that was already a JPEG means a second generation of loss.
There is a reason specific to splitting to prefer PNG, beyond the usual one. JPEG compresses in 8 by 8 blocks, and its artefacts are strongest at the edges of those blocks. Every tile boundary is a new edge in a new file, encoded with no knowledge of its neighbour, so JPEG tiles can show a faint discontinuity exactly along the seams you were trying to make invisible. PNG has no such behaviour.
JPG at quality 0.92 is what the tool writes when you pick it, which is a reasonable setting and still a second generation. For nine tiles of a photograph headed for a social feed that will recompress them anyway, it is a defensible trade. For anything being printed or reassembled, PNG.
How many tiles can you make?
Four hundred, which is a 20 by 20 grid, and the limit is about the browser rather than the arithmetic.
Each tile becomes its own canvas and its own encoded blob before anything is zipped, so four hundred tiles means four hundred canvases and four hundred encodes in one tab. Past that, encoding starts to stall the page rather than finish slowly.
21 x 21 -> That is 441 tiles. The limit is 400, which is a 20 by 20 grid.
A second check catches the other end. You cannot cut an image into more parts than it has pixels along that axis, so asking for 80 rows from a 50 pixel tall image is refused with the image's actual size, rather than producing 30 tiles of zero height.
Will a nine-piece grid line up on Instagram?
The pieces will be right. Whether the illusion works is a separate question with two parts to it.
First, the shape. A feed grid is square cells, so a square source split 3 by 3 gives square tiles and everything matches. A 4:3 photograph split 3 by 3 gives tiles that are 4:3, and the feed will crop each one to a square independently, which breaks the picture. Crop or pad the source to a square before splitting, not after.
Second, the order. A feed fills newest first, from the top left, moving right. So the tile you want in the top left corner has to be the last one posted. The posting order is the reverse of the reading order: start with the bottom right tile and finish with the top left. Posting them in the order the files are numbered puts the picture upside down and back to front.
The seams will also not be invisible, because the grid draws a small gap between thumbnails. The effect is a picture seen through a window frame rather than a continuous image, which is what every grid post looks like and what people expect.
What size should the tiles be for printing across sheets?
Work backwards from the paper and the printer's resolution, and expect the sum to be larger than the image you have.
A4 is 210 by 297 millimetres. At 300 dots per inch, which is the usual target for something being looked at closely, that is 2,480 by 3,508 pixels per sheet. A poster across a 3 by 3 of A4 therefore wants a source of 7,440 by 10,524 pixels, which is 78 megapixels. A photo from a recent phone is about 12.
So the honest version of this job is usually a lower resolution than 300 dpi, or fewer sheets, or accepting that the print will be soft. At 150 dpi the same 3 by 3 needs 3,720 by 5,262, which is within reach of a good camera. Splitting cannot add detail; it only decides where the cuts fall.
One thing to settle before you print rather than after. Consumer printers cannot print to the edge of the sheet, so each tile arrives with a white margin, and nine sheets taped together show nine white borders through the picture. The usual answer is to print borderless if the printer supports it, or to trim each sheet along one edge and overlap them. This tool cuts exactly, with no bleed and no overlap, so the overlap has to come from the source: split a slightly larger grid and accept losing a strip, or add the bleed yourself before splitting.
Does splitting lose quality?
The cutting does not. The saving might, and the resizing that nobody mentions definitely does.
Each tile is drawn from the source image into a canvas of exactly the tile's size, one source pixel to one destination pixel, with no scaling involved. That is a copy. The hash test above is the proof of it.
Where quality goes is the encoder, covered above, and one thing outside this tool entirely: anywhere you upload the tiles will probably resize them. A 360 by 360 tile posted to a feed that wants 1080 by 1080 will be scaled up by the platform, and upscaling invents pixels. If the tiles are destined for somewhere with a known size, split a source large enough that each tile is at least that size.
Why does the download come as a ZIP?
Because nine files, or four hundred, are not something a browser can hand over one at a time without a fight.
A page triggering several downloads in sequence gets blocked by most browsers after the first, which is a sensible protection against a page that wants to put twenty things in your Downloads folder. Building a ZIP in the page and offering one file is the way round it, and it also keeps the tiles together with their names intact, which is the part that matters for reassembly.
The archive is built in memory, which is another reason for the four hundred tile ceiling: the tab holds the source image, every tile's canvas, every encoded blob and the finished archive at the same time.
What splitting does not do
It cuts a rectangle into a grid of rectangles. There is nothing else in it.
No overlap between tiles, which some mapping workflows want. No bleed or crop marks for print. No non-rectangular pieces. No automatic cropping to a square before the split. No reassembly, which is the opposite job and belongs to the image merger, covered in its guide.
If you want a puzzle, a mosaic, or tiles with overlap, this is not that tool, and the gap is worth knowing before you start rather than after nine files land in your Downloads folder.
Why does this run in the browser?
Because cutting a rectangle out of a picture is something a canvas does natively, and a server adds nothing but a copy of your image on someone else's disk.
The picture is decoded into the tab, each tile is drawn into its own canvas, each canvas is encoded with toBlob, and the collection is zipped and handed back. Nothing is uploaded and nothing is stored.
The images people split are not always a holiday photo for a feed. They are floor plans, scanned documents, medical images, screenshots of internal systems, artwork before it is published. For those, the usual alternative sends the whole picture to a service in exchange for an operation your own machine performs in a fraction of a second.
