Convert WebP to TIFF

The assumption behind most searches for this pair is that TIFF is the high-quality format and converting into it is an upgrade. TIFF is the high-quality format in the sense that it can carry 16 bits per channel, CMYK, layers and multiple pages without compressing anything. It is not a restoration, and a container cannot put back what was thrown away before it.

If the WebP was lossy — which nearly every WebP served from a website is — its encoder has already smoothed flat regions and left ringing along hard edges, and those artefacts are now simply what the picture is. They are written into the TIFF faithfully and at great expense in bytes. The honest description of this conversion is that it satisfies a file-type requirement. Where the requirement is really about quality, the answer is to find the original file rather than to re-wrap this one.

Four channels at 8 bits each, uncompressed, photometric RGB, stored in strips, with the resolution tag set to 72 dpi. Uncompressed is a deliberate choice rather than an omission: TIFF readers agree on less than you would hope, LZW is patent-free and effectively universal while Deflate is not, and JPEG-in-TIFF is a different image inside a TIFF wrapper. Somebody converting to TIFF is usually feeding a particular machine, and the plain uncompressed baseline is the one thing every such machine accepts.

The cost is size and it is not small. Four bytes per pixel means a 12-megapixel image is about 48 MB before the header, and no content makes any difference to that. This site’s own 480 by 320 samples are 615,400 bytes as TIFF whatever the picture is, against 14,700 for the photograph as WebP — a factor of forty-two. If the submission system has an upload limit, that is the number to plan around.

The resolution field in the TIFF is written as 72 dpi and is not derived from anything in the WebP, which has no equivalent field to derive it from. A print shop that reads that tag will report a low-resolution file, and this is the single most common source of confusion on this page.

What actually determines whether a picture can be printed at a given size is the pixel count, and that is unchanged by any of this. At 300 dpi, a 10 cm wide print needs about 1,180 pixels and an A4 page needs about 2,480. Measure your image against those numbers before submitting, because a WebP served from a web page is often 800 or 1,200 pixels wide — enough for a small print and not for a full page. If the tag itself is what is being checked, set it in an image editor after converting; it is a metadata field and changing it alters no pixels.

TIFF supports CMYK and that is a large part of why print workflows ask for it — a CMYK TIFF with the right ICC profile is a file a press can use directly. This converter writes RGB and cannot write anything else, because the whole image pipeline here decodes to 8-bit RGB.

So if the specification says "CMYK TIFF", the file this page produces will not satisfy it, and no setting changes that. The separation has to be done in software that has the destination profile — Photoshop, Affinity Photo or GIMP will all do it, and the printer will usually name the profile they want. Where the specification just says "TIFF", RGB is almost always acceptable and is what most portals expect anyway. It is worth asking rather than guessing, because a rejected submission costs more than the email does.

The TIFF is written with a fourth channel, so a WebP carrying an alpha channel arrives with its transparency intact. For artwork that has to sit on a coloured page or be composited later, that is exactly right and is one of the reasons to use this route rather than converting to JPG.

For a submission it can be a problem. Some portals, some print RIPs and some older archive tools reject TIFFs with an alpha channel, or treat the alpha as an unexpected spot channel and produce something strange. If the requirement does not mention transparency and the image does not need it, flatten it onto a white background first in any image editor. The alpha is also declared in the file as associated rather than unassociated, which some strict readers interpret as premultiplied — another reason to flatten when transparency is not part of the job.

TIFF can hold several pages, layers, 16-bit channels, spot colours and an ICC profile. A WebP has none of those to contribute: it is a single 8-bit RGB image with optional alpha, so every one of those TIFF capabilities arrives empty. The result is a TIFF in the same sense that a text file with one line is a document.

Metadata does not travel either. Every image conversion here decodes to raw pixels and re-encodes, so any EXIF, XMP or ICC block in the WebP is dropped, and no setting on this pair can hold on to it. Where a submission requires embedded copyright or caption information, that has to be added to the TIFF afterwards in software that writes IPTC — Photoshop, exiftool or a digital-asset system.

WebP holds either a still image or an animation, and the decoder used here reads only the first kind. An animated file is refused with a readable message rather than converted to its first frame, which is deliberate: a converter that quietly returns a tenth of a file is worse than one that says no.

TIFF could in principle have held the frames, since it is a multi-image container — but nothing in this pipeline assembles them, so the question does not arise. If a single frame is what you need, open the animation in a browser, pause it and screenshot the frame. If the motion is the content, WebP to GIF or WebP to MP4 are the pages that keep it.

If the goal is an exact copy in a format everything opens, WebP to PNG is better on every axis: lossless, transparency intact, a small fraction of the size, and no version of it that a reader might refuse. TIFF is only worth the bytes when something has specifically asked for it.

If the destination is a person or an ordinary printing service, WebP to JPG is what they expect and handle without comment. If it is a document submission, WebP to PDF often satisfies the same portals that list TIFF, and is far smaller. Read the requirement carefully before converting: "high resolution" usually means pixel count rather than file type, and a TIFF made from a small WebP satisfies the letter of the request while failing its purpose.

libwebp compiled to WebAssembly decodes the file and utif2 writes the TIFF, both fetched only when needed and both running in the tab. Nothing is uploaded, which is the point when the image is unpublished work being deposited somewhere, or a client asset under an embargo.

The free limit is 100 MB per file and applies to the input, so the constraint here is really memory: a large image spends several bytes per pixel in the tab while it is being written, and a very large one on a phone can run out. Batches work — drop a folder, take a ZIP — but the output is uncompressed, so a run of a hundred images produces a ZIP measured in gigabytes. Converting in groups is the practical approach.