PostScript to TIFF Converter
Initializing... drag & drop files here
Supports: PS
Advanced Options - Our defaults are optimized for the best results. We recommend you keeping the defaults unless you have a specific need.
Reset to defaults
Need help?PostScript to TIFF: the Route That Works
PostScript and TIFF are both prepress veterans — Adobe's page-description language on one side, the bitmap that print and archival workflows have passed around since the late 1980s on the other — so turning a .ps page into a high-resolution TIFF is a natural request. There is one catch worth knowing before you upload. A .ps file has to become a PDF first: this page hands your file to our PDF page renderer, which parses PDF structure (a file starting %PDF-) and rejects a PostScript program (%!PS-Adobe-…), so a genuine PostScript upload ends in an error rather than a TIFF. Produce the PDF yourself with Ghostscript and the rest of the route is well travelled — PDF to TIFF is the same renderer with the same Compression Type and Conversion Quality controls described below.
How to Convert PostScript to TIFF
- Make a PDF From the
.psFirst: Runps2pdf input.ps output.pdfon your own computer, or open the file in any application that can print it and choose "Save as PDF".ps2pdfis a thin wrapper over Ghostscript's pdfwrite device, which is free on Windows, macOS and Linux and is the reference implementation for this step. - Upload the PDF to the TIFF Converter: Open PDF to TIFF, drag the PDF in or click "Add Files", and queue as many documents as you like.
- Choose Compression Type, Then Conversion Quality: Compression Type opens on JPEG, which is lossy — switch it to LZW or Deflate for a bit-exact page. Conversion Quality is the render DPI (72 to 1200, preselected at 300) and fixes the pixel dimensions; Image Transparency sets the fill colour for empty areas, and the File extension control writes
.tiffor.tif. - Convert and Download: Click Convert and save the result, or take a ZIP when the document has several pages. No sign-up and no watermark; files are uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours.
Compression Type: the Setting That Decides Everything
TIFF is a container, not one compression scheme, and the dropdown genuinely changes what you get. The default is the lossy one, so this is the control to touch first.
| Setting | Lossless? | Notes |
|---|---|---|
| JPEG (preselected) | No | DCT compression inside the TIFF. Smallest of the widely-readable options, but it re-encodes the page and softens sharp text edges. LOSSY in the same list is the same scheme under a second label. |
| LZW | Yes | The classic prepress choice — bit-exact and readable by essentially every TIFF tool. On a text page it typically lands between Deflate and PackBits for size. |
| Deflate | Yes | Same zlib algorithm as PNG. Usually the smallest of the traditional lossless options on rendered pages, and safer than LZW on high-bit-depth data. |
| PackBits | Yes | Simple run-length coding that every baseline TIFF reader must support. Maximum compatibility, weakest compression — expect several times the size of Deflate. |
| None | Yes | Raw pixels. A 300 DPI A4 page is roughly 26 MB uncompressed; pick it only when a downstream tool insists. |
| ZSTD / WebP | Yes | Modern additions to the TIFF spec. Efficient, but older readers and prepress RIPs may not understand them. |
| CCITT Fax 4 / JP2K | — | Do not pick these for a page render. Group 4 fax coding requires 1 bit per sample, and the JPEG 2000 scheme is not implemented for this writer; both leave a header-only file with no image data behind. |
The Quality Preset only reaches the JPEG (and WebP) encoder. Under LZW, Deflate, PackBits or None the presets are inert — we generated the same page at the Very High and Medium presets under LZW and the two files were byte-for-byte identical.
What Else Changes the Output
- Conversion Quality (DPI) is the real quality knob. A page description has no pixels of its own, so the DPI you choose is the resolution: 300 DPI turns an A4 page into 2480 × 3508 px, 600 DPI into 4961 × 7016 px. You cannot recover detail later.
- One TIFF per page. A multi-page document produces one image per page, delivered together as a ZIP. This route does not stack pages into a single multi-page TIFF, even though the format allows it — keep the PDF from step 1 if you need everything in one file.
.tiffand.tifare the same format. The File extension control only changes the name; some older Windows and prepress tools expect the three-letter form.- Image resolution rescales after rendering. Leave it on "Keep original" to get exactly what the DPI produced, or set a preset, a width, a height or a percentage to shrink a 600 DPI render without re-rendering it.
- Browsers are not the audience. Other than Safari, browsers do not display TIFF in web pages, per MDN's image format guide — TIFF is for editors, RIPs and archives.
PostScript and PDF, Side by Side
PostScript (.ps) |
||
|---|---|---|
| What the file is | A program that paints pages when executed | A static object graph with a cross-reference table |
| Header bytes | %!PS-Adobe-… |
%PDF-… |
| Needs to render | A full PostScript interpreter (Ghostscript) | A PDF parser |
| Page count known without running it | No | Yes, from the document catalogue |
| Accepted by our page renderer | No — this is why the extra step exists | Yes |
| Still produced by | Print drivers, imagesetter workflows, legacy spool dumps | Everything |
Frequently Asked Questions
Why does my .ps file fail here instead of producing a TIFF?
Because the file goes to a PDF parser, not to a PostScript interpreter. PDF parsing starts by looking for the %PDF- header and a valid trailer; a PostScript stream has neither, so the parse throws and the job reports an error with no partial output. Convert the .ps to PDF first — ps2pdf input.ps output.pdf — and then run PDF to TIFF, which is the same rasterizer with the same options.
My file is named .ps and it converted fine. What happened?
It was PDF data under a PostScript name. Renderers identify a file by its header bytes rather than its extension, so a PDF someone renamed to .ps is read as the PDF it is. That is worth knowing in reverse too: if a colleague sends you a .ps that opens in a PDF viewer, you already have the PDF and can skip the conversion step entirely.
Is the TIFF lossless?
Only if you ask for it. Compression Type opens on JPEG, which is lossy — the stored pixels will not match the rendered page exactly and fine type picks up ringing. Switch to LZW or Deflate (or PackBits, or None) and the pixels are preserved bit for bit. Rasterizing itself is still a one-way step: the vector page becomes a fixed grid at whatever DPI you chose.
Which compression should I use for print or archival hand-off?
LZW at 300 DPI is the conventional prepress pairing — lossless and readable by virtually every tool that has ever opened a TIFF. Choose Deflate when the file will sit in an archive and size matters more than reader age, since it usually compresses rendered pages better and handles high-bit-depth data more predictably. Keep PackBits in reserve for very old readers, and raise the DPI to 600 for fine line art.
Does a multi-page PostScript document become one multi-page TIFF?
No — you get one TIFF per page, bundled as a ZIP. The TIFF format supports multiple images in one file, but this pipeline writes each rendered page separately so nothing is silently dropped. If a single-file container is the goal, the PDF you created in the first step already is one.
What does the Quality Preset do when I pick a lossless compression?
Nothing. The preset maps to an encoder quality value (Highest 100, Very High 95, High 90, Medium 80, Low 70, Very Low 60, Lowest 50) and only the JPEG and WebP schemes have a quality dial to receive it. Under LZW, Deflate, PackBits or None the output is identical whichever preset is selected, so the DPI and the compression scheme are the only two settings that move the result.
Why should I avoid CCITT Fax 4 and JP2K in the list?
Both are real TIFF compression schemes, but neither works for a full-colour page render on this writer. Group 4 is a bilevel fax coding that requires one bit per sample, so a colour or greyscale render is rejected outright, and the JPEG 2000 scheme is not implemented for scanline writing. What lands on disk is a few hundred bytes of TIFF header with no image data — a file that opens as an error in every viewer.
How are my files handled, and how long are they kept?
The PDF you upload is sent over an encrypted connection and rendered on our servers; there is no offline mode for this conversion. Uploads and results are deleted automatically after a few hours, are never shared or made public, and no account is required. Output carries no watermark, and nothing is held back behind a sign-up.