How to Combine Images Into One Picture Without Uploading

Image·October 31, 2026·8 min read

Every image combiner works until your images are different sizes. Here is the exact rule that decides the output, the numbers from real files, and the arithmetic I got wrong.

Combining images sounds like the easy end of image editing, and it is, right up to the moment your two pictures are not the same size. Then every combiner has to make a decision on your behalf, most of them make it silently, and the result is a file you have to download before you can find out what it decided. I built the image combiner on this site and then spent an afternoon working out exactly what it does to mismatched images, because the answer is the whole tool.

Everything below is a measurement from real files rather than a description of the feature. Three fixtures, deliberately awkward: 400x200 red, 200x400 green, 300x300 blue. No two the same shape, and none a multiple of another, so no layout bug can accidentally round its way to the right answer.

The rule that decides everything: width follows the widest

In a vertical stack, every image is scaled to the width of the widest image in the batch, and its height follows its own aspect ratio. That is the entire rule. It is also why nothing is ever cropped and no image is ever stretched: the scale factor is uniform in both axes.

The consequence takes a moment to feel. The 400-pixel-wide image sets the width, so it stays 400x200. The 200x400 image is scaled up by 2x to reach 400 wide, which makes it 800 tall. The 300x300 becomes 400x400. Stack them with no gap and the output is 400x1400 — a number nobody would guess from the inputs, and the reason the size readout sits under the preview.

Horizontal is the same rule on the other axis: every image gets the height of the tallest, so widths follow. The three fixtures become 1400x400, and the same three images in a two-column grid become 800x1600, with each image centred vertically in a cell as tall as the tallest scaled image and a short final row centred across the canvas.

What was measured, and how

A headless Chrome drives the real page with the real fixtures, then reads two things: the size readout under the preview, and the pixels of the preview canvas at coordinates worked out by hand from the rule above. The downloaded file is then decoded with the site’s own PNG decoder and sampled at the same coordinates, so the assertions are about the file a visitor receives rather than about the canvas that produced it.

Input	Setting	Output	Pixels checked
400x200, 200x400, 300x300	Vertical, no gap	400 x 1400	red at (200,100), green at (200,600), blue at (200,1200)
Same three	Horizontal	1400 x 400	red at (400,200), green at (900,200), blue at (1200,200)
Same three	Grid, 2 columns	800 x 1600	red centred in its cell at (200,400), blue centred in the short final row at (400,1200)
Same three	Vertical, gap 20, padding 10	420 x 1460	white at (5,5) and at (200,220) — the padding and the gap
Same three	Output scale 50%	200 x 700	both dimensions halve exactly
Same three, transparent background	PNG	420 x 1460	gap pixel alpha 0 — genuinely empty, not white
4000x3000	Output scale 400%	refused	message: 16000 x 12000, 192.0 megapixels, suggests 45%

The download for the first row was a 16,436-byte PNG at 400x1400, and its first pixel at (200,100) is exactly 255,0,0,255 — the red fixture, unchanged, not resampled into something near-red. That matters because a tool that draws the preview one way and exports another will look perfect in the browser and wrong in the file.

The preview itself never exceeds 1,200 pixels on its long edge — 343x1200 for the first case — because repainting a 12-megapixel canvas on every keystroke of the gap field is how a preview becomes laggy. It is the same plan drawn at a smaller scale, not a mock-up.

The arithmetic I got wrong

While writing the tests I asserted that removing one image from a three-image stack would leave 400x600, and it came back 400x1000. I had assumed the two survivors were the two short ones. They were not: the order after a reorder and a reverse was blue, red, green, so removing blue left red (400x200) and green (200x400) — and green, being half the width, doubles to 800 tall. 200 plus 800 is 1000.

That is the whole trap in one example. The rule is simple, the consequence is not intuitive, and it compounds: add a fourth image narrower than the rest and the output can grow by more than the third one added. Which is why this tool prints the size before you download rather than after, and why the test was corrected rather than the engine.

What the other combiners do

The best of the pages ranking for this query is worth being straight about, because it is not a bad tool. ImageCombiner runs in the browser, has no watermark and no signup, and — quoted from its own page on 2026-10-31 — offers four sizing modes: “Original preserves each image at its native size. Magnify enlarges smaller images to match the largest in the set… Reduce scales the largest down to match the smallest, which is the safest default for mixed dimensions because it never enlarges anything. Crop trims from the center to a uniform size, which produces a perfectly even grid but discards content at the edges.”

That is more layout control than this tool has, and the page should say so rather than pretend otherwise. What it does differently is at the ceiling. The same page states: “The combined image is automatically scaled to fit within 8000 pixels on its longest edge to keep export reliable across browsers.” That is a silent rescale — you ask for 100%, and above a certain size you get something else without being told. It also says “There is no fixed limit” on image count while advising that above “around 30–40 images” you should switch to a grid.

Here the limits are stated and enforced loudly instead. Fifty images, 40 megapixels, 16,384 pixels on a side. Ask for a 4000x3000 image at 400% and you do not get a quietly downsized file; you get the refusal above, which names the 192 megapixels and suggests the 45% that would fit. A limit you are told about is a different thing from a limit you discover by comparing the output to your input.

Where this is worse, plainly

No free-position mode, no rotate or flip on individual images, no fixed aspect ratios like 1:1 or 16:9 for social platforms, and no undo. If you want a collage you arrange by hand, that other tool is the right choice and this page will frustrate you. What this does is one thing: three layouts with a stated rule, exact pixel gaps, a background you choose, and a size you can read before you commit.

The short version

In a vertical stack every image is scaled to the width of the widest one, so heights follow aspect ratios and the output is taller than you expect — 400x1400 from three images whose tallest is 400. Nothing is cropped, nothing is stretched, and an image is only enlarged if it is narrower than the widest. Set the gap and padding in pixels, pick a background, read the size, then download at full resolution. The preview is the export at a smaller scale, so what you see is what you get.

And it happens in the tab: no upload, no account, no watermark, no 10 MB ceiling.

Tools mentioned

Frequently asked questions

How do I combine two images into one picture?

Drop both images onto the page, choose whether they should stack vertically or sit side by side, and download. Measured on two images of 400x200 and 200x400: the vertical result is 400x1000, because both are scaled to the 400-pixel width of the wider one and the second therefore becomes 800 tall. If you want them to be the same height instead, use the horizontal layout, which scales both to the taller image.

Why is my combined image so much taller than I expected?

Because a narrower image has to be enlarged to match the widest one, and enlarging the width enlarges the height by the same factor. A 200x400 image in a stack that is 400 wide becomes 400x800 — twice as tall as it started. Three images of 400x200, 200x400 and 300x300 therefore produce 400x1400, not the 400x900 you get by adding the original heights. The size readout under the preview always shows the real output before you download.

Does combining images reduce their quality?

Only if you ask it to. With PNG at an output scale of 100% the pixels are copied at their original size, and a measured download of a three-image stack came back at 400x1400 with the first pixel exactly 255,0,0,255 — the source value, not a resampled approximation. Images that are reduced are stepped down in halves rather than in one jump, which keeps edges sharp. JPEG and WebP re-encode, so the quality slider applies there.

Can I control the exact output size in pixels?

The size follows from the images and the layout, and the output scale slider multiplies it — 50% took the 400x1400 stack to exactly 200x700, and 200% doubles both dimensions. There is no width field on purpose: a width field is a question you cannot answer until you have seen the result. If you need a specific width, combine first and run the result through Image Resizer, which asks for that width once.

Is there a limit on how many images I can combine?

Fifty images per batch, and a combined canvas of 40 megapixels or 16,384 pixels on a side. Both are enforced with a message that names the number: asking for a 4000x3000 image at 400% produces 16000x12000 — 192 megapixels — and the refusal says so and suggests the 45% scale that would fit. Fifty-one images is not a dead end either, because the result of one combination is an image and can be combined again.

Are my images uploaded to a server?

No. Each image is decoded by the browser and drawn onto a canvas in the tab, and the file you download is produced from that canvas. The only requests the page makes are for the page and its script. Disconnect the network after the page has loaded and the tool still combines images.

Can I combine HEIC photos from an iPhone?

Not directly — Chrome and Firefox have no HEIC decoder. The file is refused by name rather than with a generic error, with a pointer to the HEIC to JPG converter on this site, which also runs in the browser. Convert first, then combine the JPGs.

What happens with transparent images and JPEG output?

A transparent background leaves the gaps, padding and any spare space genuinely empty — measured as an alpha of 0 on the gap pixel, not white paint. That only survives in PNG and WebP. JPEG has no alpha channel at all, so choosing it with a transparent background fills those areas white and says so under the preview, because the alternative is the black that a tool which does not think about it would produce.

Written by the Chaudify team. Every tool mentioned here runs entirely in your browser — nothing you open is ever uploaded. Browse all tools or read more guides.