TIFF is widely supported by scanning, faxing, word processing, optical character recognition, image manipulation, desktop publishing, and page-layout applications.

It published the latest version 6.0 in 1992, subsequently updated with an Adobe Systems copyright after the latter acquired Aldus in 1994.

In the beginning, TIFF was only a binary image format (only two possible values for each pixel), because that was all that desktop scanners could handle.

The first version of the TIFF specification was published by the Aldus Corporation in the autumn of 1986 after two major earlier draft releases.

In October 1988 Revision 5.0 was released and it added support for palette color images and LZW compression.

The tags are arbitrary 16-bit numbers; their symbolic names such as ImageWidth often used in discussions of TIFF data do not appear explicitly in the file itself.

Historically this served to facilitate TIFF readers (such as fax machines) with limited capacity to store uncompressed data — one strip would be decoded and then immediately printed — but the present specification motivates it by "increased editing flexibility and efficient I/O buffering".

The StripOffsets point to the blocks of image data, the StripByteCounts say how long each of these blocks are (as stored in the file), and RowsPerStrip says how many rows of pixels there are in a strip; the latter is required even in the case of having just one strip, in which case it merely duplicates the value of tag 257 (ImageLength).

TIFF allows for both additive (e.g. RGB, RGBA) and subtractive (e.g. CMYK) color models.

Compression schemes vary significantly in at what level they process the data: LZW acts on the stream of bytes encoding a strip or tile (without regard to sample structure, bit depth, or row width), whereas the JPEG compression scheme both transforms the sample structure of pixels (switching to a different color model) and encodes pixels in 8×8 blocks rather than row by row.

Tags that take textual values include Artist, Copyright, DateTime, DocumentName, InkNames, and Model.

This tag made TIFF 6.0 a viable format for scientific image processing where extended precision is required.

An example would be the use of TIFF to store images acquired using scientific CCD cameras that provide up to 16 bits per photosite of intensity resolution.

A TIFF file, for example, can be a container holding JPEG (lossy) and PackBits (lossless) compressed images.

A TIFF file also can include a vector-based clipping path (outlines, croppings, image frames).

TIFF offers the option of using LZW compression, a lossless data-compression technique for reducing a file's size.

The flexibility in encoding gave rise to the joke that TIFF stands for Thousands of Incompatible File Formats.

Among other things, Baseline TIFF does not include layers, or compressed JPEG or LZW images.

[9] Every TIFF file begins with a two-byte indicator of byte order: "II" for little-endian (a.k.a.

In order to explicitly support multiple views of the same data, the SubIFD tag was introduced.

Private tags are reserved for information meaningful only for some organization, or for experiments with a new compression scheme within TIFF.

Organizations and developers are discouraged from choosing their own tag numbers arbitrarily, because doing so could cause serious compatibility problems.

There may however be a thumbnail image in that embedded TIFF, which is provided by the second IFD (termed 1st in the Exif specification).

Exif defines a large number of private tags for image metadata, particularly camera settings and geopositioning data, but most of those do not appear in the ordinary TIFF IFDs.

[44][45][46] The goals in developing TIFF/IT were to carry forward the original IT8 magnetic-tape formats into a medium-independent version.

There is also no plan by the ISO committee that oversees TIFF/IT standard to register TIFF/IT with either a parameter to image/tiff or as new separate MIME type.

This subset was developed on the ground of the mutual realization by both the standards and the software development communities that an implementation of the full TIFF/IT standard by any one vendor was both unlikely (because of its complexity), and unnecessary (because Profile 1 would cover most applications for digital ad delivery).

[7] Here are some of the restrictions on TIFF/IT-P1 (compared to TIFF/IT):[50] TIFF/IT-P1 is a simplified conformance level of TIFF/IT and it maximizes the compatibility between Color Electronic Prepress Systems (CEPS) and Desk Top Publishing (DTP) worlds.

CGATS reviewed their alternatives for this purpose and TIFF seemed like the ideal candidate, except for the fact that it could not handle certain required functionalities.

[54] TIFF/IT was created to satisfy the need for a transport-independent method of encoding raster data in the IT8.1, IT8.2 and IT8.5 standards.