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 tends to break silently — the job prints, just wrong — and the other one breaks loudly and obviously at import. 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 stores RGB and greyscale (with or without alpha, 8- or 16-bit) 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.
For the separate meaning of alpha, white and varnish planes—and why a familiar channel name is not a compatibility promise—see the DTF spot-channel guide.
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.
If the PNG comes from background removal, the Canva transparent-PNG preflight shows how to inspect low-alpha residue before the RIP derives white.
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 spot-capable RIPs read them directly — check your RIP’s import notes for how it expects the channels named.
The settings that matter more than the format
Before you decide between TIFF and PNG, decide what colour model the file should live in and whether its profile is honest. Those choices eat the format-choice for breakfast.
The broader DTF file requirements put container choice beside final size, effective PPI, alpha and colour handling.
For DTF production work:
- Colour model matched to your RIP. CMYK+W if your RIP expects separated input; RGB if it does its own separation and prefers unseparated input. Ask the RIP, not the designer.
- Embedded ICC profile — one that truthfully describes the numbers in the file, not the designer’s monitor profile. An untagged file forces the RIP to guess.
- Bit depth: 8 bits per channel is the production standard here, and it is enough. DTF RIPs rasterise to screened dots; the banding people fear on gradients comes from repeated colour-space conversions and untagged round-trips along the way, not from the final file being 8-bit. Keep 16-bit for the editing stage if your artwork needs heavy tonal work — hand the RIP a clean 8-bit file at the end. (NestSheet’s exports are 8-bit per channel for exactly this reason.)
Once you have those right, TIFF wins whenever the job needs more channels than RGB+alpha, because it is the only common format that carries them without compromise.
What NestSheet writes
NestSheet’s export dialog is a matrix of recipes across TIFF, PNG, PSD/PSB and PDF: CMYK+white TIFF (up to CMYK plus four white and four varnish channels), PSD/PSB with real spot channels, plain RGB+alpha PNG for RIPs that generate their own white, and PDF. Every recipe embeds the ICC profile of the output intent you chose, and the spot channels come out named W1–W8 / V1–V4 — with six RIP presets in the box (MainTOP, CadLink Digital Factory, AcroRip, PhotoPRINT, SAi Flexi, Generic DTF) and a rename control for anything else your RIP expects. You pick the row your RIP documentation asks for once; after that, format choice stops being a decision you make on every job — and the white channel is never silently missing, because it is a real channel in the file, not an artefact the RIP has to reconstruct.
