Combining images into one file means taking two to twelve separate pictures, placing them on a single canvas with a configurable gap and background color, and exporting the result as one PNG. The process keeps every source image at its original pixel dimensions, never crops, resizes, or alters the aspect ratio, and runs entirely in your browser so the source files never leave your computer. Layout choice determines how the images are arranged: horizontal places them from left to right at their decoded pixel sizes, vertical stacks them top to bottom, and a grid arranges them inside the smallest square-like column count the image total allows. A 0–100 pixel gap separates items, and the chosen background color fills the unused canvas plus any empty cells in the final grid row. The output is always one PNG, regardless of which input formats were used.
Why Combine Images Into One File
People combine images into one file for very practical reasons. Photographers build before-and-after pairs for client reviews, ecommerce sellers assemble contact sheets of every product shot in a single sheet, and designers create storyboard panels from sequential screenshots. Game developers preview sprite atlas arrangements before committing to a packed texture, and social media managers stitch multi-slide carousels into one quick preview without juggling separate files. The shared thread is straightforward: instead of emailing, uploading, or sharing N image attachments, you ship one consolidated file the recipient can open once.
That single-file workflow also helps with archival. A contact sheet that captures every receipt scan of the day is easier to file than twelve loose JPEGs. A grid of product variations in one image becomes a single asset in a brand library. A horizontal strip of sequential frames lets a reviewer scrub through a process without unzipping anything. In each case, the goal is fewer files to manage, easier sharing, and one tidy image that still contains every original picture at full resolution.
Three Layouts and When to Use Each
Three layouts cover most of those use cases, and the table below summarizes the dimension math behind each one.
| Layout | Output width formula | Output height formula | Typical use |
|---|---|---|---|
| Horizontal | Sum of image widths plus gaps | Height of the tallest image | Timeline strips, A/B comparisons, panoramic storyboards |
| Vertical | Width of the widest image | Sum of image heights plus gaps | Comic panels, tall before-and-after, numbered process steps |
| Grid | Columns × cell width | Rows × cell height | Contact sheets, gallery previews, sprite atlas drafts |
The horizontal layout lines images up from left to right at their decoded pixel sizes, uses the tallest image as the row height, and centers shorter images vertically. The vertical layout stacks images from top to bottom, uses the widest image as the column width, and centers narrower images horizontally. In both arrangements, shorter or narrower sources are centered against the longest edge rather than stretched to match.
The grid layout is the closest to a contact sheet. The tool computes the smallest square-like column count by taking the ceiling of the square root of the image count, so nine images fill a three-by-three grid and ten images fill a four-by-three grid with the final row partly empty. Every cell uses the widest decoded image and tallest decoded image as its bounds, and each source is centered inside its cell without stretching. Empty cells in the last row and unused space inside any cell show the chosen background color, which makes the grid layout especially suited to preview sheets and galleries.
A concrete worked example with three images on a horizontal layout, using a 20 pixel gap, illustrates the math. Image A is 800 × 600, Image B is 600 × 400, and Image C is 400 × 500. Output width = 800 + 20 + 600 + 20 + 400 = 1840 pixels, and output height = max(600, 400, 500) = 600 pixels. That single calculation is the entire dimension formula: sum the relevant sides, add the gaps, and let the longest edge in the perpendicular direction set the other dimension.
How to Combine Images Into One File
Putting the workflow into practice takes three explicit actions. The Combine Images tool accepts two to twelve supported raster files in the order you want them placed, lets you pick a layout, and produces one PNG for download.
- Choose between two and twelve supported raster images in the order you want them placed. PNG, JPEG, WebP, GIF, AVIF, and BMP files are decoded directly in the browser; SVG is deliberately rejected because it can reference external resources or carry very large render instructions.
- Select a horizontal, vertical, or grid layout, then set the gap (0–100 pixels) and the background color using the six-digit color picker that fills unused canvas and the area between images.
- Choose Combine images, verify the output dimensions shown on the result, and download the generated PNG. The browser handles decoding, layout calculation, drawing, and PNG encoding without any network upload.
Each source is decoded once with the browser's image bitmap path, placed at its original pixel dimensions, and then the canvas is encoded as one PNG through the standard browser encoder. The selection order in your file picker is preserved exactly, so picking files in the order you want them to appear is the simplest way to control the result.
Supported Formats, Size Limits, and Canvas Boundaries
Some combinations will fail before the canvas is built, and the limits below explain why. The tool deliberately bounds the operation so a single oversized image cannot crash the browser tab.
| Constraint | Limit | What happens at the limit |
|---|---|---|
| Images per run | 2 to 12 | Fewer than two or more than twelve is rejected before decoding |
| Per-file size | 25 MiB | A file above this size is not processed |
| Combined size | 100 MiB | The full selection above this total is rejected |
| Canvas width or height | 8,192 pixels | A side that exceeds this caps the operation |
| Canvas area | 32,000,000 pixels | Width × height above this is rejected |
The supported raster formats are PNG, JPEG, WebP, GIF, AVIF, and BMP. Files whose extension looks familiar may still fail when their bytes are corrupt or their codec is unsupported, so a brief check of any source that errors out is worth the time. Animated GIF, animated WebP, or animated AVIF input contributes only the frame decoded by the browser's image bitmap path; animation is not preserved in the single PNG output.
What the Output PNG Keeps and What It Drops
The output is always one PNG, and that choice has visible consequences. PNG preserves sharp pixels and transparency in decoded inputs, but the selected opaque background color is painted first, so any transparent area in a source image becomes that background color in the final file. The result is a single static PNG whose visible pixels match the layout you chose, with sharp edges and no compression artifacts from a second re-encode.
Several details are intentionally dropped on the way out. EXIF metadata, color-profile tags, layer information, original filenames, and source format headers are not preserved in the PNG. The tool does not compress toward a target byte size and does not add metadata. For print production or color-managed compositing, verify the exported PNG in dedicated software before publishing, since the local workflow is tuned for layout rather than for color-managed pipelines.
Why Local Processing Matters
Everything happens in the current browser tab. Image decoding, layout math, canvas painting, PNG encoding, and download generation all run locally, which means the source files never travel to a server and never leave your computer. For workflows that handle unreleased product shots, internal screenshots, medical imagery, financial documents, or any other content with privacy or compliance requirements, that local path removes a whole category of risk that an upload-based merger would introduce.
After the PNG is downloaded, every intermediate ImageBitmap used for drawing is closed and the temporary Object URL is revoked, which keeps the browser's working set tidy for the next operation. Running the tool on a different set of images starts from a clean canvas each time, so earlier selections and earlier outputs do not bleed into the new run.