This tool converts PDF pages into lossless PNG images — free, in your browser, with the file never uploaded anywhere. PNG is the format you reach for when detail matters: unlike JPEG, it does not blur text edges or introduce artifacts around sharp lines. Every pixel comes out exactly as rendered. If you are extracting pages from a PDF for use in design software, documentation platforms, or anywhere that demands visual fidelity, PNG is the right output.

When to use this tool

PNG output makes sense in situations where lossless quality or transparency matters more than file size.

Choose PDF-to-PNG when:

• You are extracting diagrams, charts, or technical illustrations that have crisp lines and flat colors
• The output will be composited over another background in Figma, Photoshop, or a web page
• You are archiving document pages and want zero degradation from the rendered original
• The PDF contains UI mockups, wireframes, or screenshots where compression artifacts would be distracting
• You need to OCR the output later and want maximally clean pixel data to feed the recognition engine

Stick with JPG when file size is your primary concern, when the pages are photographs or scans with continuous tones, or when you are uploading somewhere with strict size limits.

How PDF-to-PNG conversion works

The rendering pipeline is identical to JPG conversion up to the final encoding step. The difference lives entirely in how the pixel data is compressed and what channels it retains.

Parsing and rendering. PDF.js reads the file's cross-reference table, locates page objects, and interprets the content stream operators. Each operator maps to a canvas drawing call: moveTo, lineTo, fillText, drawImage. The canvas accumulates the full page appearance one operator at a time.

The alpha channel difference. When we create the canvas for PNG output, we do not pre-fill it with white. The canvas starts fully transparent (RGBA with alpha = 0 everywhere). As PDF operators draw content, pixels become opaque. Any region the PDF does not explicitly paint remains transparent. This is how PNG preserves transparency for pages without backgrounds.

For JPG output, we fill the canvas with white first because JPEG cannot represent transparency. For PNG, we preserve the raw alpha state.

Lossless encoding. After rendering, we call canvas.toBlob('image/png'). The PNG encoder applies DEFLATE compression (the same algorithm behind ZIP files) to the raw pixel data. It does not discard any information. A pixel that rendered as RGB(47, 128, 201) stays exactly that value in the output file.

PNG also applies row filters before compression — mathematical transformations of each row of pixels that make the data more compressible. The encoder picks the filter that yields the smallest result for each row. This is why PNG compression ratios vary so much depending on image content: a page of solid white with a few lines of text compresses extremely well, while a full-bleed photograph barely shrinks at all.

File size implications. Lossless compression means PNG files are often 3 to 10 times larger than equivalent JPEGs. A text-heavy page at 150 DPI might produce a 400 KB PNG versus a 90 KB JPG. A full-page photograph at 300 DPI could easily produce a 4 MB PNG versus a 500 KB JPG. This is the tradeoff: perfect quality at the cost of storage.

Resolution and memory considerations

The memory math for PNG is identical to JPG — the canvas requires width times height times 4 bytes regardless of output format. What differs is the output file size and the encoding time.

At 150 DPI, a letter-size page creates a 1275 by 1650 canvas using about 8 MB of RAM. This is comfortable for any modern device, and you can process dozens of pages without concern.

At 300 DPI, the canvas grows to 2550 by 3300 pixels, consuming roughly 33 MB per page. Most laptops and phones with 4+ GB of RAM handle this fine, but you will notice the per-page processing time increase.

At 600 DPI, each page demands over 130 MB of canvas memory. This is where things get precarious. A device with 8 GB of total RAM may struggle, especially if other tabs are open. We cap our maximum at 600 DPI because going higher provides negligible benefit — you have already exceeded the resolution of the source content in virtually all PDFs.

A practical rule: if your PDF was created from digital content (Word documents, presentations, design files), 300 DPI captures 100% of the meaningful detail. Going higher just creates larger files with no visible improvement. Only scanned documents with embedded high-resolution images might benefit from 600 DPI, and even then, only if the scan itself was done at that resolution.

Common issues

Enormous file sizes. This is the most frequent complaint. A 20-page PDF that is 2 MB can produce 40 MB of PNG files at 300 DPI. The PDF is small because it stores instructions, not pixels. The PNG is large because it stores every rendered pixel losslessly. If size is a problem, reduce DPI or switch to JPG for photographic pages.

Browser tab crashes on high-resolution export. This happens when canvas memory allocation fails. Each page at 300 DPI needs 33 MB. Processing 20 pages sequentially should work because we release each canvas after encoding, but if you see crashes, try closing other tabs to free memory or reducing DPI.

Color shifts from the original PDF. PDFs can specify colors in CMYK, Lab, or ICC-based color spaces. The canvas API operates in sRGB. Conversion between color spaces is handled by the rendering engine and is generally accurate, but saturated CMYK colors sometimes appear slightly muted in sRGB. This is a fundamental limitation of the sRGB gamut, not a bug.

Font rendering inconsistencies. Different browsers and operating systems render the same glyphs differently. Sub-pixel rendering, hinting algorithms, and anti-aliasing strategies all vary. If you need absolute consistency across runs, use the same browser on the same OS each time.

Slow encoding for complex pages. Pages with many small vector elements (dense charts, maps, complex illustrations) take longer to render than simple text pages. The rendering time is proportional to the number of drawing operations, not the visual complexity as perceived by your eye. A page with 10,000 tiny paths takes much longer than a page with a single large photograph.

What to expect from our tool

Each page becomes a standalone PNG file. Multi-page documents produce a ZIP archive. File naming follows a zero-padded numbering scheme (page-01.png, page-02.png, and so on) to ensure correct alphabetical sorting.

Transparency is preserved by default. If you prefer a white background (for example, to match what the page looks like in a PDF viewer), there is an option to composite onto white before export.

Processing speed on a modern machine: roughly half a second per page at 150 DPI, one to two seconds per page at 300 DPI. These times are dominated by the canvas rendering step. The PNG encoding itself adds only a small fraction.

One practical note: if you need both PNG and JPG outputs, you do not need to process the PDF twice. Convert to PNG first (lossless), then convert those PNGs to JPG using any image tool. Going the other direction — JPG to PNG — gives you no benefit because the JPEG compression damage is already baked in.