TIFF to JPG

Drop TIFF files here and get JPG copies back in this tab. A browser cannot open a .tif by itself — <img> and createImageBitmap have no TIFF decoder — so this page reads the TIFF directory first (byte order, compression, bit depth, strip or tile layout, page count) and then runs a decoder of its own, loaded the first time a file needs it. Every page of a multi-page file becomes its own JPG. Nothing is uploaded.

Drop TIFF images here

or choose files · .tif or .tiff · up to 12 at a time · every page converted

TIFF in, JPG out · up to 12 files, 200 MB each, 400 MB per batch · every page converted · 60 megapixels per page · no upload · no account · no watermark

TIFF to JPG: What the Container Holds, and What the JPG Drops

A .tif is a box, not one codec. The same 1,600 × 1,200 photograph measured 5,760,140 bytes stored raw inside TIFF, 4,731,856 as LZW, 3,598,884 as Deflate, 5,805,760 as PackBits and 1,160,361 as JPEG. This page opens the box in your browser, reads which one it is looking at, and writes each page out as a JPG at the quality you choose. The four lossless boxes all produced the same 409,100-byte JPG here, byte for byte; the JPEG-filled one produced 410,561. A 1-bit fax page moved the other way: 12,700 bytes in, 243,622 out.

A TIFF is a container, and the compression is a separate decision

Every TIFF starts with eight bytes that settle how the rest is read: II or MM for byte order, the number 42, then the offset of the first image file directory. A directory holds a count and that many 12-byte entries — tag, field type, count, value — and the chain of directories is the page list. Width, height, bit depth, compression, where each strip begins: all of it lives in those entries.

That is why the extension tells a decoder almost nothing. One photograph, five containers:

Stored as	Bytes	Compression code	Decoded pixels
no compression	5,760,140	1	exact
LZW	4,731,856	5	exact
Deflate	3,598,884	8	exact
PackBits	5,805,760	32773	exact
JPEG	1,160,361	7	already approximated

The four lossless rows decode to identical pixels: 0 differing samples and a maximum channel difference of 0 against the source. They also produced identical JPGs — 409,100 bytes, the same SHA-256 (646b3569…). The bytes on disk differ by up to 1.61× before any conversion happens.

Two more variants of a 64 × 64 image make the same point. Written little-endian, big-endian (MM) and as 16 × 16 tiles, all three wrote the same 1,120-byte JPG. Byte order and strip layout change how the file is assembled, not what comes out.

The browser has no TIFF decoder, so this page carries one

<img src="scan.tif"> renders nothing in the major browsers, and createImageBitmap rejects the file. That is not a bug in one browser: JPEG, PNG, WebP, GIF, AVIF and BMP have built-in decoders; TIFF does not. A page that converts TIFF in the tab therefore has to ship a decoder.

This one loads UTIF 3.1.0 (58,428 bytes) and pako 2.1.0 (46,859 bytes) the first time a file needs them, 105,287 bytes together. A JPEG-compressed TIFF skips both: the browser's own JPEG decoder handles those strips. In a fresh tab the first 1,600 × 1,200 photo took 1,384 ms including that load. The next LZW photo took 243 ms, a 1,700 × 2,200 Group 4 scan 284 ms, and the three pages of a document 68, 63 and 56 ms.

The decoder handles no compression, CCITT Group 3 and Group 4, LZW, Deflate, PackBits and JPEG. It refuses old-style JPEG (code 6), LZMA (34925), Zstandard (50000), JBIG (34661) and JPEG 2000 (34712). It also refuses PlanarConfiguration 2, where the red, green and blue channels sit in separate strips, and any sample format other than unsigned integer. On a refusal the card names the code and writes nothing. A decoder that meets an unknown code and returns a blank buffer would export a black page.

JPEG-compressed TIFF gets a different route. Inside the file, the image is cut into strips, each a JPEG stream with its own markers and shared tables in a tag. The page rebuilds each strip as a stand-alone JPEG, lets the browser decode it and draws it at its row. On the 75-strip test file the stitched result matched a desktop decode exactly: 0 differing pixels, maximum channel difference 0.

Five things the JPG cannot take with it

A JPG is 8-bit, three channels, one image, no transparency. A TIFF can be none of those things. What changed on the test files:

What the TIFF held	Measured	What came out
3 pages, LZW	237,728 B	41,378 + 43,559 + 43,313 = 128,250 B
alpha channel	258,743 clear + 35,775 partial, of 480,000 px	opaque, flattened onto a matte
16-bit grey ramp	22,162 B	5,894 B, high byte only
CMYK	5,390,600 B	409,109 B, plain formula
resolution, EXIF, GPS, source ICC	read and shown on the card	not written; a 456-byte sRGB profile is

Pages live in the directory chain

The three-page file came back as three JPGs named -page-1, -page-2, -page-3; a single-page file keeps its stem. Every page is decoded and encoded, not just the first, because the page count is known before any pixels are touched: it is the length of the directory chain.

16 bits become 8 by dropping the low byte

A 16-bit sample has 65,536 possible values; a JPG sample has 256. This page uses the high byte the decoder returns, with no rescale and no rounding. On a ramp of 1,024 steps the mapping measured:

16-bit value	8-bit sample
0	0
16,399	64
32,799	128
49,199	192
65,535	255

If a scan stores its useful range low, as a 12-bit scanner inside a 16-bit container does, the high byte is mostly zero and the result looks dark. A converter that rescales by the declared bit depth would do better on that file. This one reports the depth on the card so you can see what you gave it; the output was 5,894 bytes from 22,162.

Transparency has to land somewhere

The alpha fixture has 258,743 fully clear pixels, 185,482 fully opaque pixels and 35,775 partial ones. A JPG cannot store any of that, so the page paints a matte first and draws the pixels on top. White produced 24,165 bytes, black 23,175 and a red matte 17,266; the corner pixel read (255,255,255), (0,0,0) and (254,0,0) in the three outputs.

CMYK is converted with a formula, not a profile

The CMYK file went from 5,390,600 bytes to 409,109. The conversion is the plain complement formula: R = (255 − C) × (255 − K) / 255, and the same for green and blue. It matched a desktop decoder's conversion exactly on this file, sample for sample. It does not read an ICC profile, so a CMYK file carrying a press profile will shift. If the JPG is going to a printer, keep the TIFF.

A scanned page can get 19 times bigger

Bilevel scans are where JPG stops being the small format. A 1,700 × 2,200 page of text stored as CCITT Group 4 measured 12,700 bytes. Converted at quality 90 it became 243,622 bytes, 19.2 times the original. Only 4.2% of pixels changed and the result measured 52.49 dB against the decoded page, so the picture is fine; the file is not.

The reason is structural. Group 4 encodes runs of black and white along each row, which is what a page of text is made of. JPEG encodes 8 × 8 blocks of tone with a chroma plane at half resolution, which is what a photograph is made of. The output here was a three-channel 4:2:0 JPEG, even though the source had one bit per pixel. For a text scan, keep the TIFF or move to a lossless format; for a photo, JPG is doing the intended job.

Every JPG this page writes is baseline, three-channel and 8-bit

Sixteen output files at quality 90 were inspected: photos, a screenshot, a scan, a grey ramp, a 64-pixel icon. All sixteen were baseline SOF0, 8-bit, three components, with 4:2:0 chroma sampling. That is the browser's encoder, and it does not expose a subsampling setting. Quality 100 changes one of those: the encoder switches chroma to 4:4:4 there, and the file is still lossy.

The quality curve on the 1,600 × 1,200 photo:

Quality	Bytes	Change vs the raw TIFF
30	96,812	−98.3%
50	142,264	−97.5%
70	204,171	−96.5%
80	264,740	−95.4%
90	409,100	−92.9%
95	596,546	−89.6%
100	1,428,579	−75.2%

At quality 90 the JPG measured 41.45 dB against the decoded TIFF, with 85.1% of pixels moved and a largest channel change of 22 levels. Quality 100 is still lossy: the file is 1,428,579 bytes, about a quarter of the uncompressed TIFF, and the encoder has only changed chroma from 4:2:0 to 4:4:4.

What the page reads before it decodes

Before any pixel moves, the page parses the directory and puts the useful fields on the card: byte order, compression name, bits per sample, photometric interpretation, strip or tile count, resolution, predictor, alpha, and whether EXIF, GPS or an ICC profile is present. Those fields decide whether the file can be decoded at all, so they are also the refusal test.

The limits are 12 files at a time, 200 MB per file, 400 MB for the batch, 60 megapixels per page and 200 pages per file. They exist because the bytes stay in the tab: a 60-megapixel page needs about 240 MB for its RGBA buffer alone.

How to convert TIFF to JPG here

1. Add .tif or .tiff files, or drop them on the box.
2. Set the quality. Every page re-encodes when the number changes.
3. Download each JPG, or one ZIP for the batch.

What the controls do

The quality slider runs from 30 to 100 and starts at 90. The matte selector decides what replaces transparency: white, light grey, black or a colour you pick; it only paints when a page actually has an alpha channel. Multi-page files get one card and one download per page, numbered in file order. There is no run button, no resize and no watermark.

Why this page doesn't upload your TIFF

The decoder, the canvas and the JPG encoder all run in the tab. To check, open the Network panel, add a TIFF and convert it: no request carries the file. The stronger check is to load the page, convert one file, switch the network off and convert another. The same 4,731,856-byte LZW photo produced the same 409,100 bytes and the same SHA-256 with the connection off, and the page made no new resource requests during the second run.

When to keep the TIFF

• The file is 16-bit and you may edit it later.
• It is CMYK and headed for print.
• It is a bilevel scan of text; JPG will make it larger.
• It has pages you may need to reorder or split.
• Its resolution, capture date or GPS position are part of the record.
• It is the archive master. Convert a copy, not the original.

Questions that come up

Why did my scanned page get bigger after conversion? Because the source was probably Group 4 or another run-length compression, which suits black text on white paper. The 1,700 × 2,200 test page went from 12,700 to 243,622 bytes at quality 90. Keep the TIFF for text scans, or use a lossless format.

Can the JPG keep the TIFF's 16 bits per channel? No. JPG stores 8 bits per channel. This page keeps the high byte of each 16-bit sample: 32,799 becomes 128, and the low byte is discarded rather than rounded. The original TIFF keeps everything.

Does every page of a multi-page TIFF come out? Yes. The page count comes from the directory chain, and each page becomes its own JPG with a -page-N suffix. A three-page test file produced three files in page order.

What happens to a transparent TIFF? The alpha channel is painted onto the matte you choose, because JPG has no transparency. White, black and red mattes produced three different files on the test image, with the clear corners reading (255,255,255), (0,0,0) and (254,0,0).

Can it open a TIFF compressed with LZMA or JPEG 2000? No. Those compression codes are refused with a message rather than decoded into a blank page. The same applies to separate-plane files (PlanarConfiguration 2). Plain LZW, Deflate, PackBits, Group 3, Group 4 and JPEG-compressed TIFF are supported.

Which setting keeps a scan closest to the TIFF? No. It is the highest setting the browser's JPEG encoder offers: chroma moves from 4:2:0 to 4:4:4, but the transform is still lossy. On the test photo it produced 1,428,579 bytes, about a quarter of the 5,760,140-byte uncompressed TIFF.

Which colour profile does the output carry? Not the TIFF's. The canvas hands the encoder pixels, not the source profile, so the JPEG comes out with the 456-byte sRGB profile the encoder writes and nothing from the file. If colour accuracy matters, convert in a colour-managed application instead.