Most shops default to one of two workflows: export everything as TIFF because “it’s the serious format”, or export everything as PNG because “it’s smaller and it opens everywhere”. Both work. One of them breaks silently on about one job in twenty, and the other one breaks loudly and obviously. Here is which is which, and how to stop thinking about the choice at all.
What TIFF carries that PNG does not
A gang sheet destined for DTF is not a flat raster. It has, at minimum, four colour channels (C, M, Y, K) and a fifth channel for white under-base. Depending on the printer, it may also carry fluorescent or spot-colour channels, and almost always an ICC profile that tells the RIP what those numbers mean on press.
PNG can store 8-bit RGB, 8-bit RGB + alpha, 16-bit grayscale, and a handful of palette variants. It cannot store CMYK at all. It cannot store a dedicated white channel. It cannot embed a multi-channel colour profile that describes a real ink set. Everything past plain screen-colour RGB has to live in a sidecar file or get flattened at export time.
TIFF was designed for pre-press in 1986 and has not stopped. It stores any number of channels, any bit depth from 1 to 32 bits, embedded ICC profiles, layers, alpha with its own dedicated extra-samples field, and tiled or striped storage that RIPs can stream without loading the whole file at once. When a DTF RIP ingests a TIFF, it reads the channel definitions and the profile together. When it ingests a PNG, it has to guess.
When PNG is actually fine
If the job is single-layer colour artwork without a separate white channel — for example a hot-peel dark transfer where the RIP generates its own white from alpha at print time — PNG with an alpha channel is perfectly adequate. It is smaller, it is universally supported, and the RIP does not need anything the PNG lacks. Most hobbyist DTF workflows on entry-level printers (Epson XP600 3-colour
- W heads, simple ICC) live happily in PNG forever.
PNG is also fine for:
- Design approval previews — a 72-dpi flat RGB PNG is the right deliverable for a customer mock-up, never a 300-dpi CMYK TIFF.
- Web-facing thumbnails of the gang sheet (automated proof pages).
- Logos and bitmap fonts embedded inside a TIFF parent — the PNG can live as a layer, the parent carries the colour pipeline.
When PNG will burn you
Three situations where PNG silently ships a job that prints wrong:
1. Custom white-under-base with a non-default choke. If your shop runs a tighter choke than the RIP default (see the DTF choke post), the white has to be a separate channel in the file, not a RIP-generated artefact. PNG cannot carry that channel. The RIP will generate its own white from the PNG alpha and happily ignore what your designer actually drew.
2. Embedded ICC other than sRGB. PNG supports one embedded ICC at a time and most software strips it on export if it does not match sRGB. A DTF shop running a calibrated profile from its own press will lose the calibration on every PNG round-trip. The file still prints — it just prints the wrong colour by a measurable ΔE and your brand oranges go muddy.
3. Mixed spot and process. A shirt that needs a Pantone spot colour plus CMYK+W cannot be represented in PNG without flattening the spot to CMYK. You lose the spot fidelity at the file layer, not in the RIP. TIFF carries spot channels as first-class data and any RIP that speaks spot (MainTOP, Cadlink Digital Factory, ColorLogic ZePrA, Onyx) will read them directly.
The setting that matters more than the format
Before you decide between TIFF and PNG, decide what bit depth and colour space the file should live in. That choice eats the format-choice for breakfast.
For DTF production work, the honest answer is almost always:
- 16-bit per channel. 8-bit is fine for web, it is not fine for smooth gradients on dark fabric. Banding that is invisible on screen becomes a visible step on a shirt.
- CMYK+W colour model if your RIP expects CMYK, or linear RGB if your RIP does its own separation and prefers unseparated input. Never sRGB JPEG-style encoding for production files.
- Embedded ICC profile — the one your press is actually calibrated to, not the designer’s monitor profile.
Once you have those three right, TIFF wins by default because it is the only common format that carries all three without compromise.
What NestSheet writes by default
NestSheet reads your RIP target on export and picks the file format the RIP expects — CMYK+W TIFF with white channel and embedded ICC for MainTOP, Cadlink, Roland VersaWorks, Mimaki RasterLink, Onyx and ColorLogic ZePrA; 8-bit RGB+A PNG for the handful of web-to-print stacks that want the simpler input. You can override either way if a specific RIP or job wants something different, but the default already matches what your RIP documentation asks for. No guessing, no re-exporting, no “wait, why is the white channel missing”.
That is the whole point of having a pre-press tool that knows which RIP you are shipping to. Format choice stops being a decision you make on every job.
