A friend sent me a phone photo and a screenshot and asked for them in one image for a listing. I dropped both into a canvas at their own sizes and got something nobody would accept: a 4032 by 3024 photo with a narrow 1170 by 2532 screenshot beside it, a band of empty white under the screenshot, and the whole thing 5202 pixels wide. The pictures were fine. The arrangement was the problem, and it is the same problem every time, because the two files almost never share a dimension. Deciding which axis has to line up is the entire job, and everything else follows from it.
TL;DR: Merging images is a scaling decision before it is a drawing one. Side by side matches every picture to the tallest one's height, stacking matches to the widest one's width, and a grid matches both, which is why a grid also has to choose between cropping and leaving space. Measured on a 4032x3024 photo beside a 1170x2532 screenshot: side by side produces a 5429x3024 canvas with the screenshot enlarged to 1397x3024, stacking produces a 4032x11750 canvas with the screenshot enlarged by a factor of 3.4, and a two-cell grid in cover mode keeps 70.2% of the photo and 49.4% of the screenshot. Pick the mode by which axis you want preserved. The image merger draws all of it in the browser tab, so nothing is uploaded.
Why do merged images come out looking wrong?
Because the inputs are different shapes and most tools draw them at whatever size they arrive.
A phone photo is 4032 by 3024 in landscape. A phone screenshot is 1170 by 2532. A scan is whatever the scanner decided. Place any two of these in a row at native size and one of them towers over the other, with dead space filling whatever is left of the taller dimension. That reads as a mistake rather than a layout, even to someone who could not tell you why.
The fix is to normalise, and the only question is on which axis. In a row, the tops and bottoms are what the eye follows, so the heights have to match and each picture takes whatever width its own aspect ratio then gives it. In a column, the left and right edges are the line, so the widths match instead. A grid has both edges to hold, so it has to match both, and that is the mode where something has to give.
That is the whole design. Everything below is what follows from it.
What does side by side do to a tall screenshot?
It enlarges it, sometimes more than you want.
Here is the measured result for the pair above, taken from the layout code rather than estimated:
| Mode | Canvas | Photo drawn at | Screenshot drawn at |
|---|---|---|---|
| Side by side | 5429 x 3024 | 4032 x 3024 | 1397 x 3024 |
| Stacked | 4032 x 11750 | 4032 x 3024 | 4032 x 8726 |
Side by side matched both to 3024, the taller of the two heights, so the screenshot went from 2532 to 3024 pixels tall. That is a 19% enlargement, which on a screenshot of text is visible if you look for it and invisible if you do not.
Stacking is the dramatic one. Matching to the wider image took the screenshot from 1170 to 4032 pixels wide, a factor of 3.4, and the canvas came out 11,750 pixels tall. The screenshot is now the dominant object in a very long image, and every letter in it has been scaled up by more than three times, which no amount of resampling makes sharp.
The lesson is not that one mode is better. It is that the mode decides which picture gets enlarged, so pick the one whose matched axis your images already agree on. Two phone photos in landscape share a height and go side by side with no scaling at all. Two screenshots from the same phone share a width and stack perfectly.
When should you stack instead of going side by side?
When the content reads downward, or when the pictures are already the same width.
Stacking is right for a sequence: three screenshots of a checkout flow, a before and after where the after belongs underneath, a conversation captured in parts. It is also right whenever the inputs came from the same device in the same orientation, because then the widths already match and nothing is scaled.
Side by side is right for comparison, where the eye should move across rather than down, and for anything that will be viewed inline in a post, because a 4032 by 11,750 image is scrolled rather than seen.
There is a practical reason to prefer the row too. Most places that accept one image display it at a fixed width, so a very tall merge shrinks to a sliver. A row of three photos at the same height stays readable at that width in a way a column of three never does.
What does a grid have to decide that a strip does not?
What to do with a picture that is not the cell's shape, which is a question a strip never has to ask because it only pins one axis.
A grid pins both. Every cell is the same size, and a 4:3 photo does not fit a cell shaped for a 9:19.5 screenshot. There are only two honest answers, and the tool asks you to choose between them:
- Contain fits the whole picture inside the cell and leaves space around it. Nothing is lost, and the grid looks slightly ragged because each image sits in its own patch of background.
- Cover fills the cell completely by taking a centred crop out of the picture. The grid looks even, and the edges of the pictures are gone.
Neither is correct in general. Contain is right for screenshots, documents, diagrams and anything where an edge carries information. Cover is right for faces, scenery and texture, where a centred crop is what a person would have done anyway.
The default here is cover, because the most common reason to build a grid is that it should read as one object.
How much of a picture does cover throw away?
More than people expect when the inputs are different shapes, and nothing at all when they match.
The cell size is the average of the inputs, so two very different pictures produce a cell that suits neither. For the photo and screenshot pair, in a two-cell grid, the layout code reports exactly what gets drawn:
| Image | Native | Source region drawn | Pixels kept |
|---|---|---|---|
| Photo | 4032 x 3024 | 2831 x 3024 | 70.2% |
| Screenshot | 1170 x 2532 | 1170 x 1250 | 49.4% |
Half the screenshot is gone. Not compressed, not scaled: cropped away, top and bottom, because a tall narrow image forced into a nearly square cell has to lose its ends. If that screenshot was a receipt, the total is no longer in the picture.
The same operation on twelve photos from the same camera crops nothing, because every input has the cell's shape already. Cover is cheap when the inputs agree and expensive when they do not, and the tool cannot tell which case you are in. Switch to contain the moment your pictures are different shapes and the edges matter.
How many columns should a grid have?
Enough that the result is wider than it is tall, which for most counts means the square root rounded down.
The rows follow from the columns and the count, and the arithmetic is unforgiving. Twelve images in four columns is three full rows. Seven images in three columns is three rows with two empty cells at the end, which the layout leaves as background rather than stretching the last picture to fill them.
| Images | Columns | Result |
|---|---|---|
| 4 | 2 | 2 x 2, no gaps |
| 6 | 3 | 2 x 3, no gaps |
| 7 | 3 | 3 rows, two cells empty |
| 9 | 3 | 3 x 3, no gaps |
| 12 | 4 | 3 x 4, no gaps |
A count that factors cleanly is worth aiming for. If you have seven photos and the empty corner bothers you, the honest fixes are to drop one, add one, or accept it, because no arrangement of seven equal cells is a rectangle.
Why is there a gap setting, and what should it be?
Because touching images read as one picture, and sometimes that is wrong.
A gap of zero is right for a panorama, for a before and after that should look like one frame, and for anything where the seam is the point. It is the default here for that reason.
A gap is right when the pictures are separate things that happen to be in one file: three product shots, a set of screenshots, a collage. Somewhere between 8 and 24 pixels does the job on images of a few thousand pixels, and the slider goes to 80 for larger work. The gap is applied around the outside as well as between, so the result has a border rather than pictures bleeding off the edge.
One thing to know before choosing PNG for a gapped merge: the gap is filled with white, not left transparent. The canvas is painted white before anything is drawn, because JPEG has no alpha channel and an unpainted gap exports as black. A PNG from this tool therefore has white gutters rather than transparent ones, which matters if you were planning to lay the result over a coloured background.
How big does the merged image get?
Bigger than the inputs, and in the stacked case much bigger, because nothing is being compressed away.
The canvas dimensions are predictable from the mode. Side by side, the width is the sum of the scaled widths and the height is the tallest input. Stacked, the width is the widest input and the height is the sum. A grid is columns times the cell plus the gaps.
Twelve phone photos in a four column grid comes to 16,208 by 9,136 pixels, which is 148 megapixels. That is where the next section starts.
Why does the output stop at 8,000 pixels?
Because past a certain size a browser canvas stops working, and it does not say so.
The limit is not a specification. MDN puts it plainly: most browsers exceed 10,000 by 10,000 pixels, iOS devices have historically been limited to 4,096 by 4,096, and exceeding the maximum dimensions or area "renders the canvas unusable" with drawing commands silently failing. There is no exception to catch. You get a blank image, or nothing at all. Per-browser figures are collected in the canvas-size test results, which is the reference worth checking before assuming a number.
So the layout is scaled down to fit a long side of 8,000 pixels rather than being allowed to fail. For that twelve photo grid the scale factor is 0.494, taking 16,208 by 9,136 down to 8,000 by 4,509, which is 36 megapixels. Each photo lands at roughly 1,976 by 1,483 instead of 4,032 by 3,024.
That is a real loss of resolution, and it is the honest trade: a 36 megapixel image that exists beats a 148 megapixel image that the browser refuses to draw. If you need the full resolution of twelve photos, merge them in fewer, larger pieces, or use a desktop tool with no canvas in the way.
Should the result be PNG or JPG?
JPG for photographs, PNG for screenshots and anything with text or flat colour.
This is the ordinary rule and merging does not change it, but merging does make it matter more, because the output is large. A 5429 by 3024 merge of two photographs is a file you will notice at PNG sizes and will not at JPEG quality 0.92, which is what this exports at.
The reverse holds for screenshots. JPEG's chroma subsampling and block transform produce visible fringing around sharp text edges, and a merged strip of screenshots is mostly sharp text edges. PNG is lossless, so the text stays exactly as crisp as it was.
A mixed merge has no right answer. If one of your inputs is a screenshot with text and another is a photograph, choose by which one a reader will look at.
Does merging lose quality?
The drawing does not, but the scaling might, and it is worth knowing which is which.
Pixels that are drawn at their native size are copied, not recompressed. In a side by side merge of two landscape photos from the same camera, nothing at all is scaled, so every pixel in the output came from an input pixel.
The scaling is where the quality goes. Any picture enlarged to match a taller neighbour is resampled, which invents pixels that were never photographed. A screenshot enlarged 3.4 times to match a photo's width is soft in a way no setting here fixes. Nothing is upscaled past the largest input on the axis being matched, so there is a ceiling, but a small picture beside a large one still gets stretched to reach it.
Then there is the export. Choosing JPG re-encodes everything, including the inputs that were already JPEGs, which is a second generation of lossy compression on those. It is the same mechanism described in the audio guide about extracting a track, in a different medium: decoding something lossy and compressing it again is never free. At quality 0.92 the cost is small, and for a merged photo strip it is the right call anyway.
What order do the images go in?
The order you added them, left to right or top to bottom, and the only way to change it is to remove one and add it again.
This is worth knowing before you select twelve files at once, because a file picker hands them over in its own order, which is usually alphabetical by filename and occasionally not. For a sequence that matters, like a checkout flow, adding them one at a time in the order you want is less work than fixing it afterwards.
Thirty images is the ceiling. That is not a canvas limit, it is a sanity limit: a merge of thirty phone photos is a 30 megapixel grid after the cap and a layout nobody can read.
What does a merged image not give you?
Everything a design tool does, which is the honest boundary of a merging tool.
There are no borders around individual pictures, no rounded corners, no drop shadows, no captions, no per-image rotation, no overlapping, no background colour other than white. Each picture is drawn into its rectangle and that is the whole feature set.
If you want a framed collage with text, that is a design job and a design tool. If you want to put three pictures in one file so that something which accepts one image gets all three, that is this. Treating the second as a weak version of the first is the usual source of disappointment.
Two adjacent tools cover the common follow-ups: adding text to an image for a caption, and the image compressor when a merged photo grid comes out larger than an upload limit allows.
Why does this run in the browser?
Because the images never need to go anywhere, and the moment they do, it is someone else's decision what happens to them.
The whole merge is a canvas operation. Your files are decoded into page memory, drawn onto a canvas in the tab, and the canvas is handed back as a download through toBlob. No request carries an image, nothing is written to a server, and there is no stored copy for anyone to leak or forget.
For a lot of merges that is a nicety. For the ones involving a screenshot of a bank statement, a photo of a document, a medical scan or a picture of a child, it is the whole reason to use a tool like this instead of the first result that asks you to upload.
The cost is the canvas ceiling described above and the fact that very large merges are limited by how much memory the tab can hold. For two images, or twelve, neither is a limit you will meet.
