Convert TIFF to WebP

TIFF has never been a web format. It predates the web, no browser ever adopted it, and pointing a page at a .tif file downloads it rather than showing it. That is why the file arrived and why nothing downstream is co-operating: a CMS rejects it on upload, a shop platform refuses it, a page template silently drops it.

WebP is the opposite by design — a delivery format from Google, standardised as RFC 9649, read by every current browser without a fallback. The conversion here is therefore not a quality decision but a compatibility one, and it is the least controversial conversion in this family: the file becomes viewable, becomes small, and keeps the transparency that the obvious alternative would destroy.

A TIFF written by a scanner or a print workflow usually stores its pixels uncompressed, which is four bytes per pixel with an alpha channel and three without. This site’s own sample set makes the number concrete: at 480 by 320 pixels, the TIFF is 615,400 bytes for every scene, because the content makes no difference to a file that is not compressed.

The same three pictures as WebP at the default quality are 14,700 bytes for the photograph, 10,830 for the screenshot and 4,428 for the flat graphic. That is between forty and a hundred and forty times smaller. Scale it up to a real scan and the effect is what makes the page load at all: a 300-dpi A4 colour scan is roughly 26 megabytes as an uncompressed TIFF and a few hundred kilobytes as a WebP, before you have even reduced the pixel dimensions.

WebP stores width and height in fourteen bits, so no WebP can be longer than 16,383 pixels on either edge. That is the format itself and every encoder in existence shares it. Measured against the one used here: an image 16,383 pixels wide encodes normally, and the same image at 16,384 fails with an encoding error.

Ordinary photographs never come near it and scans regularly do. A 600-dpi A1 drawing is about 14,000 by 19,900 pixels and an A0 sheet at 400 dpi about 13,200 by 18,700; a 1,200-dpi scan of a letter-size page is 10,200 by 13,200 and only just fits. If a large scan refuses to convert, this is almost always why, and the fix is on the same screen: set a maximum width below 16,383 and it goes through. Reducing an image destined for a web page is not a loss in any case — almost nothing on the web is served above 3,000 pixels wide.

The quality setting runs from 1 to 100 and starts at 82. That is a good default for a photographic scan, where WebP’s lossy mode is doing what it was designed for: 82 is visually clean at normal viewing distance and the file is a fraction of anything lossless.

It is a poor default for a scanned document, a line drawing or a screenshot, where hard black-on-white edges are exactly what lossy compression handles worst — the symptom is a faint grey halo around text and rules. Push the quality to 90 or above for that material and the halos go, at a cost that is still nothing next to the TIFF. If the document has to stay pixel-exact, this is the point at which TIFF to PNG is the better page: PNG keeps every pixel and, on flat interface-like content, is often smaller than a high-quality WebP anyway.

A TIFF is a container rather than an image, and several things inside one have nowhere to go. Multiple pages: only the first is read. Layers: a flattened composite is what comes out. Sixteen bits per channel: reduced to eight by keeping the high byte, which is invisible in a finished picture and does matter if you meant to keep an editing master. CMYK: converted by formula rather than through the profile in the file, so colours shift.

None of that is a defect for the job on this page — a web page is 8-bit RGB, single-image and sRGB by definition, so the losses are all things the destination could not have used. It is a defect if the TIFF was your only copy. Keep the TIFF; publish the WebP. That is the shape this conversion should always take, and it costs nothing because the original is not modified.

WebP has a real alpha channel, so a TIFF with a cut-out subject comes through as a cut-out. That is the single reason to choose this page over TIFF to JPG when the image is a product on a transparent background, a logo, or anything that has to sit on a coloured page.

The alpha is stored per pixel rather than as a single transparent colour, so soft edges — a feathered mask, an anti-aliased outline, a shadow that fades — survive as soft edges. This is also where WebP is clearly better than the older option: converting the same TIFF to GIF would reduce it to 256 colours and, as this site’s encoder writes it, put opaque black where the transparency was.

A TIFF can hold EXIF, XMP, IPTC, an ICC profile and GPS coordinates. None of it arrives in the WebP, and there is no control that would keep it: every browser-side image conversion on this site decodes to raw pixels and encodes again, so the blocks are gone before the encoder is handed anything.

For a web image that is the behaviour you want anyway. Publishing a scan with the capture location, the operator’s name and the machine’s serial number still attached is a routine and avoidable disclosure, and stripping it is also a few hundred bytes off every file. If a caption or a copyright line needs to travel with the picture, it belongs in the page’s markup rather than in the file, because most platforms strip embedded metadata on upload regardless of what you send them.

WebP is the safe answer and not always the best one. On this site’s own samples, AVIF was substantially smaller on the screenshot — 5,081 bytes against WebP’s 10,830 — and slightly larger on the photograph, at 17,599 against 14,700. So for flat, scanned, document-like material AVIF is worth the trip to TIFF to AVIF, and AVIF also lifts the size ceiling to 65,536 pixels, which is the other reason a very large scan might go there instead.

The trade is support. WebP works in every current browser with no fallback; AVIF works in modern ones and not in everything a visitor might arrive with. And where the image is a document that has to stay exact — a signature, a plan, a table of figures — TIFF to PNG is the page that keeps every pixel, at a size that on flat content is frequently smaller than a high-quality WebP.

The conversion runs in your browser. The TIFF is decoded by utif2, re-encoded by libwebp compiled to WebAssembly, and handed back as a download; nothing about the file crosses the network, which is worth knowing when the scans are medical records, contracts or unpublished work. The free size limit is 100 MB per file, which is roughly a 600-dpi A4 colour scan stored uncompressed.

Batches work the same way: drop a folder, each file converts in turn with its own progress row, and the results come back as a ZIP. That is usually how this page gets used, because scanners produce runs rather than single files. The engine is fetched once and reused for the rest of the batch, so a hundred files cost one download of the codec.