Convert EPS to TIFF
Two formats from the same era, meeting a workflow that still runs on both. An EPS holds drawing instructions; a TIFF holds pixels; and a surprising number of print, imaging and archival systems built in the 1990s expect exactly this handoff. The output is losslessly compressed, which is the part most converters get wrong.
Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.
Add to Chrome — freeDrop your EPS file here, or click to browse
Up to 50 MB. Deleted automatically after 30 minutes.
What it does
- Lossless after rasterization, LZW compressed
- About 180x smaller than uncompressed TIFF
- Rendered at 150 dpi, not the default 72
- Nothing to install
How to use EPS to TIFF
- 1
Add the EPS
Drop it in. Ghostscript interprets the PostScript, which is what makes an EPS readable with no design software at all.
- 2
Rendered, then written losslessly
Rasterized at 150 dpi and written as TIFF with LZW compression. Nothing is discarded after the rasterization.
- 3
Check the destination first
If it will accept a PDF, /eps-to-pdf keeps the vectors and is the better file. TIFF is for the systems that will not.
How it works
Ghostscript interprets the PostScript at 150 dpi with its sandbox enabled, and the rendered image is written as a TIFF with LZW compression. The rasterization is where resolution is fixed; the TIFF encoding after it is exact.
Two formats, one generation
EPS and TIFF were both standard by 1987 and both solved a different half of the same problem: getting artwork out of one program and into another before anyone agreed on a common one.
EPS carried the drawing — resolution-independent, printable at any size, and useless to anything that could not interpret PostScript. TIFF carried the pixels — universally readable, exact, and fixed at whatever size it was written at. Design tools spoke EPS; scanners, imaging hardware and printing systems spoke TIFF.
That division never fully went away, which is why this conversion still gets asked for. A great deal of working equipment was built in that period and has had no reason to change: large-format printers, textile systems, plotters, scientific imaging pipelines, archival deposit workflows. They want a raster. Your file is a drawing.
The default that makes TIFF look bad
TIFF's reputation for enormous files comes from an encoder default, not from the format's design.
Left alone, both common TIFF encoders write no compression at all — the raw samples with a header. That produced 1,044,554 bytes for a test drawing on this site before the encoders were told otherwise. LZW brings the same pixels to 5,730 bytes.
LZW rather than the marginally smaller Deflate, on purpose: TIFF is chosen for compatibility, and LZW is the compression that every RIP, scanner utility and archival system reads without argument.
Which EPS conversion to choose
| destination | file |
|---|---|
| a printer, or anything that takes PDF | /eps-to-pdf — keeps the vectors |
| a raster-only system | this one |
| a web page | /eps-to-webp, or /eps-to-png for pixel-exact |
| a form that only takes JPEG | /eps-to-jpg |
Only the first loses nothing at all. Everything else on that list fixes the resolution, and the choice after that is how much you compress.
Getting the resolution right the first time
Because a TIFF cannot be re-rendered later, the resolution is the one decision worth thinking about before converting rather than after.
The arithmetic is simple. An EPS bounding box is in points, 72 to the inch. At 150 dpi each point becomes 2.08 pixels, so a 200 by 150 point drawing renders 417 by 313 — enough for a screen, a document, or a print at about 2.8 inches across at 150 dpi.
If your job needs 300 dpi at twice that physical size, the file you need is four times the pixels, and this tool cannot produce it. The route that can is /eps-to-pdf followed by rasterizing the PDF at whatever size the job requires — or, better, giving the printer the PDF and letting their RIP do it, which is what they would prefer.
Rasterizing too small cannot be fixed afterwards. Enlarging pixels adds no detail; it only makes the existing ones bigger.
Examples
Artwork for a system that wants a raster
Signage, textile and industrial imaging software often takes a flat TIFF and nothing newer. This is that file.
A figure for an archival deposit
Repositories specify TIFF for master copies. LZW keeps it lossless and keeps the deposit a sensible size.
Frequently asked questions
Why would anyone still want this conversion?
Because a large amount of working equipment was built when both formats were current and has never needed replacing. Large-format and textile printers, plotters, some signage software, scientific and industrial imaging pipelines, and archival deposit systems all commonly take TIFF and only TIFF. The EPS on your disk and the TIFF they want are contemporaries; this is the bridge between them.
Is anything lost?
One thing, and it happens at the rasterization rather than in the TIFF. An EPS has no resolution — it is instructions that can be drawn at any size — and a TIFF is a grid of pixels at one size. That choice is made here at 150 dpi and cannot be undone. The TIFF encoding itself loses nothing: LZW is a dictionary algorithm that reconstructs the bytes exactly, verified by pixel checksum.
How large is the file?
Much smaller than TIFF's reputation suggests. Both common encoders default to no compression, which produced 1,044,554 bytes for a test drawing here; with LZW the same image is 5,730 bytes — about 180 times smaller, with identical pixels. Nothing is gained by the uncompressed default and every tool that reads TIFF reads LZW.
What if I need 300 dpi?
Then this is not the tool. /eps-to-pdf keeps the artwork as vectors — the output embeds no images and renders 1667 by 1250 at 600 dpi from a 200 by 150 point source — so whoever prints it can rasterize at whatever resolution the press needs. Handing a printer vectors is better than guessing their resolution in advance, and it is what they would ask for.
Does my file leave my computer?
Yes. PostScript is a programming language and interpreting it safely needs Ghostscript with its sandbox on, which is a server job rather than a browser one. Your file and the result are both deleted within 30 minutes by a timer, and nothing is stored, indexed or examined.