Why the terminal is eighty columns

1928The IBM card, as standardised

Eighty is not a property of screens. It is the number of columns on the punched card that became the standard unit of data processing, adopted at the end of the nineteen-twenties with rectangular holes in place of the round ones used before.

One card was one line. Eighty characters was the width of a record, and everything that read or printed those records was built to that width.

1930s to 1970sThe chain of machines

Card readers fed line printers, which were built to print a card's worth per line. Video terminals replaced printers and kept the width, because the software written for printers assumed it.

By the time a terminal was a screen rather than paper, eighty was no longer a physical constraint at all. It was a compatibility requirement, which is a much more durable thing.

unverifiedThe popular version of the story

The most repeated explanation is that the card was sized to match a banknote of the eighteen-eighties so that existing cash-handling equipment could be reused.

The card's dimensions are documented. The banknote explanation circulates widely, is repeated in otherwise careful writing, and we have not found a contemporaneous source for it. It is presented here as what people say, not as what happened.

1928 onwardsWhat a card physically was

The object is worth describing because everything else follows from it. A card was stiff paper, punched with rectangular holes in a grid of eighty columns by twelve rows, and read by passing it between a light and a row of sensors.

Each column held one character. Twelve rows gave enough combinations for digits, letters and punctuation. The width was fixed by the mechanism and the mechanism was expensive, so the width propagated to everything the mechanism touched: the boxes, the sorting machines, the printers, and eventually the file formats.

1970s onwardsWhy compatibility outlives its reason

A physical limit disappears when the machine is replaced. A compatibility requirement does not, because it lives in the software that assumed it, and that software is cheaper to keep than to audit.

By the time a terminal was a grid of pixels, choosing anything other than eighty would have broken every program that formatted its output for a printer, which was all of them. The cost of the change was borne by whoever made it, and the benefit was diffuse, so nobody made it.

That asymmetry is the general reason old widths, old limits and old defaults survive, and it appears again in almost every entry in this part.

present dayWhat the width does to writing

The inherited width is not only a technical residue; it shapes prose. A line of about eighty characters at a normal size is close to the range typographers recommend for continuous reading, which is why the constraint has aged better than it deserves to.

That is a coincidence rather than a design. The card was not sized for legibility, and the fact that it lands near a comfortable measure is the reason people defend it with arguments that were not available when it was chosen.

present dayThe costs of keeping it

Against that, the width was fixed when code was written in short identifiers on machines with no horizontal scrolling. Modern code has long descriptive names, deep indentation and generics, and eighty characters forces line breaks that hide structure rather than revealing it.

Style guides that raised the limit did so for that reason, and the arguments against raising it are almost always about tooling that assumes the old width: side-by-side views, terminal output, and message formats. Which is, once more, compatibility rather than merit.

How to tell which reason applies

Faced with any inherited limit, the question that separates the two cases is whether anything would break if it changed today. If the answer is that files would be unreadable or a protocol would be violated, the limit is load-bearing. If the answer is that some views would look worse, it is a habit with a rationalisation attached.

Eighty columns is now firmly the second. It is defended as readability, which is a genuine argument that arrived long after the decision and would never have chosen that number by itself.

present dayThe width is not one number

Two limits are usually confused. The width a terminal opens at is eighty. The width a piece of text should wrap at is a separate decision, and the tools that display commit messages, differences and manual pages each subtract their own indentation from the first number before applying the second.

That is why recommendations cluster below eighty rather than at it: seventy-two, seventy-six, sixty-eight. Each is eighty minus whatever a particular tool prepends, which is a constraint inherited from a constraint.

present dayWhere it survives

Terminal emulators still open at eighty columns. Style guides for several languages set a line limit at or near it. Conventions for writing commit messages recommend narrower still, because the tools that display them add indentation to an assumed eighty.

None of those choices is arbitrary in the sense of being random. Each was reasonable when made, and each was made against a width that stopped having a physical basis about fifty years ago.

What we cannot verify

Why eighty rather than seventy-two or ninety-six is not settled by any source we can point to; the number appears already fixed in the standardisation. The banknote story is unverified and is marked as such. Claims that any particular modern limit was chosen for a specific reason are usually reconstructions rather than records.