Convert EML files to TIFF for production
TIFF is the format that shows up in a production request when the other side is loading your documents into a review platform rather than reading them. It is an imaged format: every page becomes a picture, which is precisely why it gets asked for — an image cannot carry a live hyperlink, a tracked change, or a formula that recalculates on open.
EML Exhibit renders each .eml message to a multi-page TIFF at 150 to 600
DPI. TIFF output is a Pro feature; free conversions produce PDF.
TIFF is a delivery decision, not a preference
Nobody asks for TIFF because they like it. It appears in a production because of what an image cannot do. A native spreadsheet recalculates. A native Word document carries its revision history and its author metadata. A PDF can hold a live link out to the internet. An imaged TIFF is a flat picture of a page, and once a document has been imaged, what the receiving party sees is fixed and identical to what you sent.
That property is what makes TIFF the traditional production format, and it is why a request for “imaged production” or “single-page TIFF with load file” means the other side has a review platform and a specification, not a preference for a particular file extension.
What imaging an email actually produces
The message renders exactly as it would to PDF — header block on top, body beneath, inline images in place — and then that rendered page set is written as a multi-page TIFF at the resolution you chose. The output is one image file per message, with as many pages inside it as the message needs.
Two things follow from that, and both catch people out:
- Text is no longer text. An imaged production is not searchable until someone OCRs it. If the receiving party expects extracted text, that comes from the load file, not from the image.
- Page count is fixed at imaging time. Whatever pagination the render produced is what gets stamped. This is a reason to image at the DPI you intend to deliver rather than re-imaging later.
Choosing a resolution
| DPI | File size | Where it fits |
|---|---|---|
| 150 | Smallest | Internal review sets, or where storage genuinely constrains delivery |
| 200 | Small | Occasionally specified for large-volume productions |
| 300 | Moderate | The common specification, and the default here |
| 400 | Large | Messages containing scanned material read closely |
| 600 | Largest | Fine detail in embedded images; rarely necessary for email |
If the protocol is silent, produce at 300. It is the resolution the other side will assume, and a set imaged at 150 that has to be re-imaged and re-stamped is an expensive way to have saved some disk.
After the images
TIFF rarely travels alone. The receiving party’s platform needs to know which
image belongs to which document, in what order, and with what metadata, which
is what a load file supplies. EML Exhibit produces the
images and preserves the originals; assembling the load file is the next step
in the chain, and the reason to keep the .eml originals is that the metadata
in that load file comes out of them.
How to do it in EML Exhibit
-
Confirm the DPI the receiving party expects
Most production protocols specify 300 DPI black-and-white or greyscale for documents. Check the protocol or the meet-and-confer correspondence before you image several hundred messages at the wrong resolution.
-
Load the .eml batch
Select up to 100 .eml files. The rendering is the same pipeline that produces PDF, so the header block and inline images land in the same place regardless of output format.
-
Select TIFF and set the resolution
Choose TIFF as the format and pick from 150, 200, 300, 400 or 600 DPI. 300 is the default and the safe answer when no protocol was specified.
-
Set a prefix and sort order
A matter prefix on every filename and a date-ordered sort make the image set match the order your load file will describe.
-
Download and hand off to the load-file step
The ZIP contains one multi-page TIFF per message plus the original attachments. From there the images go to your numbering and load-file tooling.
Why would anyone want TIFF instead of PDF?
Because a TIFF is inert. Imaging a document strips live content — macros, linked spreadsheets, revision history — and produces something every review platform can display consistently and stamp identically. It is the historical default for TIFF productions and still what many protocols specify. PDF is usually the better answer when the document is going to a judge rather than to a platform.
What DPI should I produce at?
300 DPI unless the production protocol says otherwise; it is the common specification and it renders small type in a forwarded thread legibly. 150 DPI produces much smaller files and is fine for review-only sets. 600 DPI is worth it only when the messages contain scanned images that will be read closely. The DPI options here are 150, 200, 300, 400 and 600.
Is one TIFF produced per email or per page?
One multi-page TIFF per message. Some load-file specifications require single-page TIFFs, one image per page, with the page breaks described in the load file. If your protocol calls for that, the multi-page files here need to be split by your load-file tooling before delivery.
Does the TIFF include the attachments?
No. Attachments are extracted as their original unmodified files alongside the images, never imaged into the message. Whether the attachments themselves get imaged is a separate decision, and usually one the production protocol makes — see parent-child relationships.
Do I need a Pro plan for TIFF?
Yes. TIFF rendering is a Pro feature. Free-tier conversions produce watermarked PDF and are intended for evaluating the output before you commit a matter to it.