FIT File Documentation

---

Technical details

Feature	Value
Full name	Flexible Image Transport System (FITS)
File extension	.fits, .fit, .fts
MIME type	application/fits
Format type	Scientific image/table container (ASCII header + binary data)
Developer	IAU FITS Working Group; endorsed by NASA
Introduced	1981 (IAU standard)
Current standard	FITS Standard 4.0 (2018)
Open standard	Yes — freely published, royalty-free
Byte order	Big-endian (most significant byte first)
Header unit	80-column ASCII cards, padded to 2880-byte blocks
First keyword	SIMPLE = T
Pixel data types (BITPIX)	8, 16, 32, 64 integer; −32, −64 IEEE float
Structure	One or more Header-Data Units (HDUs)
Extension types	IMAGE, BINTABLE, TABLE (ASCII)
Magic identifier	SIMPLE (ASCII 53 49 4D 50 4C 45) at offset 0
Coordinate system	World Coordinate System (WCS) keywords
Related extensions	.fits, .fts, .tiff, .png, .jpeg
Specification	fits.gsfc.nasa.gov

What is a FIT file?

In astronomy a .fit file is a Flexible Image Transport System file, almost always written .fits and pronounced “fits”. It is the standard container for scientific image, spectrum and table data. The format was defined in 1981 by astronomers at the National Radio Astronomy Observatory and Kitt Peak, adopted by the International Astronomical Union that same year, and has been formally maintained ever since; the current text is FITS Standard 4.0, published in 2018. Its MIME type is application/fits.

A FITS file is not a plain picture. It stores a numeric data array (the raw counts a detector recorded) together with an ASCII header describing exactly how those numbers were produced: the telescope, the exposure, the filter, the sky coordinates and the physical meaning of each pixel value. That is why a research archive, a cooled astrophotography CCD or CMOS camera, and a space telescope all emit FITS. The extension varies (.fits, .fit and .fts are the same format) because early filesystems limited extensions to three characters. Everything below describes how the bytes are actually laid out.

One caution before the internals: the same three letters name an unrelated Garmin FIT (Flexible and Interoperable Data Transfer) activity file written by sports watches and bike computers. That is a compact binary fitness log, not an astronomy image, and it is opened in Garmin Connect or Strava. If your .fit came from a watch rather than a telescope, this page is about the wrong format.

The Header-Data Unit: how a FITS file is built

A FITS file is a sequence of one or more Header-Data Units (HDUs). Each HDU is a header followed by an optional data block. The first HDU is the primary HDU; any HDUs after it are extensions. This lets a single file hold, for example, a primary image plus a binary table of the stars detected in it, plus a second image of the error map.

FITS file
 ├─ Primary HDU
 │    ├─ Primary header   (ASCII cards, starts with SIMPLE = T)
 │    └─ Primary data     (the main image array, optional)
 ├─ Extension HDU 1
 │    ├─ Extension header (starts with XTENSION = 'IMAGE   ' etc.)
 │    └─ Extension data   (image, binary table, or ASCII table)
 └─ Extension HDU 2 ...

The whole file is built from fixed 2880-byte logical records. This number is deliberate: 2880 is evenly divisible by the old physical block sizes of magnetic tape and by 80, the width of a punched-card image, so a header of 36 cards fills exactly one record (36 × 80 = 2880). Every header and every data block is padded with fill bytes up to the next 2880-byte boundary, so an HDU always starts on a clean block. All multi-byte binary values in the data are stored big-endian (most significant byte first), regardless of the machine that wrote or reads the file.

The 80-column header card and keyword syntax

The header is plain ASCII text divided into card images of exactly 80 characters. There are no line breaks; cards run one after another, and a reader simply steps 80 bytes at a time. A standard keyword card places an 8-character keyword in columns 1–8, the two characters = (equals plus space) in columns 9–10, and the value in the field that follows. Character-string values are wrapped in single quotes; numbers are written as decimal text. An optional comment is separated from the value by a slash.

Columns:  1        9         21                      /  comment
          SIMPLE  =                    T / conforms to FITS standard
          BITPIX  =                   16 / bits per data pixel
          NAXIS   =                    2 / number of data axes
          NAXIS1  =                 2048 / length of axis 1
          NAXIS2  =                 2048 / length of axis 2
          OBJECT  = 'M31     '           / target name
          EXPTIME =                300.0 / exposure time, seconds
          END

The header ends with a bare END keyword, after which the remainder of the final 2880-byte block is filled with ASCII spaces (byte 0x20). Because the header is text, you can open a FITS file in Notepad or less and read every keyword before a single pixel is decoded — a property that has kept twenty-year-old files self-describing.

SIMPLE, BITPIX, NAXIS: the mandatory keywords

The primary header must open with a fixed sequence of keywords, in a fixed order, so any parser can bootstrap itself from the first few cards.

SIMPLE comes first and carries the logical value T when the file follows the standard. BITPIX comes second and states how each pixel is encoded. Its value is a signed integer whose sign distinguishes integers from floats: 8 is an unsigned byte, 16 a signed 16-bit integer, 32 and 64 signed 32- and 64-bit integers, while -32 and -64 are 32- and 64-bit IEEE 754 floating point. NAXIS comes third and gives the number of array dimensions, from 0 (no data in this HDU) up to 999. For each axis there is then a NAXISn card giving that axis’s length: a 2048×2048 image sets NAXIS = 2, NAXIS1 = 2048, NAXIS2 = 2048.

BITPIX	Pixel type
8	Unsigned 8-bit integer
16	Signed 16-bit integer
32	Signed 32-bit integer
64	Signed 64-bit integer
-32	32-bit IEEE floating point
-64	64-bit IEEE floating point

Those five numbers are enough to locate and interpret the data: the array is NAXIS1 × NAXIS2 × ... pixels, each |BITPIX|/8 bytes wide, stored with the first axis varying fastest. The data block’s size in bytes is that pixel count times the byte width, rounded up to the next 2880-byte record.

BZERO, BSCALE and physical values

The integers stored in the array are rarely the physical quantity a scientist wants. FITS separates the two with a linear transform declared in the header: the physical value equals BZERO + BSCALE × stored_value. This is how the format stores unsigned 16-bit data even though BITPIX = 16 is signed: set BZERO = 32768 and BSCALE = 1, and a stored range of −32768…32767 maps onto 0…65535. The same mechanism lets a compact integer array represent calibrated floating-point fluxes without inflating the file. A separate BLANK keyword names the integer that stands for “no data” (a dead pixel or gap), which a reader converts to a NaN once scaling is applied.

The World Coordinate System: mapping pixels to the sky

A raw image knows only rows and columns. The World Coordinate System keywords tie those pixel indices to real astronomical coordinates so software can label a pixel with a right ascension and declination. The core keywords are CRPIXn (the reference pixel), CRVALn (the world coordinate at that pixel), CDELTn (the increment per pixel), CTYPEn (the coordinate type and projection, for example RA---TAN), and a rotation given either by CROTA2 or a CDi_j / PCi_j matrix. With these, a viewer can overlay a coordinate grid, identify catalogued objects, and align (register) two exposures of the same field taken at different times or with different instruments.

Image, ASCII table and binary table extensions

Extension HDUs open with XTENSION instead of SIMPLE, and its string value names the extension type. An 'IMAGE ' extension is just another data array with the same BITPIX/NAXIS grammar as the primary HDU. A 'TABLE ' extension is an ASCII table, where each column is fixed-width readable text. A 'BINTABLE' extension is a binary table, the workhorse for catalogues: rows of packed binary fields whose columns are described by TFORMn (the data type and repeat count, such as 1E for one float or 16A for a 16-character string), TTYPEn (the column name), and TUNITn (its physical unit). A single FITS file can therefore carry an image and the measured photometry of every source in it, each in its own HDU, all self-described by keywords.

Why an ordinary image viewer fails, and how stretching works

Opening a FITS file in Windows Photos or Preview usually fails or shows noise, for a concrete reason: the pixel values span a range far wider than a screen’s 0–255 per channel. A 16-bit exposure can hold values from a few tens (dark sky) to tens of thousands (a bright star core). To show it, an astronomy viewer applies a stretch: it maps the wide data range onto display brightness through a transfer function, commonly linear, logarithmic, square-root or an arcsinh curve, with black and white points chosen from the data’s histogram. SAOImageDS9 is the standard tool for this; NASA’s FITS Liberator exports a stretched image to 16-bit TIFF for further processing in a photo editor, and browser tools such as Aladin Lite render FITS without any install. Exporting to JPEG or PNG bakes one chosen stretch into 8-bit pixels, which is fine for sharing but discards the original dynamic range, so the FITS file remains the master copy.

References

• NASA FITS Support Office — The FITS Standard (v4.0)
• NASA — A Primer on the FITS Data Format
• SAOImageDS9 — astronomical imaging and data visualization

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.