The line of metadata under an image

Files and text

The short line a viewer prints under or beside a picture, giving its dimensions, its size, a format name and sometimes a date.

The shape

This line is generated, not written, which makes its shape unusually regular. A viewer reads a handful of values, formats each one to a house style and joins them with a separator. The house style differs between viewers; the field order barely does.

Field order

dimensions first, then size, then format, then a date where one is shown

Dimensions

two integers with a multiplication sign between them, width before height, no decimal point

Dimension unit

pixels, almost always unstated

Size

a number and a unit, where the unit decides what the number was divided by

Format

a short word, usually upper case, drawn from a header or from the name

Date

a date, sometimes with a time, sometimes absent entirely

Separator

a middot, a comma, a vertical bar or two spaces, depending on the viewer

skeleton: # is one digit

#### × ####  ·  ###.# UNIT  ·  FORMAT

a filled placeholder, digits counting up

1234 × 5678  ·  123456 bytes  ·  EXAMPLE
1234 × 5678  ·  120.6 KiB  ·  EXAMPLE

Bytes, kibibytes and kilobytes

The size field is the one place this line invites a wrong reading, because two divisors are in common use and the labels for them are used inconsistently.

Two consequences follow. The first is that a size printed with a unit has been divided and then rounded, so it is an approximation of a whole number that the viewer already had. The second is that the same file can be honestly described as a slightly different size by two viewers, and the difference is a formatting choice rather than a discrepancy.

Where a byte count is available, it is the only figure on the line that has not been through arithmetic. It is worth preferring for that reason alone.

How to check it by eye

What a wrong shape means

1234 × 5678  ·  123456 bytes
two integers, then an exact count

123.4 × 567.8  ·  123456 bytes
decimals where a pixel count belongs

Pixels are counted, so they arrive as whole numbers. Fractions mean the figure describes how large the picture is being drawn, not how large it is stored.

A dimension of zero, or a missing dimension, generally means the viewer could not read the header and is showing whatever it had. That is a statement about the reading, not necessarily about the file.

A size with a unit and no number, or a number with no unit, is a truncated line. Long metadata lines get cut to fit narrow columns, and the field that loses its tail is usually the last one printed.

A format word that disagrees with the filename suffix is worth stating precisely: one label was read from inside the file and the other was typed by whoever named it, and they were always independent. Disagreement means the two labels differ. That is the complete finding, and the extension card explains why the suffix was never binding in the first place.

The picture on your screen and the picture in the file

Dimensions describe the file. The size at which you are looking at the picture describes the display, and the two coincide only by chance. Zoom, a window narrower than the image, a page that scales images to fit its column and a screen that draws more than one device pixel for each layout pixel all separate them.

Some viewers print both figures, sometimes on the same line, sometimes with one in brackets. When they do, the labels are easy to confuse because both are a pair of integers with a multiplication sign between them. The stored dimensions do not change when you zoom; the displayed pair does, which is the only reliable way to tell which is which.

The practical result is that a small looking picture is not a small picture, and a picture that fills a column is not necessarily large. Reading the number rather than the impression is the entire discipline here.

The same separation applies to the size field in a quieter way. A viewer showing a picture scaled down is still holding all of it, so the figure on the line describes the file rather than the amount of it you are looking at. Two pictures drawn at identical sizes in the same column can differ by a large factor in both dimensions and in bytes, and the line beneath them is the only place that difference is visible.

What a correct shape does not prove

Everything on this line came out of the file. The viewer opened it, read fields from its headers, formatted them and printed them. Those headers are values recorded by whatever produced the file, which is why a well formed metadata line is a faithful report of what the file says about itself and not an independent measurement of anything.

• The format word reflects a header field or the filename suffix, and both of those are set at production time.
• A date on this line is a recorded field. It is not evidence of when anything happened, and many files carry none at all.
• The dimensions describe the stored image. What is visible on your screen is a separate matter, as the section above sets out.
• The size describes the file as stored, including whatever else the file carries besides picture data.
• Nothing on the line addresses content, subject, origin or authorship, because no field for those exists in the shape.
• Nothing on the line establishes that the picture has not been altered, since every field would be rewritten by any tool that rewrote the file.
• A viewer that prints fewer fields than another has not found less; it has chosen to show less.

Read the line as the file describing itself in a fixed format. That description is usually accurate and never self supporting.

What this card is not

The suffix on the filename beside the picture, and why it constrains the contents so weakly, belong to the extension card. Naming rules for the file itself are on the filename card. Anything to do with identifying a particular file rather than describing one is on the file hash card. This card describes a printed line and nothing that could be read out of image data.