Convert PDF to JPG on Mac

Pick by how many pages you need out, not by which app you like. That single question eliminates three of the five rows.

The uncomfortable summary: the free built-in tools cover almost every case, and the one case they cover badly is doing this across a folder every week. That is the honest division of labor and the rest of this guide sticks to it.

Preview, and nothing else comes close. Open the PDF, scroll to the page you want, then File → Export…, choose JPEG from the Format menu, name it, save. Apple documents those four steps in the Preview User Guide.

On macOS 27 that Format menu offers exactly seven things: HEIC, JPEG, JPEG-2000, OpenEXR, PDF, PNG and TIFF. It does not ask you for a pixel size or a DPI, which is fine when the image is going into a Slack message and fatal when it is going to a printer.

Two details people trip over. The export applies to the page you are currently looking at, not the document. Preview’s own window title spells this out, reading License.pdf – Page 1 of 15. And selecting several thumbnails in the sidebar does not change that.

Because a JPG holds one image and your PDF holds fifteen pages. Converting is not a format swap, it is a fan-out: one input file, N output files, which then need names, an order, and somewhere to live. Every tool that does this well is really solving the naming problem, not the rendering problem.

This is not new. The Apple Support Communities thread “Can I use preview to export multiple page PDF as jpeg for every page?” was posted on September 6, 2011, and the answer that stuck, from January 2012, was: use Automator. Fifteen years later, that is still the answer.

Two dead ends worth naming so you do not waste time on them. Deleting the pages you do not want from a duplicate of the file and exporting what is left works, and is genuinely the fastest thing for three pages. And the widely copied 2013 advice to use Print → PDF → Save PDF to Folder as JPEG is gone: /System/Library/PDF Services on macOS 27 contains only Save to Web Receipts, Save to iCloud Drive and Send in Mail.

Automator ships with macOS, and the action you need has been in the box a long time: its bundle still carries Apple’s 2005–2009 copyright. Open Automator, start a new Workflow (or a Quick Action if you want it in the Finder’s right-click menu), search the action list for Render PDF Pages as Images, and drag it in.

The action gives you four controls: Format, Color Model, Resolution in dots per inch, and a Compression slider running from Least to Best. Apple’s defaults, stored in the action bundle itself, are JPEG at 200 DPI with compression at 0.5. Add a Move Finder Items action after it or your images land in a temporary folder.

Run against the 15-page test file at 150 DPI, it produced 15 JPEGs of 1,275 × 1,650 px, the first one 722 KB. Which brings up the part nobody warns you about.

Apple knows. The action’s own bundle carries a note reading: “As the names of the resulting images are randomly generated, this action is often followed by the Rename Finder Items > Make Sequential action.” The names are no longer random on macOS 27, but the advice still holds. Add Rename Finder Items, set it to Make Sequential, and give it a base name with three-digit numbering. That one extra action is the difference between a folder you can hand to someone and a folder you have to re-sort by hand.

DPI is the only setting in this whole process that changes the answer, and the math is one line: pixels = page inches × DPI. A US Letter page is 8.5 × 11 inches, so 150 DPI gives you 1,275 × 1,650 px and 300 DPI gives you 2,550 × 3,300 px.

Here is the same page of text rendered three ways, measured. The JPEGs are quality 80, the PNGs are for comparison and explained in a moment.

Below 150 a body-text page is legible but soft the moment anyone zooms. Above 300 you are paying in megabytes for detail the source PDF may not even contain. If the page came from a 200 DPI scanner, exporting at 600 invents nothing.

One trap worth knowing because it silently produces the wrong file: sips -s dpiWidth 300 -s dpiHeight 300 does not render at 300 DPI. It writes 300 into the image metadata and leaves the pixels alone. Tested: the output was still 612 × 792 px, now carrying a label claiming otherwise. Pixel count is the thing. Everything else is a note attached to the file.

Yes, with sips, which has been in macOS since forever and needs no install. The basic form takes a PDF and writes a JPEG of the first page at the page’s natural size, which is 72 DPI:

sips -s format jpeg document.pdf --out page1.jpg

To choose the size, add -Z, which sets the longest edge in pixels and re-renders the page from the PDF’s vectors rather than enlarging a small bitmap. For a Letter page, 11 inches × 150 DPI is 1,650:

sips -s format jpeg -Z 1650 document.pdf --out page1.jpg

JPEG quality goes through -s formatOptions, which the sips manual page documents as taking low, normal, high, best, or a percentage. On the test page at 72 DPI: 30 produced 99 KB, the default 224 KB, and best 412 KB, all of the same page.

A folder of PDFs, first page of each, at 150 DPI:

for f in *.pdf; do
  sips -s format jpeg -Z 1650 "$f" --out "${f%.pdf}.jpg"
done

Now the limitation, because it is the reason half the Stack Exchange answers about sips are wrong: sips only ever converts page 1. Handed the 15-page test file, it writes one image and exits cleanly, with no warning that fourteen pages went nowhere.

Quick Look can do the same job through qlmanage, Apple’s Quick Look debugging tool. It renders page 1 only, always writes PNG, and names the output after the whole input filename, so document.pdf becomes document.pdf.png:

qlmanage -t -s 1650 -o ~/Desktop/out document.pdf

It is fast and it is fine for cover thumbnails. It is not a conversion pipeline, and Apple never claimed it was.

This is the one case the built-ins handle badly: not 15 pages of one document, but the first page of 300 documents, every week, with the results named predictably.

Smol does that in one drop: select the PDFs, choose Convert, pick JPG or PNG. Measured on the M2 Pro: 30 PDFs converted in 2,507 ms, about 84 ms per file, with each output named after its source. Be clear about what it converts, though: the first page of each PDF, at the page’s native size. For all 40 pages of one deck, Automator is the right tool and it is free.

If the same folder job runs on a schedule, the AI route is worth knowing: Smol ships an MCP server, so Claude Code, Codex, and Google Antigravity can drive conversion, batch compression, and resizing directly, each one click to enable in the AI access panel as of Smol 1.0.35. “Convert every PDF in ~/Invoices to JPG, then compress them for the web” becomes one instruction instead of a workflow you maintain. Details on the Smol MCP page.

The honest caveat that applies to every tool here: turning a PDF into images makes it bigger, not smaller. The 93 KB, 15-page test file became roughly 10 MB of JPEGs at 150 DPI. One page as a JPEG was 224 KB – more than twice the entire original document. If you are converting because the PDF is too large to email, you want the opposite operation: compress the PDF on your Mac and keep it a PDF, or run a whole folder of PDFs through compression at once.

Often not. JPEG was built for photographs, and most PDF pages are text, rules, tables and flat fills — exactly the content JPEG handles worst, ringing faintly around every letterform while spending bytes doing it.

Both formats, rendered from the same two pages at the same pixel size, measured:

So: scanned pages, photo-heavy brochures and anything with gradients go to JPG. Text pages, contracts, charts, screenshots of type and anything with large flat areas go to PNG, where they come out both smaller and sharper. PNG also keeps transparency, which matters if the page is going into a design file. That, plus retina exports, is covered in converting PDF to PNG on Mac.

For one page, Preview wins outright. It is already installed, it is three clicks, and paying for software to do it would be silly. Use it.

For every page of a single PDF, Automator wins. It is free, it handles page count properly, its DPI field does what it says, and with a Rename Finder Items action stapled on it produces a correctly ordered folder. Smol converts the first page of each file, so it is the wrong shape for that job.

For a first-page thumbnail inside a script, sips or qlmanage is a one-liner with no dependency and no license.

Where Smol earns its $29 is the fourth case: a recurring folder job, where you also want the resulting images resized, converted to WebP or AVIF, stripped of metadata, and compressed properly, the same work described in compressing images on a Mac. That is a different problem from “turn this page into a picture”, and it is worth being clear which one you actually have. If it is the recurring one, Smol is a one-time $29 and runs entirely on your Mac.