What changes in the file
- Bit depth drops to 8
- TIFF commonly carries 16 bits per channel from a scanner or a print workflow. Baseline JPEG is 8-bit, so 65,536 levels per channel become 256. Smooth gradients are where you would notice, and it is why you edit before converting, not after.
- Colour space is remapped
- A print-bound TIFF may be CMYK. The JPEG standard can carry CMYK, but PixelFerry writes RGB JPEGs, so a CMYK TIFF has to be brought into RGB on the way through. Some saturated print colours have no RGB equivalent and shift.
- Lossless becomes lossy
- TIFF with LZW compression is pixel-exact. JPEG discards high-frequency detail permanently. For an archive master this is a downgrade; for a delivery copy it is the entire point.
- Size collapses
- A 16-bit scan will generally be far larger than the JPEG it converts to. It stores two bytes per channel with no lossy transform, against JPEG's one byte and a discarded high-frequency component. The ratio varies with the scan, so read the per-row figures.
What TIFF is for
TIFF is the format you keep things in. It is a container rather than a single compression scheme. The common archival choices, uncompressed and LZW, are lossless, though the format also admits JPEG-compressed data. It handles 16 bits per channel, carries CMYK and spot colour, and has been stable long enough that a file written in 1995 still opens.
That makes it right for scanning, print production and digital preservation, and wrong for almost everything else. Safari displays TIFF; other browsers do not without an add-on, so it is not a format to put on a page. Email clients choke on the size, and most web upload tools reject it outright.
So the archive stays TIFF, and you convert copies.
Do the editing first
This is the one piece of sequencing advice that matters.
Sixteen bits per channel exists so that you can push exposure and contrast around without the histogram tearing into visible bands. Once you convert to 8-bit JPEG, that headroom is gone, and any correction you apply afterwards is working with 256 levels per channel instead of 65,536.
Straighten, crop, colour-correct and dust-spot the TIFF. Then convert. Doing it in the other order produces banding in exactly the smooth areas you were trying to clean up: skies, studio backdrops, scanned paper.
LZW, and why size varies so much
TIFF compression is optional and comes in several flavours. Uncompressed TIFF is width × height × channels × bytes, exactly. LZW and ZIP compress losslessly, with LZW doing well on flat content and poorly on noisy scans.
That is why two 40-megapixel scans can differ several-fold in size with nothing wrong with either. An uncompressed 16-bit one is fixed at width × height × 3 × 2 bytes, while an LZW one depends entirely on the content. It also means the size reduction you get from converting to JPEG varies enormously between files in the same batch, and the per-row before/after figures are the only reliable way to know what actually happened.
When PixelFerry writes TIFF as an output format it uses LZW, which is the widely compatible lossless choice.
Batching a scanning archive
Scanning archives are the case this is built for: hundreds of large files, in nested folders, with inconsistent naming.
Drop the top-level folder in. PixelFerry walks the tree. Set JPG, keep the default quality until a sample tells you otherwise, and set a maximum width if there is a delivery spec. Send the output to a separate folder so the derivatives never mix with the masters.
Large TIFFs are slow to decode, and four run concurrently. The summary bar shows a live count and an estimate based on the files that have already finished, so a two-hour batch tells you it is a two-hour batch early rather than at the end.
When people do this
- Sending scans from an archive or a museum digitisation project to someone who just needs to look at them.
- Producing web-sized derivatives from a print production set without touching the masters.
- Making a large scanning backlog browsable in Photos or a digital asset manager that struggles with very large files.
What macOS already does
Preview, Finder's Quick Action, or sips.All three read TIFF and export JPEG. `sips -s format jpeg -s formatOptions 85 scan.tiff --out scan.jpg` even takes a quality value, which makes it genuinely usable for scripted batches.
Where it stops being enough:The archive is large and mixed. sips gives no progress, no per-file failure reporting, and no way to constrain output dimensions and quality together without writing the loop yourself.
Limitations worth knowing first
- The conversion is one-way in quality terms. Keep the TIFF as the master. A JPEG can never be promoted back to an archive original.
- Multi-page TIFFs convert their first page only; unlike PDF, they are not split into a folder of images.
- Layered TIFFs saved from Photoshop are read as their flattened composite, the same way a PSD is.
PixelFerry requires macOS 14 (Sonoma) or later on Apple silicon and Intel. Conversion runs entirely on your Mac. No file, and no part of one, is uploaded anywhere.