Convert PDF to PNG on Mac (Transparent, High-DPI)

Two routes, and which one you want depends on whether you care about the exact pixel size.

Preview, when you do not: open the PDF, go to the page, choose File → Export…, pick PNG from the Format menu, save. The menu on macOS 27 offers HEIC, JPEG, JPEG-2000, OpenEXR, PDF, PNG and TIFF. Preview exports the page you are looking at, one file at a time.

sips, when you do. The -Z flag sets the longest edge in pixels and renders the page at that size from the PDF’s own drawing instructions:

sips -s format png -Z 1584 artwork.pdf --out artwork.png

Both stop at page 1. If you need all 40 pages of a deck, that is a different job with a different tool, covered in converting PDF to JPG on Mac along with the Automator action that handles page count and file naming properly. The same action writes PNG — set its Format control to PNG instead of JPEG.

Sometimes, and it depends on two independent things: whether the PDF page actually has transparency, and which renderer you use on the way out. Both catch people.

A PDF page is not a white rectangle. It is a blank canvas with drawing instructions on it, and the whiteness you see in Preview is Preview choosing to draw white underneath. If nothing in the file paints the background, the area around your artwork is genuinely empty. If something does paint it – a Figma export with Include background ticked, an Illustrator artboard with a fill, an InDesign page with a full-bleed rectangle, or anything scanned – those pixels are real and no converter can remove them.

Same unpainted page, four routes, alpha sampled at the corner pixel:

That third row is the one that wastes an afternoon. A script or app that renders through NSImage hands you a file with a full alpha channel in which every pixel is opaque. It looks correct on a white artboard and wrong the moment it lands on a dark one.

Checking is harder than it should be, because sips -g hasAlpha answers the wrong question: it reports yes for both files above, since both carry an alpha channel. What you want is the value of a pixel you expect to be empty:

osascript -l JavaScript -e 'ObjC.import("AppKit"); const r = $.NSBitmapImageRep.imageRepWithContentsOfFile("/path/page.png"); console.log(r.colorAtXY(3, 3).alphaComponent)'

It prints 0 for a transparent corner and 1 for an opaque one. Those are the two readings in the table.

PDFs are measured in points, and one point is one pixel at 72 DPI. That single equivalence is the whole conversion between the two vocabularies designers and command-line tools use:

So “2×” and “144 DPI” are the same instruction in two dialects, and scale factor = DPI ÷ 72. For a one-off, take the page height in points, multiply by the scale, and feed it to -Z: a Letter page at 2× is 792 × 2 = 1,584.

Quick Look will also do scale factors directly, which is handy because it takes the multiplier rather than the arithmetic. -s sets the base size, -f multiplies it:

qlmanage -t -s 612 -f 2 -o ~/Desktop/out artwork.pdf

That produced a 945 × 1,224 px PNG named artwork.pdf.png, double extension and all. It is page 1 only, PNG only.

For a whole document at a chosen scale, with names that sort correctly, this script calls PDFKit directly. Save it as pdf-pages.js and pass it the PDF, an output folder, and a scale factor:

ObjC.import('Quartz')
ObjC.import('AppKit')

function run(argv) {
  const src = argv[0]
  const outDir = argv[1]
  const scale = parseFloat(argv[2] || '2')
  const doc = $.PDFDocument.alloc.initWithURL($.NSURL.fileURLWithPath(src))
  const pages = doc.pageCount
  for (let i = 0; i < pages; i++) {
    const page = doc.pageAtIndex(i)
    const box = page.boundsForBox(0)
    const size = $.NSMakeSize(box.size.width * scale, box.size.height * scale)
    const img = page.thumbnailOfSizeForBox(size, 0)
    const rep = $.NSBitmapImageRep.imageRepWithData(img.TIFFRepresentation)
    const name = 'page-' + String(i + 1).padStart(3, '0') + '.png'
    rep.representationUsingTypeProperties(4, $()).writeToFileAtomically(outDir + '/' + name, true)
  }
  return pages + ' pages at ' + scale + 'x'
}

osascript -l JavaScript pdf-pages.js ~/Desktop/deck.pdf ~/Desktop/out 2

Run against the 15-page test file at 2× it wrote page-001.png through page-015.png at 1,224 × 1,584 px each. The zero padding is the point: without it, every alphabetical sort on your Mac puts page 10 in front of page 2. Rename the output to [email protected] if it is going into Xcode or a CSS image-set(), since both infer the scale from that suffix. One caveat, from the table above: this route composites onto white. If you need the transparency, use sips.

Almost always because the page was rendered once at 72 DPI and enlarged afterwards in Figma, Photoshop or a CSS rule. Blowing up a 612 px-wide bitmap to 1,224 gives you the blur; the type in the PDF is vector and deserves better.

The fix is to re-render at the size you need instead of scaling the result. sips -Z does exactly that: rendered at 1,970 × 2,550 px, its output was visually indistinguishable from the same page drawn directly through PDFKit at that resolution – clean letterform edges in both, no interpolation softness. The rasterizer goes back to the vectors every time.

The second cause is subtler and produces a file that claims to be high-resolution and is not. sips -s dpiWidth 300 -s dpiHeight 300 writes 300 into the image’s metadata without changing a single pixel: the output stayed 612 × 792. Pixel dimensions are the only thing that carries detail. The DPI table in the JPG guide lays out what each setting is actually worth in megabytes.

When the page is a photograph. PNG is lossless, which sounds like an upgrade and is a liability on continuous-tone images: there is no quality slider to trade away, so the only lever on file size is pixel count. Same page, same pixel dimensions, both formats:

Reach for PNG on text, tables, charts, logos, UI, line art, and anything that needs transparency. Reach for JPG on scanned pages and photographic layouts. Two other limits worth knowing before a handoff: the PNG specification supports indexed-color, greyscale and truecolor images only, so a press-ready CMYK PDF gets converted to RGB on the way out and the color will shift; and for anything web-bound, WebP and AVIF beat PNG on both counts, keeping the alpha channel at a fraction of the bytes.

Straight answer first, because this is our software and you should be able to discount what we say accordingly. For a single page, Preview is free, installed, and three clicks. For an exact pixel size, sips is one line. For every page of one document, Automator or the script above. None of those is a case for buying anything.

Smol converts the first page of each PDF you give it to PNG or JPG at the page’s native size, preserving transparency – its output on the test file was byte-for-byte identical to the sips render. What it adds is throughput and what happens next: 30 PDFs went to images in 2,507 ms on the M2 Pro, and the same drop-in handles the part designers actually spend time on afterwards – batch-converting those PNGs to WebP or AVIF, resizing to a max dimension, stripping metadata, and compressing with quality control, all locally.

So the dividing line is honest and easy to state. Page extraction at a specific scale: use the free tools. A recurring pipeline where PDF pages become optimized image assets: that is the job an image pipeline on a Mac is for, and Smol is a one-time $29 with no uploads. And if the real problem is that the PDF itself is too big to send, converting it to images makes it worse: the 93 KB test document became about 10 MB of page images. Compress the PDF instead.