Cutting an image into a grid means dividing one picture into a rectangular set of smaller tiles that, taken together, cover every original pixel exactly once — for example, splitting a 10-pixel-wide source into 4 columns produces tiles of 2, 3, 2, and 3 pixels that sum back to 10. The tiles share straight horizontal and vertical boundaries, no pixels overlap, and every part of the source ends up in exactly one tile. This is the standard way to split a large photo into a printable contact sheet, prepare a 3 by 3 Instagram carousel post, slice a sprite sheet into individual assets, or break a high-resolution scan into manageable sections. The work involves choosing how many rows and columns to use, computing the boundary positions from the source's natural pixel size, copying each rectangle onto its own canvas, and saving the rectangles as separate image files. A browser-based grid splitter can do all of that locally, so the source file never leaves your device while you decide how many tiles you need and which ones to keep.

What "Cutting an Image Into a Grid" Actually Means
Grid cutting is one specific shape of image editing, and the rules are stricter than they look. A grid is always rectangular, meaning every row has the same number of tiles and every column has the same number of tiles. The boundaries run straight across the full width and full height. Nothing is rotated, scaled, padded, or filtered, and no source pixel is allowed to appear in two tiles or to disappear. That is what separates a true grid from a free-form slice tool or a content-aware crop, both of which can drop pixels they consider unimportant.
Three jobs come up most often. The first is social media: a 3 by 3 grid turns one tall photo into a sequence of nine square tiles that, when posted in order to Instagram, recombine into the original image on the profile grid. The second is print: a panoramic image is split into A4-sized tiles so each sheet can be printed on a home printer and the sheets can be taped together. The third is game and web design: a sprite sheet is divided into individual frames so each frame can be loaded on its own and animated independently. In every case the rule is the same — every source pixel ends up in exactly one output file, with no overlap, no gap, and no resampling.
For those jobs, a focused local splitter is the cleanest tool, because it does one thing, does it predictably, and never uploads the source. Image Grid Splitter accepts a single JPG, PNG, or WebP, asks for a row and column count between 1 and 10, and produces up to 100 PNG tiles named by their position in the grid.
Split an Image Into a Grid Step by Step
The whole workflow runs inside one browser tab, in three short actions.
- Choose a local JPG, PNG, or WebP within the displayed file and pixel limits. The file picker accepts only what your browser can decode natively, which means JPG, PNG, and WebP. Files up to 25 MiB are allowed, and the decoded image must fit within 20,000 pixels per side and 40 megapixels total — those caps protect the browser tab from a runaway canvas allocation.
- Enter 1–10 rows and 1–10 columns, then select Split image. Both fields are independent. The combination cannot exceed 10 in either direction, and the total cannot exceed 100 tiles. If a row or column count would produce a tile that is zero pixels wide or tall, the tool rejects the grid instead of producing a misleading empty file.
- Check each numbered tile's dimensions and download the PNG files you need. The result panel lists every tile in top-to-bottom, left-to-right order with its exact width, height, and an individual download link. You can save the whole set, pick only the tiles you want, or change the grid and re-split without leaving the page.
How Grid Boundaries Are Calculated
The interesting part of grid cutting is what happens when the source width or height is not evenly divisible by the number of columns or rows. The splitter uses proportional integer coordinates: for a source width W split into C columns, the i-th boundary sits at floor(i × W / C). That formula covers every pixel exactly once and never rounds to a misleading common size.
A worked example: a source width of 10 pixels divided into 4 columns gives boundaries at 0, 2, 5, 7, and 10. The four column widths are therefore 2, 3, 2, and 3 pixels. The widest tile is one pixel wider than the narrowest, the four widths sum to 10, and no narrow strip is discarded. The same rule is applied independently to the height, so a 1200 by 900 image split into 3 rows and 4 columns produces twelve 300 by 300 tiles whose widths and heights each cover the full source without gaps.
The practical effect is that you can split any source, even one whose dimensions are odd numbers, and trust that the tiles meet flush, cover everything, and never overlap. Each tile is then drawn onto its own natural-size offscreen canvas using the standard drawImage call, which copies only that tile's source rectangle, without stretching, interpolation, filters, borders, or padding. If you need absolutely uniform tile sizes instead, the answer is to pre-crop to a multiple of your target tile size, for example with Image Cropper, before splitting.
Input, Output, and File Naming
Knowing what goes in and what comes out makes the tool easier to trust. The table below summarizes the supported formats, the output format, and the limits the tool enforces. The file selection itself uses the standard browser file input documented for web applications, so the source is read locally and never sent to a server.
| Stage | What is used | Details |
|---|---|---|
| Accepted input formats | JPG, PNG, WebP | What the browser can decode natively; other formats are rejected with a visible error |
| Input file size cap | 25 MiB | Enforced before decoding |
| Decoded pixel cap | 20,000 px per side, 40 MP total | Protects the tab from very large canvas allocations |
| Rows | 1 to 10 | Integer values only |
| Columns | 1 to 10 | Integer values only |
| Maximum tiles | 100 | 10 rows multiplied by 10 columns |
| Output format | PNG | Lossless, supports transparency |
| Output file name | base-row-R-column-C.png | Row-major reading order, sortable |
| Reported per tile | width, height, encoded size | Shown next to each download link |
The PNG choice is deliberate. PNG preserves exact tile boundaries and any source transparency without re-compressing the visible pixels through a lossy codec. A JPEG or WebP source is still decoded in full so every visible pixel is reproduced exactly, but the original JPEG compression bytes and metadata are not retained in the output. If you need the source bytes untouched, work from a PNG source; if you need a smaller archive, convert the resulting tiles later with Image Compressor.
Limits, Errors, and Privacy
Because the splitter runs locally, the limits are mostly browser limits. Anything that would crash the tab is rejected up front. The table below lists the cases the tool handles explicitly, and what the user sees in each.
| Condition | Behavior |
|---|---|
| Unsupported file type | Visible error, no output produced |
| Empty or unreadable file | Visible error, no output produced |
| File over 25 MiB | Rejected before decoding |
| Decoded image over 20,000 px per side or 40 MP | Rejected before drawing |
| Rows or columns outside 1 to 10 | Visible error, no output produced |
| Grid that would create a zero-pixel tile | Visible error, no output produced |
| PNG encoding failure | Visible error, no output produced |
| Source or grid changed after a split | Old results invalidated, stale URLs revoked |
| Source uploaded to a server | Never — processing stays in the current tab |
Privacy is built in by construction. Decoding, slicing, encoding, and download creation all happen inside the current browser tab; the source image is never uploaded to Lizely. Temporary download URLs are revoked when they are replaced or when the tool closes, so old tiles cannot be retrieved after you change the grid. That makes the tool suitable for client work, draft designs, and any image you simply do not want to leave your machine.
When You Need a Different Tool
The splitter is intentionally narrow. It produces a uniform row-by-column grid from one image and nothing else. It does not detect faces, automatically find panels, create overlapping slices, add bleed for printing, package the downloads as a ZIP, reconstruct a panorama, or optimize the PNG files. It does not let you define guides, gutters, or custom row and column heights.
For print production with bleed, custom guides, or mixed tile sizes, use an editor that supports manual slice positions. For sharing many tiles at once, consider compressing the set with Image Compressor or merging them back into a single PDF with Image To PDF. For resizing each tile to a target dimension after the split, run Image Resizer on the saved files. For one-off conversions like turning a JPG source into a PNG master before splitting, use JPG To PNG.
For a straightforward nine-grid post, the simplest path is still the one the tool was built for: set rows to 3 and columns to 3, select Split image, and download the nine numbered results in reading order.