The checksum line above the footer

A short line at the bottom of an armoured block, beginning with an equals sign and carrying four more characters.

The shape

Five characters on their own line, in a fixed position. It is the smallest shape on this site and one of the easiest to read correctly, which makes the ways it goes wrong unusually crisp.

First character: an equals sign, which here is a marker and not base64 padding
Then: exactly four characters from the base64 set
Total width: five characters, with nothing else on the line
Position: directly after the last body line and directly before the footer
Spacing: no space between the marker and the four characters
Presence: optional; newer output sometimes leaves the line out entirely

[body: last line of base64 characters]
=xxxx
-----END PGP PUBLIC KEY BLOCK-----

The four x characters stand for four base64 characters. No real checksum appears on this site.

Right shape

=xxxx

Wrong shape

= xxxx

A space between the marker and the four characters. The marker and its characters are written together, with nothing between them.

=xxxx      five characters, correct
=xxxxx     five characters after the marker, one too many
=xxx       three after the marker, one short
==xxxx     the marker doubled
xxxx       the marker gone, taken with the selection above it

Four ways the line arrives damaged. All four are copying faults rather than variants of the format.

The equals sign is the part people misread. In base64 an equals sign at the end of data is padding, so a reader who has met the alphabet expects it to mean that, and here it does not. It is a marker announcing that the remainder of the line is a checksum rather than more body. That is why it is written flush against its four characters: they are one token.

The line is also unmistakable by width alone. Armoured bodies are printed at a fixed line length, so the block above this line is a solid rectangle of text; the footer beneath it is a long line of hyphens and words. Between those two, a line five characters wide reads as a notch in the right hand edge. Once you have noticed that notch you will find it instantly on every block that has one, and its absence is equally quick to see.

How to check it by eye

The five characters above the footer

Look at the line directly above the closing marker and see whether it is short.
If it starts with an equals sign, count what follows. Four, and no more.
Check there is no gap after the equals sign.
If no such line exists, leave it alone. Its absence is a legitimate form.
If the equals sign is there but fewer than four characters follow it, the copy stopped early.

What a wrong shape means

This line is deleted by accident more than any other part of an armoured block, and the reason is physical. It sits at the join between two things that look important, it is much shorter than everything around it, and a selection dragged from the body to the footer will often either include it or skip it by one line. It also looks, to somebody tidying text, like a fragment left behind.

A missing checksum line is therefore ambiguous in a way the other faults are not. It may have been removed in transit, or it may never have been written, because output from newer software leaves it out on purpose. Absence alone does not distinguish those two, and reading a missing line as damage produces a lot of false alarm.

A malformed line is less ambiguous. Five characters after the marker, or three, or a doubled marker, are all signatures of a selection that started or ended in the wrong column.

What a correct shape does not prove

What this line was designed to detect is accidental corruption in transit. It was never designed to say anything about origin, and it does not acquire that ability by being present and well formed.

Not that the block came from anywhere in particular. Whoever produces a block produces its checksum in the same breath, so a replaced body arrives with a matching line.
Not that the body is complete in any sense you can see. The four characters are computed by software from the bytes; by eye you are checking a shape, not a value.
Not that the block is the one you were expecting, since two entirely different blocks can both be internally sound.
Not that the check is a strong one. It is a small transport check by design, which is part of why newer output treats it as optional.
Not that the block, or the key inside it, has any connection to anything published elsewhere. That question is outside every shape on this site.

Its value is narrow and real: it catches text that broke on the way. Ask it for more and it has nothing further to offer.

What this card is not

This is not the base64 alphabet, which is listed once at alphabets and not repeated on cards. It is not a file hash, a different kind of short value with a different purpose, described at a file hash. The blocks this line terminates are at the family page.

Questions people send about this shape

Is the equals sign here the same as base64 padding?

No. Padding appears at the end of base64 data to fill out the final group. This equals sign opens a line of its own and announces that what follows is a checksum rather than more of the body. The two look identical as characters and sit in different places, which is the source of most of the confusion around this line.

Does a block without this line have something wrong with it?

Not necessarily. The line is optional, and newer output often omits it deliberately. A block with a well formed opening marker, a body and a matching footer is a complete block whether or not a checksum line sits above the footer, so absence on its own is not a fault to report.

The checksum line at the foot of an armoured block