Technology
The short and long tail of File Formats
Why every PNG starts with a trap, why geneticists renamed human genes for Excel, and how a bigger file can mean less downloading.
Every PNG image ever saved begins with the same eight bytes. Open one in a plain-text editor and they show up as a garbled symbol, the letters PNG and a few invisible control characters. As numbers, they are 137, 80, 78, 71, 13, 10, 26 and 10.
They were settled on 26 January 1995 by an informal group of volunteers that had formed on Usenet a few weeks earlier, and five of them exist to guard against accidents.
The first byte, 137, lies outside the range of plain ASCII text, so a text file is unlikely to be mistaken for a PNG. It also catches file transfers that wiped the top bit off every byte, which some did at the time. Bytes two to four spell PNG.
Bytes five and six, 13 and 10, are a carriage return and a line feed, the pair DOS and Windows use to end a line of text. A transfer program that "helpfully" converted line endings on the way would mangle them. Byte seven, 26, is Control-Z, which told MS-DOS to stop displaying a file, so anyone who dumped a PNG onto the screen saw a few characters instead of a screenful of junk. Byte eight is a lone line feed, to catch the line-ending conversion running the other way.
Before a PNG says anything about a picture, it checks that it survived the trip.
That's a file format in miniature. A file is only a long row of numbers. A format is the agreement that lets one program write those numbers and a different program, on another machine, years later, read them back as a photo, a song or a tax return. Some of that agreement is about the content, and a surprising amount is about everything that can go wrong on the way.
Most of us live among about half a dozen formats. Past them stretches a tail of thousands more, and the strange ones explain the familiar ones better than the familiar ones explain themselves. Before we're done we'll see why geneticists renamed human genes so a spreadsheet would stop turning them into dates, how a satellite image can get bigger and faster to use at the same time, and why the James Webb Space Telescope still describes its data in 80-character lines inherited from punched cards.
Part oneThe short tail
What is a file format, actually?
It's a rulebook for reading bytes. A byte is a number from 0 to 255, and a file is nothing but a sequence of them, with no built-in label saying "photo" or "spreadsheet". The rulebook supplies the meaning: these four bytes are the width, these the height, and everything after this point is compressed pixels.
Most rulebooks open with a nametag, often called a magic number. Every PDF starts with the characters undefined followed by its version number. A JPEG starts with the two bytes FF D8, a marker meaning "start of image". A ZIP archive usually starts with the letters PK, and the PK is Phil Katz, who designed it.
The letters after the dot in a filename are a second, flimsier label. Rename holiday.jpg to holiday.mp3 and not one byte changes; a music player will open it, read the first bytes and give up. Your computer mostly goes by the name when it picks which app opens a file. Archives go by the bytes: the UK's National Archives keeps a database of signatures so its tools can identify a file from its contents.
Here's a two-minute experiment. Copy any Word document, change the ending from .docx to .zip, and open it. Inside are folders of plain-text XML files: one holds your words, others hold styles and settings.
Microsoft's own documentation notes that any of its Open XML files can be explored with a ZIP viewer, so the trick works on Excel and PowerPoint files too. EPUB e-books are ZIP containers underneath as well.
So formats nest like Russian dolls. A Word document is a ZIP file of XML files; XML is text; text is bytes in a character encoding. Nearly every modern Word document on Earth begins with Phil Katz's initials.
Which formats does nearly everyone meet?
About six. Documents travel as PDF and Word's DOCX. Pictures travel as JPEG and PNG. Sound and video travel as MP3 and MP4, and most of the rest is a relative of these or a wrapper around them.
On the web we can watch the fall-off. W3Techs, which surveys the technology behind websites, finds PNG on 75.4% of sites, JPEG on 69.4% and SVG on 67.7% as of 22 September 2026. Then comes the drop: WebP on 22.0%, GIF on 13.5%, AVIF on 1.7%, and TIFF, APNG and JPEG XL on less than 0.1% each.
That's the shape of this essay: a few formats almost everywhere, then a long, thin tail.
Adobe reported in 2018 that some 200 billion PDFs had been opened in its products in the previous year alone. The JPEG committee still describes its 1992 standard as the dominant format for still images.
Notice what the head has in common: these are formats for finished things. We receive the exported song, the edited photo, the final report. The formats those things were made in, like the project file, the camera's raw data or the scan with its measurements, mostly stay with the people who made them. That's where the tail lives.
Who makes file formats?
Anyone who writes a program that saves something. There's no licence and no approval body. The formats that spread, though, have come from four kinds of maker, and the familiar formats have an example of each.
Some come from one person, sometimes under pressure. In the mid-1980s Phil Katz sold a faster program built on a popular compression tool called ARC. Its maker sued him for trademark infringement, the dispute went against Katz in 1988, and so he wrote something new: PKZip, with a new file format, released in 1989. Katz also designed deflate, the compression method that still does the work inside ZIP files and PNG images.
Some come from a company solving its own problem. Adobe launched PDF on 15 June 1993, after co-founder John Warnock wrote a six-page paper, "The Camelot Project", about how hard it was to send a document between different computer systems and have it look right.
Some come from committees, and are named after them. JPEG is the Joint Photographic Experts Group, where "joint" refers not to its parent bodies, ISO and IEC, but to an extra partnership with the International Telecommunication Union. MP3 is short for MPEG-1 Audio Layer III, from the Moving Picture Experts Group, and grew largely out of work at Germany's Fraunhofer institute. Even the .mp3 extension was picked in 1995 by a unanimous internal poll of Fraunhofer researchers.
And some come from volunteers in a hurry. CompuServe designed GIF in 1987 around a compression method, LZW, that Unisys had patented. On 28 December 1994 an agreement was announced under which authors of GIF software would owe royalties, and Usenet erupted.
On 4 January 1995, Thomas Boutell posted a draft replacement. By early March the design was frozen, just over two months after it began, and CompuServe itself had endorsed PNG as GIF's successor. The W3C made PNG a Recommendation on 1 October 1996, and the current specification still introduces it as a patent-free replacement for GIF.
Standards bodies often arrive later, to turn one company's format into everyone's. PDF 1.7 became the international standard ISO 32000-1 in 2008, and Microsoft's DOCX format became ECMA-376 in December 2006. Standardizing a format needn't change a single byte of it. It changes who gets to edit the rulebook.
When were the familiar formats created?
Mostly in one burst, between 1987 and 1996.
| Format | Made for | Made by | Year |
|---|---|---|---|
| GIF | Simple graphics | CompuServe | 1987 |
| ZIP | Bundling and shrinking files | Phil Katz, PKWARE | 1989 |
| JPEG | Photographs | Joint Photographic Experts Group | 1992 |
| Pages that look the same everywhere | Adobe | 1993 | |
| MP3 | Music | MPEG, with Fraunhofer IIS | 1993 |
| PNG | Lossless graphics | Internet volunteers | 1996 |
| MP4 | Video | MPEG | 2003 |
| DOCX | Editable documents | Microsoft, then Ecma | 2006 |
Six of the eight arrived within a decade, as personal computers were joining networks and the web was taking off.
So why haven't better formats replaced them? Because a format is only as useful as the number of programs that can read it, and a file passes through many: camera, editor, uploader, email, browser. A replacement has to win at every step.
Google's WebP shows how slowly that happens. Its first code was released on 30 September 2010, and Google says its lossy images are 25–34% smaller than comparable JPEGs. Apple's Safari didn't display WebP until Safari 14, in 2020. In 2026, WebP is on 22% of websites and JPEG is still on 69%.
iPhones can save photos as HEIF, which Apple says uses less space than JPEG at the same visual quality. But send one to a device that can't read HEIF and the phone may quietly send a JPEG instead. The head is where a format stops being a technical choice and becomes a social one.
Why isn't there one format for everything?
Because every format decides what to keep, and different jobs need different things kept.
A screenshot of a spreadsheet can match the screen pixel for pixel and still keep none of the formulas; change a number and nothing updates. A MIDI file keeps the opposite: which notes to play, when and how hard, and no sound at all, much like sheet music. An SVG drawing stores a circle as a centre point and a radius rather than as pixels, so it stays sharp at any size, and it would be a hopeless way to store a photo of a forest.
Compression sharpens the choice, because every compressed format is a bet about what its data looks like and who will consume it.
JPEG bets on your eyes. It cuts an image into 8 × 8 blocks, rewrites each block as 64 numbers describing patterns from flat to finely striped, then rounds those numbers off. The standard's example rounding tables were tuned by experiment to what people can actually see. The rounding is where the file shrinks, and where detail is lost for good.
MP3 bets on your ears. A loud sound hides quieter sounds near it in pitch and time, an effect called masking. An MP3 encoder estimates that masking threshold as the music plays and buries its rounding errors underneath it.
The payoff is large. CD audio stores 44,100 samples a second at 16 bits each; for the two channels of a stereo recording, that's 1,411,200 bits every second. Fraunhofer, where much of MP3 was developed, says an MP3 needs about a tenth of the original's storage.
PNG and ZIP bet on repetition. Deflate, the method both use, spots stretches of data it has seen recently and replaces each with a short pointer back to the earlier copy: go back this far, copy this many bytes. Nothing is rounded, so unpacking returns every byte exactly. Deflate's own specification says English text usually shrinks by a factor of 2.5 to 3.
Each bet pays off only on the data it was placed on. And there's a mathematical reason no single bet can win everywhere.
Why doesn't zipping a JPEG make it any smaller?
Because the JPEG has already cashed in its patterns. For this essay we zipped three files with ordinary settings.
A 5.6-megabyte JPEG, a 4K wallpaper that ships with macOS, shrank by about 1%. The plain-text specification of deflate shrank by 70%. A megabyte of random bytes came out slightly bigger than it went in.
That last result is guaranteed, and we can prove it with a pencil.
Take every possible message exactly 8 bits long. There are 2⁸ = 256 of them. Now count every message shorter than 8 bits: one of length zero, two of length one, four of length two, and so on up to 128 of length seven. The total is 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 = 255.
A compressor that promised to shrink every 8-bit message would need 256 different shorter outputs, and only 255 exist. Two messages would have to share an output, and the decompressor couldn't know which one to give back. The same count works at every length, because there are always 2ⁿ messages of length n and only 2ⁿ − 1 shorter ones.
Deflate's specification invokes this very argument and states its own worst case: a file can grow by 5 bytes for every 32 kilobytes.
So every lossless compressor is a trade. The inputs it expects get shorter, paid for by the unexpected ones getting a little longer. Random bytes are unexpected by definition, and a JPEG, with its patterns already squeezed out, looks nearly random to deflate.
That's why compressed formats multiply. Photographs, speech, music, text and tables of sensor readings each have their own kinds of pattern, and a format tuned to one is a poor bet on the others.
How many file formats are there?
Nobody knows, and the reasons are more interesting than any total.
PRONOM, the registry run by the UK's National Archives, describes more than 2,000. Search it for "Portable Document Format" and you get 35 separate entries: PDF 1.0 through 2.0, plus archival PDF/A, print-ready PDF/X, engineering PDF/E and accessible PDF/UA, several in multiple versions.
So is PDF one format or 35? For an archivist deciding whether a file will still open in 2060, the difference matters.
Other counters draw other lines. IANA, which registers labels such as image/png that browsers and email use to announce what they're sending, lists about 2,350 media types as of 23 September 2026. TrID, a tool that identifies files from their bytes, has definitions for 22,268 file types, because it counts anything with a recognizable pattern.
All of these count only formats someone bothered to document or detect. Many more are defined only by the software that reads and writes them, and their number grows whenever someone ships a program that saves a file.
Part twoThe long tail
Out in the tail, formats serve small groups with specific problems, which makes their design choices easy to see. Here are four, each exposing something the familiar formats hide.
Why did geneticists rename human genes to suit a spreadsheet?
Because of a format that says too little.
CSV, for comma-separated values, is about as simple as a format gets: one row per line, values separated by commas. When an Internet memo, RFC 4180, finally described it in 2005, it noted that the format was very common yet had never been formally documented, which had allowed a wide variety of interpretations.
Here's what CSV doesn't record: whether a value is text, a number or a date. 00123 might be a quantity or a product code, and MARCH1 might be a date or a name. So when a spreadsheet opens a CSV file, or you paste data in, it guesses.
Microsoft documents Excel's guesses. It drops leading zeros, keeps only the first 15 digits of long numbers, reads digits around a letter E as scientific notation, and turns letter-and-number combinations like JAN1 into dates.
Genes have short symbols like these. SEPT2 is the gene for a protein called septin 2, and MARCH1 is another. Let Excel guess, and SEPT2 becomes 2-Sep, MARCH1 becomes 1-Mar, and the identifier 2310009E13 becomes 2.31E+13.
The problem was first reported in 2004. In 2016, researchers who screened supplementary spreadsheets from 18 journals published between 2005 and 2015 found gene-name errors in 704 of 3,597 papers with gene lists, or 19.6%.
Then the geneticists gave in. In 2020 the committee that names human genes reported that every symbol Excel auto-converted to a date had been changed: SEPT1 is now SEPTIN1, and MARCH1 is now MARCHF1. It was easier to rename genes than to change how a spreadsheet reads a file. Microsoft now lets users switch most of those conversions off.
The same year, an old spreadsheet format lost something bigger. In October 2020, Public Health England announced that 15,841 positive COVID-19 cases from 25 September to 2 October had been left out of the daily figures, because some data files had exceeded a maximum file size.
Labs had sent results as CSV files, which were loaded into Excel spreadsheets in the old XLS format. XLS allows 65,536 rows and each test result took several of them, so each sheet held only about 1,400 cases. Records past the limit were simply left off.
Why 65,536? The XLS format stores each row number in 2 bytes, which is 16 bits, and 16 bits can count exactly 2¹⁶ = 65,536 different values. Microsoft's compatibility guide confirms that data beyond 65,536 rows is lost in the old format, while worksheets since Excel 2007 hold 1,048,576 rows, or 2²⁰.
A choice about how many bytes a row number deserved set the point where a public-health spreadsheet stopped counting.
Both stories share a mechanism. What a format leaves unsaid gets filled in by guesses, and the size of its fields becomes a hard limit. Neither shows up until the day it does.
How can a bigger file mean less downloading?
By arranging itself so that almost all of it can be ignored. The numbers are worth doing step by step.
Say a satellite image is 100,000 pixels wide and 100,000 tall. That's 10 billion pixels, and at 3 bytes of colour per pixel it's 30 gigabytes before compression. You look at it through a window on your screen 1,000 pixels on each side: a million pixels. The file holds 10,000 times more than you can see at once.
Step one: cut the image into tiles. Instead of storing pixels in rows that run the full width of the image, store them in squares, commonly 512 by 512 pixels today, with an index recording where each tile's bytes begin and end. Our image becomes 196 × 196 = 38,416 tiles of about 0.8 MB each, uncompressed.
Step two: fetch only the tiles you need. The web already allows this. An HTTP range request asks a server for, say, bytes 5,000,000 to 5,786,431 of a file instead of the whole thing, and the server needs to know nothing about images to answer it.
Zoomed all the way in, a 1,000-pixel window overlaps at most three tiles across and three down. That's nine tiles, about 7 MB, roughly one four-thousandth of the file.
Step three: store the zoomed-out views in advance. Zoom out to see the whole image and every tile contributes something to the screen, so fetching them all would put us back at 30 GB. Instead, the file carries extra, smaller copies of the image, called overviews.
Say each overview halves the width and height of the one before: 50,000 pixels across, then 25,000, and so on until the smallest fits inside a single tile, which is the default in the widely used GDAL software. For our image that's eight overviews, the last one 391 pixels across. To show the whole image in a 1,000-pixel window, a reader can use the overview that's 782 pixels across. It spans four tiles: about 3 MB.
Isn't storing the image eight more times wasteful? Here's the pleasing part. Halving the width and the height leaves a quarter of the pixels, so the overviews add 1/4 + 1/16 + 1/64 + …, a sum that creeps toward 1/3 and never passes it. The whole ladder costs about a third more storage, and our 30 GB becomes about 40 GB.
So the file grew by a third, and the most you ever need to download to fill a screen fell from 30 gigabytes to under 10 megabytes. This arrangement is a Cloud Optimized GeoTIFF, or COG: an ordinary TIFF image with geographic tags, laid out in tiles and overviews so that range requests can pick out just the parts a reader needs.
The COG standard, from the Open Geospatial Consortium, states the trade plainly: overviews make the file bigger and faster at once. NASA has approved COG as a data format standard for its Earth science systems, and Sentinel-2 satellite imagery sits on Amazon's cloud as COGs.
Even the order of the bytes is tuned. Each round trip to cloud storage costs time, often around 150 milliseconds by the standard's estimate, so it recommends putting all of a file's bookkeeping at the very front, where a single request can fetch it.
Tables get the same treatment. Apache Parquet, which came out of a collaboration between Twitter and Cloudera in 2013, stores a table column by column in chunks, with a footer recording where every chunk lives. A question about one column reads that column and skips the rest.
Parquet can also store the minimum and maximum of each run of values. A reader looking for temperatures above 30 °C can skip any chunk whose maximum is 22 °C without reading a single value inside it. Skipping is the fastest kind of reading.
Both formats move work from the moment of reading to the moment of writing. That's a good deal whenever a file is written once and read thousands of times.
What does a medical scan know that a photo doesn't?
Where it is, in millimetres, inside a particular person.
To a computer, one slice of a CT scan is a grid of grey values, much like a black-and-white photo. The DICOM format, which radiologists and equipment makers began building together in 1983 and which is now used by almost every radiology device, stores that grid alongside the facts that tie it to a body.
Pixel Spacing gives the physical distance between pixel centres, in millimetres. Image Position gives the x, y and z coordinates of the first pixel. Image Orientation gives the directions in which the rows and columns run.
Say a slice is 512 by 512 pixels, and a spot on it is 20 pixels wide. If the pixel spacing is 0.7 mm, the image spans 358 mm and the spot is 14 mm across. If the spacing is 0.3 mm, the image spans 154 mm and the spot is 6 mm.
On screen, the two can look identical. Save either as a JPEG and the millimetres are gone.
DICOM even has to decide what "left" means. Its coordinates are anchored to the patient rather than the machine: the x-axis increases toward the patient's left, the y-axis toward their back and the z-axis toward their head. Earlier versions used the machine's coordinates, which the standard admits were never fully defined.
The strangest part of a DICOM file is its first 132 bytes. Every one starts with a 128-byte preamble, all zeros when unused, followed by the letters DICM. The preamble exists so that the same file can also make sense to other, common image software: one set of bytes, two rulebooks.
In 2019 a researcher at the security firm Cylera showed the catch. Those 128 bytes can also hold the start of a Windows program, producing a file that is both a valid medical image and a valid executable.
DICOM's maintainers say billions of its images are in clinical use, each one carrying its context along with its pixels.
Why does the James Webb Space Telescope still label its data like punch cards?
Because astronomers made a promise never to break a file.
FITS, the Flexible Image Transport System, was designed in 1979 to move images between observatories whose computers agreed on almost nothing. In the first test, in May 1979, a tape written on an IBM-360, with 32-bit words and IBM's own character code, was read by a program on a CDC-6400, with 60-bit words and a different way of storing negative numbers. The FITS user's guide considers that pairing about as bad as interchange gets.
The first papers defining FITS appeared in 1981, and the International Astronomical Union endorsed it in 1982. Its header is written in lines of exactly 80 characters, long called "card images" after the 80-column punched cards common in the 1960s and 1970s.
The file's own nametag is its first card: the word SIMPLE, an equals sign and, in column 30, a T for true. Thirty-six cards fill a block of 2,880 bytes, and every FITS file is built from whole blocks.
Why 2,880 bytes? That's 23,040 bits, a number chosen because it's a whole multiple of the byte and word lengths of every computer sold commercially up to 1979. Check it yourself: 23,040 divides evenly by 8, 12, 16, 18, 24, 32, 36, 48, 60 and 64. Whatever machine read the tape, a block would end exactly on a word boundary.
Then came the promise. FITS rules can grow, but no change may make an old FITS file unreadable or invalid. The community calls this "once FITS, always FITS", and the user's guide admits it has preserved some awkward constructs, which it considers better than forcing astronomers to rewrite their archives.
So the James Webb Space Telescope delivers its science data as FITS files, header cards and all. The FITS standard explains why the promise matters: a format defined only by the software that reads it can be lost when that software stops being maintained, while FITS is written down to the level of individual bits.
What the tail says about the head
Each of these tail formats wears its assumptions openly. CSV assumes someone else will decide what its values mean, and XLS assumed 65,536 rows would be enough. A COG assumes its reader is far away across a network, looking at one corner. DICOM assumes a patient, and FITS assumes the computers of 1979, forever.
The formats in the head carry the same kinds of assumption; we just share them, so we don't see them. JPEG's rounding tables are a model of the human eye, and MP3's masking threshold is a model of the human ear. PDF assumes a page. A Word document assumes a ZIP file, because that's the box Microsoft picked.
The head, in other words, is made of tail formats that happened to fit nearly everyone's job at the moment that job became common, and then stayed. Somewhere on your phone or laptop is a PNG saved this week whose first eight bytes are still standing guard against a 1995 file-transfer accident.
Links in this essay
- 137, 80, 78, 71, 13, 10, 26 and 10 w3.org
- 26 January 1995 libpng.org
- guard against accidents libpng.org
- some did at the time libpng.org
- thousands more pronom.nationalarchives.gov.uk
- 0 followed by its version number rfc-editor.org
- FF D8 pronom.nationalarchives.gov.uk
- Phil Katz loc.gov
- picks which app opens a file learn.microsoft.com
- can be explored with a ZIP viewer learn.microsoft.com
- ZIP containers w3.org
- 75.4% of sites, JPEG on 69.4% and SVG on 67.7% w3techs.com
- some 200 billion PDFs blog.adobe.com
- the dominant format for still images jpeg.org
- released in 1989 britannica.com
- deflate rfc-editor.org
- Joint Photographic Experts Group jpeg.org
- Moving Picture Experts Group mpeg.org
- unanimous internal poll mp3-history.com
- Recommendation on 1 October 1996 w3.org
- ECMA-376 in December 2006 ecma-international.org
- 1989 pkwaredownloads.blob.core.windows.net
- 2003 iso.org
- the web was taking off w3.org
- released on 30 September 2010 chromium.googlesource.com
- 25–34% smaller than comparable JPEGs developers.google.com
- Safari 14, in 2020 webkit.org
- uses less space than JPEG at the same visual quality support.apple.com
- no sound at all midi.org
- a centre point and a radius w3.org
- 8 × 8 blocks w3.org
- masking threshold iis.fraunhofer.de
- 44,100 samples a second at 16 bits each turing-machines.com
- about a tenth mp3-history.com
- 35 separate entries pronom.nationalarchives.gov.uk
- 2,350 media types iana.org
- 22,268 file types mark0.net
- defined only by the software fits.gsfc.nasa.gov
- had never been formally documented rfc-editor.org
- drops leading zeros, keeps only the first 15 digits of long numbers, reads digits around a letter E as scientific notation, and turns letter-and-number combinations like JAN1 into dates support.microsoft.com
- 704 of 3,597 papers with gene lists, or 19.6% genomebiology.biomedcentral.com
- every symbol Excel auto-converted to a date had been changed nature.com
- 15,841 positive COVID-19 cases gov.uk
- XLS format theregister.com
- 2 bytes learn.microsoft.com
- data beyond 65,536 rows support.microsoft.com
- 512 by 512 pixels docs.ogc.org
- range request rfc-editor.org
- default gdal.org
- laid out in tiles and overviews cogeo.org
- data format standard earthdata.nasa.gov
- as COGs registry.opendata.aws
- collaboration between Twitter and Cloudera in 2013 blog.x.com
- where every chunk lives parquet.apache.org
- minimum and maximum parquet.apache.org
- began building together in 1983 dicomstandard.org
- almost every radiology device dicomstandard.org
- Pixel Spacing dicom.nema.org
- 128-byte preamble dicom.nema.org
- both a valid medical image and a valid executable github.com
- about as bad as interchange gets fits.gsfc.nasa.gov
- in column 30 fits.gsfc.nasa.gov
- preserved some awkward constructs fits.gsfc.nasa.gov
- FITS files jwst-pipeline.readthedocs.io