The extension is what follows the last dot

Files and text

A filename with more than one dot in it, read under the single rule that the extension is whatever follows the last dot.

The shape

There is exactly one structural rule and it admits no exceptions worth the name: scan from the right hand end of the name until you meet a dot, and everything you passed is the extension. Dots earlier in the name are ordinary characters that happen to be dots. This rule is short enough to apply without thinking about it, which is precisely why it is worth applying deliberately instead.

Rule: the extension is the text following the final dot in the name
Dot count: unbounded. A name may contain no dots, one dot or many, all legal
Extension length: not fixed. Three and four characters are habits, not constraints
Extension alphabet: in practice letters and digits; nothing prevents other characters, and they are rare
Case: written lower case by habit; compared without regard to case on many systems
Empty extension: a name ending in a dot has an extension of zero characters, which is a legal and unusual shape
No extension: a name with no dot, and by convention a name whose only dot is the first character

example.notes.pdf.xyz
                  ^^^ the extension is xyz

example.notes.pdf
              ^^^ the extension is pdf

.example                no extension
example                 no extension
example.                extension of zero characters
example.2026.01.notes   the extension is notes

The last line is the one that catches people out. Three dots, and the extension is a word that was never intended as a type.

Dots that are not extensions

Names accumulate dots for reasons that have nothing to do with type. Version markers, dates, sequence numbers, a project code, an abbreviation someone wrote with a full stop in it: each adds a dot, and each dot moves the boundary the rule cares about only if it happens to be the last one.

There is also the compound suffix, where a name ends in two suffixes and both are meaningful to a reader: the outer one describes a container, the inner one describes what is inside it. Under the rule, such a name has one extension, the outer one. Software that treats the pair as a unit is applying a convention layered on top of the rule, and that convention is a list of known pairs, not a general principle. Where the pair is unknown, the plain rule reasserts itself.

So a name reading example.notes.pdf.xyz is one file with one extension, xyz. The pdf in the middle is four characters of name text. It occupies the position where an extension would sit if the name ended there, and it does not end there.

The name shown and the name stored

Many file listings hide the extensions they recognise. The setting exists to reduce clutter and it does, at the cost of making the displayed name shorter than the stored name. Under that setting a stored name of example.notes.pdf is displayed as example.notes, and a stored name of example.notes.pdf.xyz is displayed as example.notes.pdf whenever the trailing suffix is one the listing knows.

The consequence is worth stating carefully, because it is the whole reason this card exists. Under a listing that hides known extensions, a displayed name ending in something that looks like a type is ambiguous: it may be a name whose extension is being shown, or a name whose extension is being hidden and whose visible tail is name text. The display cannot distinguish those two cases for you, and neither can the eye.

Related display behaviour: long names are truncated in the middle or at the end with an ellipsis, columns cut names at their width, and some listings show a type description drawn from the extension in a separate column instead of the extension itself. In each case the name on screen is a rendering, and the rendering is lossy.

How to check it by eye

Working right to left to the first dot

Start at the right hand end of the name and move left until you hit a dot. Stop there. What you crossed is the extension, and no earlier dot changes that.
Count the dots in the whole name. Zero or one is the simple case. Two or more means the middle of the name contains text that resembles a type without being one.
Find out whether the listing you are looking at hides known extensions, then read the name again knowing that the tail may be missing.
Check for a space or a dot sitting between the last dot and the end of the name, both of which make the extension something other than it appears.

What a wrong shape means

As stored

example.notes.pdf.xyz
extension xyz, three dots

As displayed

example.notes.pdf
same file, one suffix hidden by the listing

Nothing has changed about the file between these two lines. Only the listing setting differs, and the visible tail moved from one piece of text to another.

An extension containing a space, a slash or punctuation that systems reserve indicates the name has been rewritten somewhere along the way, usually by a step that substituted characters it could not store. Read it as damage in transport rather than as design.

An extension twenty characters long is legal and almost always means the final dot is not where you assumed, because the name ends in a word rather than a type. Apply the rule again and it resolves.

A name that ends in a dot with nothing after it will frequently fail to save at all, or will save as the name without the dot. Two files that should have identical names and do not are worth comparing at their tails before anywhere else.

A missing extension is not a wrong shape. Plenty of files have no extension, and a system that decides how to handle a file by other means does not need one. The absence is information about the name only.

What a correct shape does not prove

The central point is short. An extension is a suggestion attached to a name by whoever saved the file. It is not derived from the bytes, it is not checked against them, and changing it changes nothing except the suggestion. A file whose name ends in a familiar suffix and a file whose name ends in an unfamiliar one may hold identical contents.

A recognised extension does not establish the format of the contents. Those are two separate pieces of information that usually agree because people usually name files sensibly.
It does not establish which program will open the file, since that mapping is a setting on your side, not a property of the file.
It does not establish that the file will open at all, or that it is complete.
It does not tell you what the stored name is, if the listing hides suffixes it recognises.
It does not tell you whether the earlier dots were deliberate structure or accidents of naming.
It carries no author, no date and no origin, and it never has.

What remains after the rule has been applied is a boundary in a string. You know where the extension starts. You know nothing further, and any further conclusion has come from a habit rather than from the name.

What this card is not

Length limits, reserved characters, case behaviour and the invisible characters that can reorder a rendered name belong to the filename card, which this one assumes you have read. How a name gains directory structure once it sits inside a container is on the archive listing card. Nothing here describes how to determine a file format from its contents, which is outside what a reference of shapes can honestly cover.

An extension, and the second extension behind it