Batch Convert HEIC to JPG on Mac

Everything in this table except Smol is already installed on your Mac. Same 500 files, same disk, page cache warmed before each run.

Two results are worth pausing on. The free command-line route is the fastest thing on the list, and the three free routes produce byte-identical JPEGs — verified with cmp, because Automator’s action and sips are both thin wrappers over the same ImageIO encoder. There is no hidden quality difference between them to shop for.

One route is missing from that table on purpose. Converting during the import from the phone is real and it is covered below, but it needs an iPhone on the end of a cable, so there is no comparable wall-clock number for it.

The other result is that every one of these routes makes your library bigger. 605.9 MB of HEIC became 989.6 MB of JPEG, a 63% increase, because you are throwing away a 2013 video codec’s worth of compression to buy compatibility. Plan disk space before you start, not after.

sips ships with macOS, needs no install, and takes a list of files plus an output directory. That second part is the bit most guides get wrong, because they hand you a loop when you do not need one:

mkdir -p converted
sips -s format jpeg *.heic --out converted/

One process, 500 files, 39.0 seconds. It renames the extension for you, so IMG_0042.heic lands as IMG_0042.jpg. Two cosmetic wrinkles that make people think it failed: it prints Warning: Output file suffix changed to jpg once per file, which is the tool telling you it did the right thing, and the progress lines underneath echo the output path still wearing a .heic extension. Exit code is 0 and the folder is correct. Ignore the console.

The loop everyone copies off Stack Exchange does the same work and takes twice as long, because it pays for 500 process launches instead of one:

for f in *.heic; do
  sips -s format jpeg "$f" --out "converted/${f%.heic}.jpg"
done

Measured: 81.5 seconds against 39.0. Identical bytes out. The loop is worth writing only when you need per-file logic, such as a different output name or a quality that depends on the source.

If you want the machine to work properly, hand the loop to xargs and let all ten cores run:

mkdir -p converted
ls *.heic | xargs -P 8 -I{} sh -c \
  'sips -s format jpeg "{}" --out "converted/$(basename "{}" .heic).jpg"'

16.7 seconds for the same 500 files, a 4.9× speedup over the serial loop, output again byte-identical. Eight was the sweet spot on a 10-core M2 Pro; going higher mostly fights over memory bandwidth.

To control quality rather than accept the default, add -s formatOptions, which the sips manual documents as taking low, normal, high, best, or a number. And if you want the JPEGs smaller as well as converted, resize in the same pass with -Z, which sets the longest edge in pixels:

sips -s format jpeg -s formatOptions 80 -Z 2048 *.heic --out converted/

Yes, and almost nobody knows it. Select the HEIC files in the Finder and press ⌘O. Preview opens them as separate documents inside a single window, one thumbnail each in the sidebar, which we confirmed by asking Preview itself: five files opened this way reported five documents and one window. Click any thumbnail, press ⌘A to select every one of them, then go to File → Export Selected Images…. That menu item only appears when more than one thumbnail is selected; with a single image the same slot reads Export As….

The export panel is the standard macOS image save panel, and it gives you more control than any other free route: a Format menu, a Quality slider running from Least to Best with a live File Size readout beside it, a Resolution field, and an Alpha checkbox. Choose JPEG, drag the slider, pick a destination, done.

The catch is the getting-there. Opening the 500-file test folder took Preview 20.8 seconds before the export menu was even reachable, and left the app sitting on 262 MB of resident memory. At that scale it also asks you to confirm overwrites one prompt at a time, with a dialog reading “All 500 files already exist. Do you want to replace them?” if you export twice into the same folder.

For a dozen photos Preview is the right answer and I would not reach for anything else. For five hundred, the twenty seconds of thumbnail generation is the whole problem, and a command that takes 39 seconds end to end has already finished.

It is the most convenient route on this page and it has a default that will cost you your originals. Open Automator, create a new Quick Action, set it to receive image files in Finder, and drag in Change Type of Images, then set To Type to JPEG. Save it, and it appears in the Finder’s right-click menu under Quick Actions.

Run against the 500-file corpus through the automator command-line tool it finished in 72.3 seconds and produced JPEGs byte-identical to the sips output. It also left the folder holding zero HEIC files. The action converts in place and deletes what it converted.

Apple knows, and warns you exactly once. The moment you drag the action into a workflow, Automator raises a sheet reading: “This action will change the image type of the image files passed into it. Would you like to add a Copy Finder Items action so that the copies are changed and your originals are preserved?” Click Add. If you clicked Don’t Add six months ago and forgot, your workflow is a shredder.

One more oddity worth knowing before you trust it with a camera roll. The action’s own description, stored in its bundle, lists the input formats it expects: “Image files of type BMP (.bmp), GIF (.gif), JPEG (.jpg or .jpeg), JPEG 2000 (.jp2), PDF (single page .pdf), PNG (.png), or TIFF (.tif or .tiff).” HEIC is not in that list. The bundle version is 1.1.1 and its copyright line still reads 2003–2012. It handles HEIC anyway, because it accepts anything macOS considers public.image, but nobody has revisited that text in the nine years since iPhones started shipping HEIC.

This is the route people mean when they say “use Image Capture”, and the credit is misplaced. Image Capture has no HEIC setting. Searching the app binary on macOS 27 for the strings HEIF, HEIC, JPEG and Keep Original returns nothing at all.

The conversion is done by the phone. Apple’s own documentation puts it plainly: “When you import HEIF or HEVC media from an attached iPhone or iPad into Photos, Image Capture, or a PC, the media might be converted to JPEG or H.264. If you don’t want it to be converted, open Settings, tap Apps, tap Photos, then scroll down and tap Keep Originals.” On the phone that control sits under a heading reading Transfer to Mac or PC, with two options, Automatic and Keep Originals.

So the cleanest batch conversion on this whole page is the one you never run: set the iPhone to Automatic, plug it in, import, and the JPEGs arrive already transcoded, with no second step to script and nothing to clean up afterwards. The limit is obvious. It only helps for photos still on the phone. For the folder of HEIC someone AirDropped you last week it does nothing at all.

Why the phone shoots HEIC in the first place, and whether you should turn that off, is its own question. We answer it in why your iPhone photos are .HEIC.

Because two different dates live on every photo and only one of them survives a conversion. This is the single most common complaint about batch HEIC conversion and the explanation is not the one most pages give.

The EXIF capture date is fine. Tested across every route on this page, with the source HEIC carrying a full iPhone tag set:

What breaks is the filesystem date. A converter writes a brand new file, and a brand new file is born today. Test case: a HEIC whose creation and modification times were both set to 13 July 2024 produced a JPEG stamped with the current second, on every route tried. Finder’s Date Created column, Google Drive’s sort order, Windows Explorer and most cloud backups all read that number, which is why a freshly converted camera roll looks like it was all shot this afternoon.

Photos.app and Lightroom read EXIF, so importing the JPEGs into either of those puts everything back in order. If you are handing the folder to someone who will just look at it in the Finder, push the EXIF date back onto the file with ExifTool:

exiftool -overwrite_original \
  "-FileModifyDate<DateTimeOriginal" \
  "-FileCreateDate<DateTimeOriginal" \
  converted/*.jpg

Verified on the test file: creation and modification times both went back to the original capture time. Run it once at the end of the batch, not per file.

The mirror image of this problem is when you want that data gone before sharing a folder. That is a different job and a separate operation entirely, because converting a HEIC to JPEG carries your GPS coordinates straight through.

Three things, and the first one is the reason converted photos sometimes look flatter than the originals on the same screen.

HDR gain maps. A modern iPhone photo carries a second image alongside the picture, tagged urn:com:apple:photo:2020:aux:hdrgainmap, which tells a capable display how far above SDR white each region should be pushed. Taking one untouched 4032 × 3024 iPhone 15 Pro Max HEIC and converting it four ways, the gain map was gone from the JPEG every single time: sips, Automator, Preview and Smol all wrote a single-image JPEG. The HDRHeadroom tag inside the Apple maker note survives, which is misleading, because the pixel data it refers to does not. If HDR rendering matters, keep a copy of the HEIC.

Live Photos. Apple’s Photos User Guide is explicit: a Live Photo “is exported as two separate files: a still-image file and a video file”. Convert the HEIC and you convert half of a pair; the .MOV sitting beside it is untouched and now orphaned, because nothing re-links a JPEG to a movie on import. Either delete the movies deliberately or keep them together, but decide, because a folder of stray three-second .MOV files is how people end up assuming a conversion corrupted something.

Everything else in the container. HEIC is a container format, not just a compressed picture, and Apple uses that. Portrait shots carry depth information, burst captures carry multiple frames. A JPEG holds one image. Whatever else was in the box does not make the trip.

One of them stops existing, silently, and this is the failure mode that bites hardest when you are consolidating several years of exports into one output folder. iPhone filenames wrap: IMG_0001.HEIC comes around again every ten thousand shots, and every phone in the house starts at 1.

Tested directly. Two different HEIC files, both written to the same output path with sips: the first produced a 1,350,900-byte JPEG, the second overwrote it with a 2,819,530-byte JPEG. No warning, no prompt, no non-zero exit code. Automator behaves the same way, because it is the same encoder underneath.

Three ways out, in increasing order of effort. Convert in place so each file stays in its own folder and there is nothing to collide with. Or flatten the names first, which is what Automator’s Rename Finder Items action set to Make Sequential is for. Or use something that refuses to overwrite: Smol writes IMG_0001_converted 2.jpg rather than clobbering IMG_0001_converted.jpg, which we confirmed by running the same conversion twice into the same folder.

The general rule for any batch job: never let a converter write into a folder that already has things in it that you care about.

Not for raw speed. Smol converted the same 500 files in 191.9 seconds against 39.0 for the one-line sips command, and it wrote 1.46 GB where sips wrote 989.6 MB. That gap is a deliberate difference in defaults rather than a performance bug: checked with ImageMagick, sips writes 4:2:0 chroma subsampling and Smol writes 4:4:4, so Smol keeps full color resolution and pays for it in bytes. If all you want is JPEGs out of a folder of HEIC, the Terminal is faster and it is free. Say so out loud before spending money.

What you buy instead is the rest of the job in the same pass: a quality slider, a resize, a metadata strip, an output format that is not JPEG, and a Finder right-click that runs it without a Terminal window. The Compress with smol Quick Action installs into ~/Library/Services/ and reads the app’s current settings, so once you have set the output format to JPG, converting a selection is a right-click with no app launch at all. Watched folders take it further: drop HEIC in, get JPEG out, forever.

The batch case is also where driving this from an AI agent stops being a novelty. Smol ships an MCP server, so Claude Code, Codex and Google Antigravity can run conversion, compression and resizing directly — one click to enable in the AI access panel as of Smol 1.0.35. “Convert every HEIC in ~/Trip to JPG at quality 80, cap the long edge at 2048, then restore the capture dates” becomes one instruction, with the agent chaining Smol’s conversion and the ExifTool pass above it rather than you getting four commands right in order. Every Smol measurement on this page was produced that way. The guardrails are real, too: hand the tool a folder path instead of files and it refuses with Input must be a file. The tool surface is listed on the Smol MCP page.

For a handful of files, use Preview. Select them, open them, ⌘A, File → Export Selected Images…, pick JPEG, set the quality slider, save. It is already installed, it gives you a live file-size readout while you drag the slider, and it takes about fifteen seconds. Paying for software to do that would be silly.

For a scripted or scheduled job, use sips. It is on every Mac, it has no dependencies, it is the fastest thing measured here, and it drops straight into a shell script or a cron job. A build pipeline that needs JPEGs from HEIC should not shell out to a GUI app.

If the files are still on your iPhone, change the phone setting. Settings → Apps → Photos → Transfer to Mac or PC → Automatic, then import. No conversion step, no date repair, nothing to script.

Where the $29 earns itself is the recurring folder job where JPEG is only half the request: the same photos also need resizing for a site, or compressing to fit an upload cap, or converting to WebP for one destination and JPEG for another, or stripping GPS before they leave the building. That is the work described in compressing images on a Mac, and it is a different problem from “change the extension on this folder”. The document version of the same job is compressing a PDF on a Mac, where the built-in Quartz filter can hand you back a larger file than it was given. If the recurring folder is the problem you have, Smol is a one-time $29 and never sends a photo anywhere.

For the single-file version of this job, with screenshots, our step-by-step HEIC to JPEG guide is shorter and more useful than this page. If your target is PNG rather than JPEG, read converting HEIC to PNG first, because for photographs it is usually the wrong choice and the file size is brutal.