How to Merge JPG Files into One Image (3 Methods Compared)

I needed to merge 14 receipt scans into one image for an expense report last month. The first tool I tried uploaded all my files to a server, slapped a watermark on the output, then asked for $12 to remove it. The second tool crashed my browser tab after the 8th image. The third produced a PDF when I specifically wanted a JPG.

After testing a dozen options, three approaches actually work reliably. Each has a specific use case where it wins.

Method 1: Browser-based JPG merger (best for 2-30 images)

Browser tools run the merge inside your browser using the HTML5 Canvas API. You pick your images, choose a layout (vertical, horizontal, or grid), and download the result. No installation, no signup.

How the Canvas API actually works: Your browser loads each image into memory as a bitmap - raw pixel data. The tool creates a canvas element sized to fit all images in your chosen layout. It draws each image onto that canvas at calculated coordinates. Then it calls canvas.toDataURL('image/jpeg', quality) to compress and export the final JPG. Zero network requests touch your image data.

I timed a 20-image merge (each photo 4032x3024 px, average 4.2 MB) across three browser tools:

The speed difference comes down to network upload time. Server-based tools spend 3-5 seconds uploading your images before processing even starts. Client-side tools skip that entirely.

Where browser tools fail: Memory. Each 4032x3024 image consumes about 48 MB of RAM as an uncompressed bitmap (width x height x 4 bytes per pixel). Twenty images eat nearly 1 GB just for the source bitmaps, plus the canvas itself. On a phone with 3 GB total RAM, you will see browser tab crashes around 15-20 large images. On desktop with 8+ GB, I have gone past 100 images without issues.

Method 2: Desktop software (best for 30+ images or repeated batches)

For large batches, desktop tools avoid the browser memory ceiling by streaming images from disk. ImageMagick is the standard.

Vertical merge of all JPGs in a folder:

magick convert *.jpg -append merged-vertical.jpg

Horizontal merge:

magick convert *.jpg +append merged-horizontal.jpg

Grid layout (4 columns):

magick montage *.jpg -tile 4x -geometry +5+5 grid.jpg

ImageMagick handles 500+ images without flinching because it can read and discard images one at a time instead of holding all bitmaps in memory simultaneously. The tradeoff is setup: you need to install it (via Homebrew on Mac, apt on Linux, or the Windows installer), and the command-line interface has a learning curve.

Quality note: ImageMagick's -append re-encodes the image by default. Set -quality 95 to control compression. For truly lossless vertical/horizontal joins (no re-encoding), use jpegtran - but it only works when image widths are multiples of the JPEG MCU size (usually 8 or 16 pixels). This means images shot at 4032 px wide work (4032 / 16 = 252), but a 1000 px crop would not.

Batch merging with GIMP's Script-Fu

GIMP can merge JPGs through its Script-Fu console (Filters > Script-Fu > Console) if you already have it installed. The scripting language is a Scheme dialect from 1997 - all nested parentheses - but it handles transformations during the merge better than ImageMagick. Rotating every other image 90 degrees, adding 20 px borders between photos, or resizing inputs to a fixed width before joining is more readable as a Script-Fu procedure than piped shell commands.

The downside is performance. I batch-merged 40 product photos (3000x2000 each) on a 16 GB Windows machine and GIMP took 22 seconds - about 7x slower than ImageMagick. GIMP loads every image as a layer in RAM simultaneously and redraws the canvas preview after each operation. For straight vertical or horizontal joins, stick with ImageMagick.

XnView MP as a GUI alternative

XnView MP is what I recommend to people who hear "command line" and close the tab. Free for personal use, runs on Windows, Mac, and Linux. The merge function lives under Tools > Create Contact Sheet - confusing name, but it is effectively a grid merge tool. Set columns to 1 for vertical, pick spacing and background color, hit Create.

I tested it with 50 scanned documents at 300 DPI and it rendered in about 4 seconds on an i5-12400. The limitation: XnView MP uses strict uniform cell sizes, so images with different aspect ratios get padded with background color instead of packing tightly. ImageMagick's -append packs images flush regardless of size, which looks cleaner for documents and receipts.

Method 3: Programming languages (best for automation)

If you merge images as part of a larger workflow - generating reports, processing uploads, building catalogs - writing code gives you full control.

Python with Pillow (the most common approach):

from PIL import Image
import os

files = sorted(f for f in os.listdir('.') if f.endswith('.jpg'))
images = [Image.open(f) for f in files]

total_height = sum(img.height for img in images)
max_width = max(img.width for img in images)

merged = Image.new('RGB', (max_width, total_height))
y = 0
for img in images:
    merged.paste(img, (0, y))
    y += img.height

merged.save('merged.jpg', quality=92)

This script vertically stacks all JPGs in the current directory. For 20 images at 4032x3024, it runs in about 2.1 seconds on an M1 MacBook. Memory usage peaks at around 1.4 GB because Pillow holds all images in RAM simultaneously. For very large batches, load and paste one image at a time instead of building the full list first.

Which method to pick

Common mistakes when merging JPG files

Mixing wildly different resolutions

A 4000 px wide photo next to a 640 px screenshot creates an awkward composition. The small image floats in padding, and the output file is dominated by dead space. Resize to a consistent width before merging, or use grid layout which handles mixed sizes better than vertical/horizontal stacking.

Forgetting about color profiles

Phone cameras save JPGs in Display P3 color space. Screenshots use sRGB. When you merge them, the Canvas API converts everything to sRGB, which can shift colors slightly on wide-gamut photos. If color accuracy matters (product photography, design work), convert all images to sRGB before merging. On Mac, use sips --matchTo '/System/Library/ColorSync/Profiles/sRGB Profile.icc' *.jpg.

Using 100% quality when you do not need it

The difference between 92% and 100% JPG quality is invisible to the human eye in most photos, but the file size difference is 2-3x. A merged image of 20 photos at 100% can hit 60+ MB - too large for most email attachments (25 MB limit) and slow to load on web pages. Use 92% as your default and only bump to 100% for archival or print production.

Merging JPG files on mobile - what actually works

Half the time I need to merge images I am standing in a parking lot combining photos of a fender bender for an insurance claim. Phone merging has problems that desktop users never hit.

iOS limits

Safari on iOS 17/18 caps each tab at roughly 1.2-1.4 GB of memory on 6 GB iPhones (iPhone 15 Pro, 16 Pro). A single 12 MP photo decodes to about 48 MB as a raw bitmap, so you can merge around 20-25 photos before Safari silently reloads the tab and your selections vanish. On the iPhone SE 3rd gen (4 GB RAM), that drops to 12-15 images. I lost a 20-image merge three times on an SE before realizing the crash happened during canvas rendering.

A useful shortcut: long-press a photo in Files or Photos, tap Copy, then paste directly into a browser merge tool. Skips the file picker and the iOS Photos permission prompt. Saves about 5 seconds per image.

Android limits

Chrome on Android degrades gracefully instead of crashing - the UI freezes for 2-3 seconds at a time, then Android's low-memory killer terminates the tab. A Samsung Galaxy S23 (8 GB RAM) handled 40 rear-camera photos. A Pixel 6a (6 GB RAM) topped out around 30. Budget phones with 3-4 GB RAM (Moto G Power, Samsung A14) struggle past 10-15 full-resolution photos.

Watch for the Google Photos file picker quirk: selecting JPGs from Google Photos triggers full-resolution downloads from cloud storage. Thirty offloaded photos means 200+ MB of downloads before the merge starts. Pick from "Files" instead of "Photos" in the picker to use local copies.

Safari vs Chrome rendering

Safari converts Display P3 to sRGB during canvas drawing, shifting reds and greens by a few percent. Chrome preserves sRGB as-is. Photos merged in Safari may look slightly less saturated on non-Apple screens.

The bigger issue: Safari caps canvas size at 16384 x 16384 pixels. Stack 7+ full-resolution iPhone photos vertically (each 4032 px tall) and the canvas silently renders blank - white output, no error. Chrome allows 32767 x 32767. Resize inputs to 50% when you hit this on Safari.

File naming and organization before merging

The order images appear in the merged output depends on how your tool sorts input files. Get this wrong and page 3 ends up before page 1.

Sort order traps

Most tools sort alphabetically, so image2.jpg comes after image19.jpg (the character "2" has a higher ASCII value than "1"). The fix: use zero-padded names like 001-front.jpg, 002-back.jpg, 003-detail.jpg. A shell command handles bulk renaming:

ls *.jpg | cat -n | while read n f; do mv "$f" "$(printf '%03d-%s' $n "$f")"; done

EXIF date sorting vs filename sorting

Some tools sort by "date taken" from EXIF metadata. This breaks when you mix photos (with EXIF dates) and screenshots (often no EXIF date at all). The tool puts dateless images at one end, scrambling your intended order. I hit this merging product photos with annotated screenshots - the screenshots all clustered at the end because their DateTimeOriginal field was empty.

Filename sorting is more predictable. You control the names, so you control the order.

How different tools handle ordering

Browser tools use file picker order. On macOS, Finder reorders to match its sort regardless of click sequence. On Windows, Ctrl-click selection order is preserved. Same files, different merge order depending on OS.

ImageMagick's *.jpg glob uses locale-dependent shell sorting. Mixed-case filenames (IMG_001.jpg and img_002.jpg) sort differently in en_US vs C locale. Use magick convert @filelist.txt -append merged.jpg with an explicit file list to guarantee order. Python's os.listdir() is even worse - the return order varies by OS (random on ext4 Linux, alphabetical on macOS APFS). Always wrap it with sorted().

Merging JPG files for specific use cases

Bug reports and QA screenshots

QA engineers merge screenshots vertically to show a sequence of steps that reproduce a bug. A typical flow - login screen, dashboard, broken modal, console error - becomes four screenshots stacked into one scrollable image. This beats attaching four separate files because reviewers see the full reproduction path without clicking through attachments.

Jira caps file attachments at 10 MB by default. Four full-resolution screenshots from a 1440p monitor at 100% JPG quality produce about 3-4 MB each, so a naive vertical merge hits 12-16 MB and gets rejected on upload. The fix: merge at 80% quality. Pixel-perfect fidelity does not matter for bug reports - you need the UI elements readable, not color-accurate to the last sub-pixel. At 80%, those same four screenshots merge into a 2-3 MB file.

E-commerce product grids

Amazon requires the main product image to be at least 1600 px on the longest side for zoom functionality to activate. Sellers who upload images below that threshold lose the zoom feature entirely, which Amazon's own data shows reduces conversion rates. A 2x2 grid of four 1200 px product photos produces a 2400 px output - well above the minimum and sharp enough for zoom.

eBay's listing templates favor 3x3 grids showing the product from nine angles. Nine photos at 1000 px each in a 3x3 grid create a 3000 px square output, typically 2-4 MB at 92% quality. White backgrounds compress much smaller than textured ones - a watch on marble might be 4 MB while the same watch on white drops to 1.8 MB.

Before-and-after comparisons

Real estate agents merge renovation photos side by side. Fitness coaches merge progress photos at 30-day intervals. Design teams merge UI mockups next to production screenshots. All of these are horizontal merges where the comparison breaks if the two halves do not line up visually.

The single most common mistake is merging two photos with different aspect ratios. A 4:3 "before" photo next to a 16:9 "after" photo creates a lopsided image where the shorter photo gets padded with dead space. Crop both photos to the same aspect ratio before merging. On a phone, this takes 10 seconds per photo in the built-in editor. The slight loss of content at the edges is worth it for a comparison that does not look crooked.

Document and receipt scanning

Vertical merge is the natural choice for multi-page receipts and scanned documents. The output reads top to bottom, same as the original paper. Expense reporting tools like Expensify and SAP Concur accept a single merged JPG more reliably than a multi-page PDF, which sometimes renders with missing pages on older systems.

The common mistake here is scanning resolution. Most phone scanning apps default to 600 DPI, which produces massive files for text documents that do not benefit from that level of detail. At 600 DPI, a standard letter-size page scans to roughly 5100 x 6600 pixels - about 33 megapixels per page. At 200 DPI, that same page is 1700 x 2200 pixels, the text is still perfectly readable, and the file size drops by about 9x. Five receipt scans at 600 DPI might total 40 MB before merging. The same five receipts at 200 DPI total under 5 MB. Use 200 DPI as your default for receipts and text documents, and save 300 DPI for pages with fine print or detailed diagrams.

What happens to EXIF data when you merge

Every JPG from a digital camera or smartphone carries EXIF metadata - GPS coordinates, capture date, camera model, lens focal length, aperture, ISO, and sometimes the owner's name. A single iPhone photo can contain 40-60 EXIF fields, all riding invisibly inside the file alongside the pixel data.

When you merge JPGs using a browser-based tool, the Canvas API draws pixels onto a blank canvas and exports a brand new JPG. That new file has no EXIF data at all. The canvas only knows about pixel colors - it has no mechanism to read, combine, or transfer metadata from the source images. The same applies to Python's Pillow library: Image.new() creates an image with empty metadata, and paste() copies pixels without touching EXIF fields.

For most use cases, this metadata stripping is a benefit. Merged images shared on social media or uploaded to bug trackers will not contain GPS coordinates from the originals. You do not need to run a separate metadata removal step - the merge itself handles it.

If you do need EXIF preservation - for photo archives, legal evidence chains, or professional photography workflows - ImageMagick can copy metadata from a source image to the merged output. Run magick convert merged.jpg -set exif:DateTimeOriginal "2026:01:15 14:30:00" output.jpg to set specific fields manually, or use exiftool -TagsFromFile source.jpg merged.jpg to clone the full EXIF block from one of the originals. This only makes sense when all source images share the same camera and session, since a merged image can only carry one set of metadata.