Initializing... drag & drop files here
Supports: PDF
Converting a PDF to .tif is really two decisions: how densely to rasterise the page, and which compression scheme to write inside the TIFF. The second one is where most conversions go wrong, because the Compression Type dropdown opens on JPEG, which is lossy — and a TIFF chosen for archiving, OCR or prepress is usually being chosen precisely because it should not be lossy. This page compares every scheme the converter offers, says which two to avoid outright, and shows where the quality slider has no effect at all.
Short answer: LZW for almost everything, Deflate if you want it slightly smaller, JPEG only for photographic pages where size beats fidelity.
| Scheme in the dropdown | Lossless? | What it is good at | Verdict for a rendered PDF page |
|---|---|---|---|
| LZW | Yes | The classic TIFF scheme; near-universal reader support | Best default. Safe for text, line art, colour and greyscale alike |
| DEFLATE | Yes | The zlib/ZIP algorithm; often a little smaller than LZW | Good second choice; slightly narrower support in very old software |
| PACKBITS | Yes | Simple run-length encoding, extremely widely supported | Fine for flat bilevel-ish pages, weak on photos or gradients |
| ZSTD | Yes | Modern, fast, compresses better than LZW | Good if your reader is current; older imaging software will not open it |
| NONE | Yes (no compression) | Maximum compatibility, no decode cost | Enormous files — a 300 DPI colour page runs to tens of megabytes |
| JPEG | No | Big savings on continuous-tone scans | Only for photographic pages; adds ringing around text and line edges |
| LOSSY | No | Duplicate label — it writes the same JPEG-compressed TIFF as the JPEG entry | Identical output to JPEG; nothing extra to gain by picking it |
| WebP | Configurable | Modern codec inside a TIFF wrapper | Small, but many TIFF readers cannot decode a WebP-compressed strip |
| CCITT Fax 4 | Yes, but bilevel only | Group 4 fax encoding, defined for 1-bit black-and-white data | Do not use here. See below |
| JP2K (JPEG 2000) | Configurable | JPEG 2000 codestream inside a TIFF | Do not use here. See below |
The two to avoid. CCITT Group 4 is defined in the TIFF 6.0 specification for bilevel (1-bit) imagery only — it is the fax encoding, and it has no way to represent a colour or greyscale raster. A rendered PDF page is a colour raster. Selecting Fax 4, or JP2K, leaves a tiny header-only TIFF behind that opens as an empty frame, and the job still reports as finished rather than raising an error. There is no bit-depth control on this path to convert the page to 1-bit first, so if you need bilevel Group 4 output for a fax gateway or an eDiscovery load file, produce a lossless TIFF here and let that system do its own bilevel conversion.
Even then, keep an untouched lossless copy. And remember JPEG-in-TIFF is a genuinely lossy encode: the page never round-trips back to what the PDF drew.
The Quality Preset dropdown maps to a numeric quality value handed to the encoder. That value only means something to a lossy scheme — under LZW, Deflate, PackBits or None the encoder has no fidelity knob to turn, so the preset makes no difference to the output at all.
| Quality Preset | Encoder quality value | Effect under JPEG | Effect under LZW / Deflate / PackBits / None |
|---|---|---|---|
| Highest | 100 | Largest, minimal artefacts | None |
| Very High (preselected) | 95 | Very close to the source | None |
| High | 90 | Good balance | None |
| Medium | 80 | Visible softening on text edges | None |
| Low | 70 | Obvious artefacts around glyphs | None |
| Very Low | 60 | Heavy artefacts | None |
| Lowest | 50 | Severe artefacts | None |
If you have chosen a lossless scheme and the file is still too big, the levers that actually move it are Conversion Quality (DPI) and Image resolution — not the quality preset.
None in the bytes. Both extensions name the same Tagged Image File Format; .tif survives from the era when Windows required three-character extensions, while .tiff was what Macintosh users wrote. The File extension selector on this page offers both and neither is preselected, so the output takes the extension the page is set up for unless you pick the other. The sibling page, PDF to TIFF, runs exactly the same conversion under the longer spelling.
Because JPEG produces the smallest file, and file size is what most casual conversions optimise for. It is a poor default for the reasons people usually want TIFF, so treat changing it to LZW as step one rather than an optional tweak. Nothing warns you afterwards — a JPEG-compressed TIFF looks like any other TIFF until you inspect it.
Because you are on a lossless scheme. LZW, Deflate, PackBits and None reproduce the pixels exactly, so there is no fidelity to trade and the quality value is simply ignored; the same page at "Lowest" and at "Highest" produces the same file. The preset only moves the output when the compression type is JPEG or another lossy codec.
Group 4 is a bilevel encoding — the TIFF 6.0 specification defines it for 1-bit black-and-white data — and a rendered PDF page is a colour raster it cannot represent. The result is a truncated, header-only file that opens as an empty image, and the job still reports as finished. Use LZW instead and let your fax or document-management system perform its own bilevel conversion.
300 DPI is the preselected value and the standard baseline for print and archival work. Push to 400 or 600 when the document has small or dense type and an OCR engine has to read it — the extra pixels cost only file size, not accuracy. Drop to 150 when the TIFF is only going to be looked at on screen. Above 600 DPI you are almost always just making the file bigger.
One TIFF per page, with a "Download All (Zip)" button for multi-page documents. TIFF the format can hold multiple images in one container — that is why fax and archival workflows like it — but this conversion writes them out separately. If a single multi-page container is the requirement, keep the PDF, or reassemble the pages with TIFF to PDF.
Not directly. There is no bit-depth control on this conversion path, so pages are written in colour at 8 bits per channel. Produce a lossless LZW TIFF at 300 DPI and let the receiving system binarise it — fax servers and eDiscovery platforms almost always have their own thresholding step, and theirs is tuned for the documents they ingest.
No. Rasterising converts vector glyphs into a fixed grid of pixels, so there is no text layer left to select, copy or search. That is inherent to every image format, not a limitation of this tool. Keep the PDF as the searchable copy, and if the TIFF has to become searchable later, run it through OCR — which is another reason to choose a lossless scheme and a generous DPI now.
A PDF stores text as font instructions and vectors that cost a few bytes each; a TIFF stores the finished picture, every pixel of it. A single US Letter page at 300 DPI is 2550 × 3300 pixels — over 8 million of them, in colour, before compression. Lossless schemes squeeze flat regions hard but cannot invent the compactness of vector text. If the size is a problem, lower the DPI first, then consider Compress TIFF.