Standard quality is 150 DPI — good for screen use and web. High quality is 300 DPI — suitable for printing. Both settings produce sharp, clear images.

Can I convert only specific pages?

Yes. Select individual pages or a range to convert only the pages you need, rather than the entire document.

What is the maximum PDF size I can convert?

The tool handles PDFs up to 50 MB. Very large PDFs may take 30–60 seconds to process.

Why is PDF to JPG useful?

Converting PDF pages to images lets you use the content in presentations, embed pages in web pages, or share pages as images without sharing the full editable document.

About PDF to JPG Converter

A magazine editor asked you for 'just the photo on page 7 of the press kit' and the PDF does not let you right-click extract the image cleanly — the source asset is buried in a content stream that needs rendering before it becomes a usable image. Or your team wiki only accepts JPG uploads in its WYSIWYG editor and you need to inline a single page of a product datasheet. This converter uses PDF.js (Mozilla's WebAssembly-based PDF renderer, the same engine Firefox uses to display PDFs) to rasterize each page onto a Canvas 2D context at your target DPI, then encodes the canvas to JPG via the native toBlob call. You pick a resolution — 72 DPI for web thumbnails, 150 DPI for screen previews, 300 DPI for print-ready output — and optional JPG quality (50-95, default 85). Each page becomes a separate JPG, batched into a zip when there are more than three pages. Everything happens in the browser tab with no server round trip, which matters because PDF-to-image conversion often runs over contracts and ID scans that should not be uploaded to a random SaaS.

When to use this tool

Extracting a hero image for a press release

A PR manager receives a 20-page media kit as a PDF with a cover image that needs to go into the press release template (which accepts JPG but not PDF). Convert just page 1 at 300 DPI for print-quality output, drop into the release template, verify the image is sharp in the printed proof.

Creating thumbnails for a document catalog

A knowledge-base admin maintains an internal library of 200 product datasheets. Generate a 72 DPI JPG thumbnail of each datasheet's first page (roughly 30KB each) for use as catalog cards in the browse interface — total thumbnail payload around 6MB, small enough to load inline on the catalog page.

Preparing pages for social media posts

A marketing coordinator has a whitepaper PDF and wants to pull three pages as carousel slides for LinkedIn. Convert at 150 DPI (sufficient for Instagram-quality display), quality 90 for high color fidelity, three JPGs totaling around 400KB that upload directly as carousel assets.

Including PDF content in a support ticket

A customer pastes a page of a product manual into a Zendesk ticket to point at a specific step. Zendesk's editor accepts images but not PDF attachments inline. Convert the relevant page to 150 DPI JPG, drag into the ticket, paragraph flows around the image naturally in the support thread.

Archiving PDFs as image stacks for legacy systems

A compliance team migrates PDF records into a legacy document management system that only accepts TIFF or JPG. Convert each page of each PDF to 300 DPI JPG for archival fidelity, upload into the DMS alongside the original PDF as both formats are required by policy.

How it works

1
PDF.js renders pages onto a Canvas element
Each page is loaded as a PDFPageProxy from the PDF.js document object, we create an HTMLCanvasElement sized to the page's physical dimensions in points scaled by DPI/72 (PDF internal unit is 1/72 inch), and call page.render(renderContext) which draws the vector content, images, and text onto the canvas context. The render is fully software-based — no GPU required — so it works identically on any device.
2
Canvas is encoded to JPG natively
After rendering, canvas.toBlob('image/jpeg', quality) triggers the browser's native JPEG encoder (libjpeg-turbo internally on Chrome and Firefox) to produce the output blob. Quality 85 is the default sweet spot — visually indistinguishable from 95 on most content but 30 percent smaller in bytes. Quality below 70 produces visible blocking on solid color areas; quality above 92 inflates file size without perceivable gain.
3
Multiple pages zip for single download
Single-page conversions download as a standalone JPG. Multi-page jobs build a zip via JSZip after each page completes rendering, then trigger one download. This avoids the browser's multi-download prompt that would ask for approval per file. Rendering happens sequentially rather than in parallel because PDF.js shares a single WASM heap per document — parallelizing would not speed up the overall wall time on most configurations.

Honest limitations

· Rasterization is lossy by definition — the output JPG is a pixel representation of the vector source, so zooming in beyond the rendered DPI shows aliasing and text blur that the original PDF would not exhibit.
· Very large or image-heavy pages may exhaust canvas memory on mobile browsers; iOS Safari in particular caps canvas size at ~16 megapixels, which means a Letter page at 300 DPI (8.5 * 300 * 11 * 300 = 8.4 MP) just barely fits and A4 at 300 DPI is right at the edge.
· Form fields and annotations appear in the rendered output as they visually display but become flat pixels — any interactive behavior (fillable fields, clickable links) is lost in the JPG.

Pro tips

Match DPI to the final output medium, not the source

A PDF's internal resolution does not cap the output image resolution — you can render a 72 DPI screenshot-captured PDF at 300 DPI and get a 300 DPI upscaled JPG. But upscaling synthesizes pixels that were not in the source, so for screenshot or low-DPI source PDFs, rendering above native resolution just wastes bytes. Rule of thumb: for print output (magazine, poster) use 300 DPI, for screen viewing use 150 DPI, for web thumbnails use 72 DPI, and never render above the source PDF's effective image resolution unless your audience specifically requires the higher DPI.

Use PNG for screenshots inside PDFs, JPG for photos

This tool produces JPG output, which is the right choice for photographic content (portraits, product photos, paintings) because JPG's lossy compression is designed for smooth color gradients. For PDFs whose content is itself screenshots, diagrams, or text-heavy pages, JPG artifacts appear as ringing around sharp edges. If the source is mostly screenshots, convert to PNG via a different tool instead, or accept a 10-20 percent size penalty by using JPG quality 95 to minimize the artifacts. The one-format-per-tool limitation is a simplification — some conversion jobs genuinely need PNG.

Render only the pages you need for large documents

Rendering a 500-page PDF at 300 DPI synthesizes 500 large canvases and can run for 3-5 minutes on a modern laptop while consuming several GB of heap. If you only need pages 42-58, specify that range up front — PDF.js loads only the requested pages, rendering completes within a couple of seconds, and memory stays low. This is especially important for batch jobs where you are converting many PDFs; always limit by range rather than converting everything and discarding output.

Frequently asked questions

What DPI should I use for my conversion?

Depends on where the JPGs will be used. For screen-only viewing (websites, email attachments, social media posts), 150 DPI is the sweet spot — it looks sharp on retina displays without ballooning file size. For print output (magazines, posters, marketing collateral), use 300 DPI which matches the standard print resolution. For thumbnails and web previews where file size dominates over detail, 72 DPI gives visible-but-compact previews. Rendering above 300 DPI rarely helps because most PDF content (especially embedded photos) is stored at 300 DPI or lower, so higher DPI just upscales existing pixels.

Why did my converted JPG come out blurry when the source PDF is sharp?

Usually a DPI mismatch. If the source PDF embeds a 300 DPI image but you rendered at 72 DPI, the output is downsampled — 72 DPI looks sharp at normal viewing distance on a screen but blurry when zoomed. Conversely, if the source is a 72 DPI screenshot-captured PDF and you render at 300 DPI, the tool upscales the pixels and the result is fuzzy because there is no additional detail to draw. For sharp output at any zoom level, render at the highest DPI the source supports; for practical delivery, render at the DPI appropriate to the target medium and accept that printed zoom-in inevitably softens.

Can the converter extract the original image from a PDF at full resolution?

Not reliably — the tool renders the page, which composites the image together with any overlaid vector graphics, text, and annotations. If the source PDF contains a clean embedded image (page is just the image, nothing else), rendering at the image's native DPI produces an output very close to the original. If the image has text or overlays, rendering captures them together as one flattened JPG. For true image extraction without re-rendering, Adobe Acrobat's 'Export to Image' feature or the poppler-utils 'pdfimages' CLI tool pulls the raw embedded image bytes directly from the PDF's object stream, which this browser-based renderer cannot do.

Is the conversion happening on a server?

No. Everything runs in your browser. PDF.js (Mozilla's WebAssembly PDF renderer) parses the file into JavaScript heap, HTMLCanvasElement handles the rendering, and canvas.toBlob produces the output JPG — all inside the tab. There is no fetch call that sends the PDF contents anywhere. You can verify this in the browser's devtools Network tab during conversion — zero outbound requests will contain file data. This matters when the PDF contains sensitive information (contracts, medical records, financial statements) that you cannot share with server-side conversion services without creating a privacy or compliance issue.

How large can the source PDF be before conversion slows down?

Rendering time scales roughly linearly with page count and quadratically with DPI. A 10-page PDF at 150 DPI converts in about 2 seconds on a modern laptop. A 100-page PDF at 300 DPI can take 30-60 seconds and consume 500MB of heap for the canvas data. Above 200 pages at 300 DPI, you may hit memory pressure on devices with 8GB or less — either render in smaller page ranges or drop to 150 DPI which cuts memory by 75 percent. For 1000-page industrial documents, a command-line tool like poppler-utils 'pdftoppm' is the better fit since it streams pages without holding all canvases in memory simultaneously.

PDF-to-JPG often follows other PDF operations. After pdf-splitter extracts a specific page range, converting those pages to JPG is the natural next step for web publishing or social media. rotate-pdf fixes orientation before rendering so the output images land right-side-up. When pages need to be edited visually before rasterization, pdf-editor adds annotations that will bake into the JPG output. And for the reverse direction — combining a batch of JPGs back into a PDF — the images-to-pdf tool is the complement, making this conversion reversible for content that needs to move between formats during a publishing workflow.