On a standard t-shirt listed in the US, the printed design reads GOT TOO SILLY in capital letters above a white, goose-like bird dressed in an orange prison uniform and holding a black mugshot board. That is the whole of the artwork as observed, and it is enough to make a small argument about how jokes work when they are compressed into a single frame.

The shirt is sold under the title Got Too Silly Funny Bird Mugshot Prison Meme by Quirky Cotton Collective. You can find the listing here. I am not going to tell you how it fits, because I have not worn it, and I am not going to tell you that it is popular, because the only demand evidence I have is a keyword range, not a sales history. What I can read is the design itself, and the design is doing something more deliberate than it first appears.

Editorial note: this publication and Quirky Cotton Collective share an owner. This is not an independent review.

The mugshot as a genre

A mugshot is a documentary form. It exists to identify a person at a low point, under official light, with a board that records a name, a number, a date. Its conventions are rigid: front-facing, neutral background, the board held at chest height. When you see one, you are meant to read it as fact. The genre has no room for whimsy. That is precisely why it is useful to a joke.

The shirt takes that rigid frame and fills it with a bird. Not a hawk or a crow — a white, goose-like bird, the kind of animal that in common usage is associated with silliness rather than menace. The orange uniform is the uniform of incarceration, but on a bird it reads as costume. The black board is the board of record, but it is held by a bird. The phrase above supplies the charge: GOT TOO SILLY. The joke is not that the bird committed a crime. The joke is that silliness has been treated as an offense serious enough to warrant the full apparatus of official documentation.

This is a familiar comic structure — the mismatch between a trivial transgression and a solemn response. What makes it work on a shirt is that the structure is delivered without a caption, a punchline, or a second panel. The viewer completes it. The phrase is not a description of the bird’s character; it is a verdict. The image is the sentence.

What the mugshot board asks of you

The most interesting decision in the design is the mugshot board itself. A filled board would close the joke. It would give the bird a name, a number, a date, and the joke would become a specific fiction. A board that is merely present — held at chest height, the way a board is always held — leaves a gap that the viewer’s eye fills automatically. You read the board as a board because of its shape and position, and then you notice that the bird is the one holding it, and the substitution becomes an invitation. The joke is completed by its viewer, not by its maker.

That is a useful thing to notice about compressed visual humor. It relies on recognition of a form — the mugshot — and then a substitution within that form. The form does most of the work. The substitution does the rest. If you did not recognize the mugshot conventions, the image would still read as a bird in a costume, but the specific charge of GOT TOO SILLY would lose its edge. The shirt assumes a viewer who has seen a mugshot before, probably many times, and who knows what one is supposed to mean. The joke is built on that prior knowledge.

This is also why the phrase is set above the image rather than integrated into it. The words are the charge; the image is the evidence. The layout reads top to bottom like a case file: accusation, then photograph. The bird does not speak. The board does not speak. The only language on the shirt is the verdict, and it is delivered flatly, without exclamation, as if it were a formal finding.

The bird as a character without a backstory

The white bird is not a specific character from a known property, at least not in the observation I have. It is a generic goose-like bird, and that generality is part of the design’s economy. A recognizable character would bring its own history and its own fan base; the joke would become about that character. A generic bird is a blank slate. You project onto it whatever silly thing you imagine it did. The orange uniform and the mugshot board give it a role, but not a biography.

That is a different kind of humor from the meme formats that rely on a named face or a recurring catchphrase. This shirt uses a stock situation — the perp walk, the booking photo — and a stock animal — the silly goose — and lets the combination do the work. The phrase GOT TOO SILLY is not a quotation from a particular source that I can verify. It is a common construction, and the shirt uses it as a caption for an image that already contains its own narrative logic. The words and the picture are not redundant; they are two halves of a single sentence.

I am wary of overreading a t-shirt. But there is a real craft question here about how much context a joke needs. This design gives you almost none. It does not tell you what the bird did. It does not tell you whether the bird is sorry. It does not give you a second bird to react. It gives you a form, a costume, a verdict, and a board. The rest is your work. That is a lean kind of design, and it is harder to pull off than a design that explains itself.

Why the phrase matters more than the costume

The orange uniform is the most visually loud element, but the phrase is the load-bearing wall. Without GOT TOO SILLY, the image is a bird in a costume. With it, the image becomes a joke about proportionality. The phrase does not describe the bird as silly; it says the bird got too silly, which implies a threshold was crossed, a limit was reached, a line was breached. That is the language of discipline, applied to something that has no business being disciplined. The humor is in the mismatch between the gravity of the phrase and the lightness of the offense.

This is also why the shirt works as a piece of language as well as a piece of art. The phrase is short, idiomatic, and slightly ungrammatical in a way that feels natural. It is the kind of thing you might say about a friend who has taken a joke too far, or about yourself after a long week. It is not a formal charge; it is a gentle verdict. The image supplies the formal charge, and the phrase supplies the gentle verdict. The tension between the two is the joke.

If you are the kind of reader who notices typography, you will notice that the phrase is set in capitals, with no ornament. It is not trying to be a vintage poster or a hand-lettered sign. It is trying to look like a label. That plainness is consistent with the mugshot form, which is also plain and bureaucratic. The design does not undercut the officialness of the image with a fancy typeface; it doubles down on it. The bird is being processed, and the typeface is the processing.

The shirt as a surface for a completed joke

A t-shirt is a strange medium for a joke. It is worn on a body, which means the joke is always in motion, always being seen from different angles, always subject to the wearer’s context rather than the designer’s. A mugshot is a fixed image, taken once, filed away. Putting a mugshot on a shirt turns the fixed image into a moving one. The bird is being booked, but the booking is happening on your chest, in a grocery store, at a bus stop, in a meeting where someone is trying to read the board.

That mobility is part of the design’s humor. The joke is not a one-time reveal; it is a recurring situation. Every time someone reads the shirt, they have to complete the joke themselves. The board is still there. The verdict is still GOT TOO SILLY. The bird is still not contrite. The shirt does not get old in the way a written joke gets old, because it is not a written joke. It is a visual situation that the viewer re-enters each time.

This is the kind of thing I mean when I say the container shapes the content. A mugshot on a wall is a document. A mugshot on a shirt is a performance. The same image, moved to a different surface, becomes a different kind of object. The shirt does not change the drawing; it changes what the drawing is for. It turns a fixed record into a portable bit of theater, and it asks the wearer to be the stage.

What to make of it

I do not know whether this shirt is funny to you. Humor is not a property of a design; it is a transaction between a design and a viewer. What I can say is that the design is coherent. The phrase, the costume, the board, and the bird all point in the same direction. The joke is not explained, and it is not over-explained. It is compressed into a single frame and left there for you to complete.

If you are thinking about the got too silly shirt as a purchase, the useful question is not whether it is popular. The useful question is whether you want to carry a mugshot board around with you, and whether you are willing to be the person who completes the joke for everyone who reads it. That is a format decision, and it is yours to make.

The bird got too silly. The board is there. The rest is up to you.

The native garment preview for the Cat Daddy Feline Father Lover Pet Owner Funny Tee shows a dark shirt with light lettering: a C and a T on either side of a cat silhouette, and the word Daddy beneath them. That is the whole design. No slogan, no paw-print border, no date. The cat sits inside the word the way a letter sits inside a line of type, and the shirt asks you to read the gap as a syllable.

I want to argue that this is a typographic joke before it is a pet joke, and that the typography is what makes it work. The phrase cat daddy is already a compressed identity — two words that name a particular kind of affection, the man who has decided that a cat is his. The shirt compresses it further, into a diagram. C and T are the frame; the cat is the vowel. You do not read the shirt so much as solve it, and the solving is the pleasure.

The frame and the vowel

Consider what the design refuses to do. It does not print the word CAT in full and then add a cat. It does not stack the words CAT and DADDY like a label on a jar. It splits the first word into its outer consonants and lets the silhouette stand in for the middle letter. This is a rebus, the oldest visual pun in the book — the picture that completes the word. Rebus writing is not a modern invention; it is one of the earliest ways humans made language visible, and it survives in exactly this kind of casual garment because it is cheap, legible, and satisfying to decode.

The silhouette is doing double duty. It is a cat, obviously — ears, haunches, the suggestion of a tail. But it is also an A, or near enough: a shape with a point at the top and legs at the bottom, occupying the slot where a vowel should be. The design does not insist on the resemblance. It trusts you to hear the word cat when you see the frame, and the cat fills the hole. That is a small act of reader address. The shirt assumes a viewer who will complete the joke, and it rewards that viewer with the mild smugness of having got it.

This is the same contract a good subject line makes with a reader. You leave a gap, and the reader fills it. You do not spell everything out; you trust the frame to carry the meaning. The Cat Daddy shirt is a one-line lesson in compression: two letters, one silhouette, one word below, and the whole identity arrives intact.

Why Daddy sits below

The word Daddy is set beneath the frame, in the same light lettering, and it does the work of a caption. It tells you what kind of cat this is — not a cat, but a cat daddy, a father to a feline. The vertical arrangement matters. The frame is the joke; the caption is the claim. Read top to bottom, the shirt says: here is a cat, and here is the role it puts you in. Read the frame alone, and it says cat. Read the caption alone, and it says Daddy. Together they say the thing the wearer wants said, which is that the cat is not a pet but a dependent, and the man is not an owner but a parent.

I am aware that this is a lot of weight to put on a t-shirt. But the shirt is asking for it. The design is spare enough that every element has to carry its share, and the share is larger than it looks. The dark ground and light lettering give the whole thing the quality of a stencil or a rubber stamp — a mark rather than a decoration. It reads at a distance, which is what a garment has to do, and it reads again up close, which is what a joke has to do. The cat silhouette is the only soft shape on the shirt, and it sits in the middle of hard letters like a living thing in a cage of type.

The identity it names

The phrase cat daddy is a specific piece of contemporary pet vocabulary. It names a man who has taken on the caretaking role for a cat and wants the role acknowledged. It is not the same as cat owner, which is a legal description, or cat lover, which is a disposition. Cat daddy is a kinship term, and kinship terms are always a little bit funny because they borrow the gravity of family for a relationship that the culture has not fully decided how to rank. The shirt leans into that. It prints the kinship term and then illustrates it, so that the claim and the evidence arrive together.

What I find interesting is that the design does not need a human figure. There is no man on the shirt, no arms, no lap. The cat is the only creature, and the word Daddy is the only human presence. The wearer supplies the rest. This is a generous design: it leaves room for whoever is actually wearing it, and it does not prescribe a body type, an age, or a particular cat. The silhouette is generic enough to stand for any cat, which means it can stand for your cat, which is the only cat the wearer is thinking about.

That is the quiet craft of the thing. A less careful design would have put a cartoon cat with a speech bubble, or a paw print, or a slogan in a ribbon. This one puts the cat where a letter should be and lets the word do the talking. The restraint is the point. It is the difference between a shirt that announces a personality and a shirt that lets a personality complete it.

What the shirt is not

It is worth saying plainly what the design does not claim. It does not claim that the wearer is a father in the human sense, and it does not need a Father’s Day occasion to make sense. The phrase is a pet-father phrase, and the graphic is a cat, and the two together name a role that exists all year. The shirt is not a greeting card. It is a standing description. That is a different kind of garment, and it asks a different kind of reading: not congratulations on the day but this is who I am, most days.

I also want to be careful about what the shirt does not prove. A design like this tells you nothing about how it wears, how it washes, or how it fits. Those are questions for the listing and for the wearer, not for the artwork. What the artwork gives you is a legible idea, executed with enough precision that you can read it at a glance and then read it again. That is the standard I would apply to any printed object: does the composition hold up when you look at it twice? This one does, because the second look is where the rebus resolves.

The reader’s own frame

If you write for a living, or even for a habit, the Cat Daddy shirt is a useful object to keep on the desk of your attention. It is a reminder that a frame can do the work of a sentence. Two letters and a silhouette carry an identity that a paragraph might struggle to establish. The design trusts the viewer to close the gap, and the viewer does, and the closing is the pleasure. That is not a bad model for a subject line, a headline, or the first line of an issue. Leave the vowel out. Let the reader hear it.

The shirt is available at the Amazon listing for the Cat Daddy Feline Father Lover Pet Owner Funny Tee, where the native preview shows the design as described. I have not worn it, and I am not reviewing its fit. I am reading its typography, which is the part I can see.

Editorial note: This publication and Quicky Cotton Collective share an owner.

The 102KB Clip: Gmail’s Truncation and the Craft of the Front-Loaded Issue

Somewhere in the middle of a long newsletter, Gmail draws a line. Below it, the text stops, an ellipsis appears, and a small link offers View entire message. The reader has not been told the issue is too long. They have been told, in the quiet way interfaces tell us things, that the container has made a decision on the writer’s behalf.

This is the artifact I want to examine: not the growth tactic, not the deliverability scare, but the cut itself. It is a named, observable convention in the inbox, and like most conventions it disciplines the content that passes through it. The question for writers is whether we let that discipline happen to us or whether we practice it deliberately.

What the threshold actually measures

Gmail clips messages whose size exceeds roughly 102KB, hiding the remainder behind a View entire message link. That figure comes from platform documentation rather than a Google page I can cite directly here, so treat it as the working number the sending tools use. Mailchimp’s help documentation states the behavior plainly: “Gmail clips emails that have a message size larger than 102KB, and hides the full content behind a ‘View entire message’ link.”

What counts toward that size is the message source — the HTML, the text, the URLs, the tracking parameters, the markup that styles it all. As Mailchimp puts it, “Each letter—or character—of the code is approximately 1 to 2 bytes.” Hosted image files do not count; only the HTML that references them does. This is the first place writers go wrong. Compressing a photograph will not save an issue from clipping. Rewriting the markup that surrounds it might.

The threshold is also approximate in practice. SendLayer’s guide to inbox clipping notes that “senders report clipping a little under 100KB,” and recommends treating 102KB as a rough boundary rather than an exact one. That is a vendor’s caution, not a standard, but it is a sensible one: the number is a design constraint, not a contract.

Two failure modes that look like one

The most useful thing a writer can understand about clipping is that it conflates two separate variables. One is editorial length. The other is code weight. They are not the same, and confusing them leads to the wrong remedy.

SendLayer makes the distinction directly: clipping “is about the message’s file size, not how long the email reads.” A short-looking issue built from deeply nested tables, repeated inline styles, and leftover HTML comments can cross the threshold while a long, plain-text letter never comes close. The same guide describes how email builders “generate deeply nested tables, repeat inline styles on every cell, and leave HTML comments behind. None of that changes how the email looks. All of it counts toward your 102KB.”

This is the platform’s quiet tax on decoration. Every redundant style attribute, every wrapper table that exists because a builder could not imagine otherwise, every tracking parameter appended to a URL — these are bytes the reader never sees and the writer never chose. When an issue clips, the first question is not “what should I cut?” but “what is in here that I did not put there?”

Non-ASCII characters are a smaller but real contributor. Standard characters take one byte each in UTF-8; accented letters, symbols, and emoji take two to four. A single emoji in a subject line is irrelevant. Hundreds of accented characters across a long template are not. This is not an argument against writing in languages that need them — it is an argument for knowing where the weight sits.

The front of the issue as an editorial decision

Here is where the craft begins. If the container will truncate somewhere, the writer’s job is to decide what belongs above the cut before the container decides for them.

Front-loading is often described as a marketing tactic — put the call to action high, lead with the offer. That framing is too narrow. The real question is editorial: what is the one thing a reader must encounter even if they never click View entire message? For a letter, that is the lede. For an essay, it is the argument’s opening move. For a dispatch, it is the sentence that makes the rest worth continuing. The top of the issue is not a billboard. It is the first paragraph, and it should be written as one.

What belongs below the cut is equally a decision. It should be the continuation — the second movement, the supporting material, the invitation to read further. When the cut falls in the middle of a sentence because the markup ran long, the reader experiences an accident. When it falls at a natural break because the writer planned it, the reader experiences a pause. The bytes are the same. The reading is not.

The deliberate “read more” versus the accidental ellipsis

These are two different artifacts, and writers should prefer the first even when they are nowhere near the limit.

Gmail’s ellipsis is an accident of byte count. It appears where the container decided, not where the writer did. A deliberate read more link is an editorial gesture: it has its own opening sentence, its own destination, its own reason for existing. Mailchimp recommends using “Read More links” when content cannot be cut, noting that this is “more obvious than the link Gmail creates.” SendLayer makes a similar case for leading “with a preview and a ‘read more’ link rather than pasting a whole article.”

The distinction matters because the two artifacts teach the reader different things. The accidental ellipsis teaches them that the email was too heavy. The deliberate link teaches them that the writer made a choice about where the issue ends and the next thing begins. One is a failure of craft. The other is craft.

What clipping does to the reader’s exit

There is an ethical dimension here that is easy to miss when the conversation stays on tracking and deliverability.

SendLayer notes that “clipping can also hide your unsubscribe link, which makes recipients more likely to hit the spam button instead.” That is usually framed as a deliverability problem — complaints hurt sender reputation. But it is also an editorial-ethics problem. The reader’s exit should never be concealed by the container’s truncation. If a writer’s issue is so heavy that the unsubscribe link falls below the cut, the reader has been denied the most basic courtesy of correspondence: the ability to leave.

The tracking consequences are real but placement-dependent, and writers should be honest about that rather than repeating a blanket claim. Mailchimp describes open tracking being clipped along with the message. beehiiv’s documentation states that its open-rate pixel sits at the top of the email, so clipping does not affect its open rate — though readers who click through to view the entire message are not tracked as clicks, because the clipping happens inside the mail client rather than through a tracked URL. The lesson is not “clipping always breaks tracking.” It is “know where your pixels and links sit, and do not let the container decide whether they survive.”

A brief historical analogy, offered as analogy

The idea that display environments truncate is older than Gmail. RFC 5322, the Internet Message Format specification published in October 2008, sets two line-length limits: “Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.” The 78-character recommendation exists, the document explains, “to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line.”

Two things are worth noticing. First, the standards have long acknowledged that readers’ software will truncate, and have long declined to dictate what that software does. RFC 5322 says explicitly that it “is not intended to dictate … any of the characteristics of user interface programs that create or read messages.” The container is not the writer’s to control. Second, the response to that uncertainty was to recommend a conservative format — not to demand that readers change.

This is an analogy, not a causal claim. Gmail’s 102KB threshold is not descended from the 78-character recommendation, and I have no evidence that Google’s engineers had RFC 5322 in mind. But the pattern is instructive: format standards have consistently treated truncation as a fact of the display environment and placed the responsibility for the front of the message on the writer. That responsibility has not changed. Only the number has.

MIME, the extension that made rich email possible, was designed with a similar humility. RFC 2045 notes that “compatibility with existing standards AND robustness across existing practice were two of the highest priorities of the working group that developed this set of documents. In particular, compatibility was always favored over elegance.” The container disciplines the content because the container was built to survive, not to be beautiful.

A practical sequence for the front-loaded issue

None of this requires a particular tool or a particular number. It requires a sequence of decisions, made in the right order.

First, measure the rendered HTML. SendLayer recommends saving the rendered template as an .html file and looking at its size, because “this is the number you can actually act on, since it’s the part you control.” Do this before you start cutting words. You may find the words are not the problem.

Second, cut markup before cutting prose. Flatten nested tables. Consolidate repeated inline styles into a single declaration. Remove HTML comments left by builders. Shorten tracking parameters where you can. These changes are invisible to the reader and recover bytes without touching the argument.

Third, decide what the front of the issue is for. Write the lede as if it were the only thing guaranteed to be read, because under truncation it may be. Then decide where the natural break falls and place the deliberate read more link there — not wherever the byte count happens to land.

Fourth, check the exit. Confirm that the unsubscribe link and any essential account information sit above the likely cut. This is not a growth consideration. It is a courtesy.

Fifth, test with the subject line varied. Gmail groups messages sharing a subject line into a single conversation, and SendLayer notes that “if the whole thread grows too large, Gmail clips it.” This rarely affects production sends, but it catches people testing: send the same test subject twenty times and the later copies may collapse under the trimmed section. Vary the subject or clear the thread before concluding that your issue is too heavy.

What the clip is actually for

The 102KB threshold is not a judgment about your writing. It is a container deciding how much of itself to render inline so that the inbox stays fast. That is a reasonable thing for a mail client to do, and it is not going away.

What is within the writer’s control is the shape of the issue that meets that container. A front-loaded issue is not a shorter issue, necessarily. It is an issue whose first movement was written to stand on its own, whose continuation was designed rather than truncated, and whose reader’s exit was kept visible. The container disciplines the content. The craft is in deciding what discipline the content receives before the container applies its own.

Questions writers actually ask

Does the 102KB limit include image file sizes? No. Hosted images load from a server after the email opens; only the HTML that references them counts toward the limit. Compressing an image will not prevent clipping, but removing an unnecessary image tag and its URL will reduce the message size.

Why did my short-looking email clip? Because clipping measures file size, not visible length. A short email built from bloated markup, repeated inline styles, and long tracking URLs can exceed the threshold while a long plain-text letter does not come close.

Does clipping hurt deliverability? Not directly, on the evidence available. The indirect risk is real: a clipped unsubscribe link pushes readers toward the spam button, and complaints affect sender reputation. Treat the exit as the priority.

Can I prevent Gmail from clipping my emails entirely? By keeping the message source comfortably under the threshold, yes — clipping is a size boundary, not a judgment about content. The exact safe margin varies by sender and by the platform’s own reporting, so measure your rendered HTML rather than trusting a single number.

What if I am the one reading a clipped email? Nothing has been lost. Click View entire message and Gmail opens the full version in a new tab. If the culprit is a long thread rather than a single heavy message, turning off conversation view may help.

Somewhere in the folklore of email, a rule is repeated with the confidence of scripture: lines in email should be 78 characters, because RFC 822 said so. It is a tidy story. It has a date, a document number, and a number that sounds technical. It is also, on inspection, not quite right.

RFC 822, published August 13, 1982, is the standard that gave us the header syntax we still use — the From:, To:, Subject: fields, the folding rules, the address grammar. It is a foundational document. But if you read it looking for a line-length rule, you will not find one. The 78-character figure does not appear in RFC 822. It appears, instead, in RFC 2822, published in April 2001, and it is carried forward into RFC 5322, the current Internet Message Format specification, published in October 2008.

This matters for writers who care about format, because the difference between a rule and a recommendation is the difference between a constraint you must satisfy and a courtesy you choose to extend. The 78-character line is a courtesy. Knowing that changes how you use it.

What RFC 822 actually specifies

RFC 822 is a syntax document. It defines how a message is structured: header fields, a body, the separation between them. It specifies that a header field can be folded — split across multiple lines — by inserting a carriage return and line feed followed by at least one whitespace character wherever linear whitespace is permitted. The purpose of folding is to let long header fields, like a To: line with many recipients, be represented across several physical lines while remaining a single logical line.

What RFC 822 does not do is tell you how many characters a line may contain. It describes the grammar of messages, not their display. The document is explicit that it is not intended to dictate user interface characteristics: “This standard is NOT intended to dictate the internal formats used by sites, the specific message system features that they are expected to support, or any of the characteristics of user interface programs that create or read messages.” Line length, in RFC 822, is a display concern, and display is out of scope.

The 78-character rule that people attribute to RFC 822 is a later addition. It belongs to RFC 2822, which superseded RFC 822, and to RFC 5322, which superseded RFC 2822. The attribution is a case study in how a later document’s recommendation gets retroactively attached to an earlier, more famous standard. RFC 822 is the document people cite; RFC 2822 is the document that actually states the number.

The two limits: 998 and 78

RFC 2822, published in April 2001, is where the line-length rule enters the specification. Section 2.1.1, “Line Length Limits,” states: “There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.”

RFC 5322, published in October 2008 and still the current Internet Message Format specification, carries the same two limits forward in identical language: “Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.”

The distinction between MUST and SHOULD is not decorative. In the terminology these documents use, MUST indicates an absolute requirement. SHOULD indicates a recommendation: there may exist valid reasons to ignore it, but the implications should be understood. The 998-character limit is a hard ceiling. The 78-character limit is a target.

The rationale for each is given in the specification itself. The 998-character limit exists because “many implementations that send, receive, or store IMF messages… simply cannot handle more than 998 characters on a line.” The 78-character recommendation exists “to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line.”

Note the direction of the accommodation. The 78-character recommendation is aimed at senders, asking them to be conservative so that receivers’ displays do not mangle the message. The specification is clear that this is a concession to imperfect implementations, not an ideal: it notes that such implementations are “non-conformant to the intent of this specification” and that “it is incumbent upon implementations that display messages to handle an arbitrarily large number of characters in a line.”

In other words, the spec would prefer that displays handle long lines gracefully. It recommends 78 because many do not.

Where the number comes from

The 78-character figure is not arbitrary, but neither is it derived from the protocol. It is a display-compatibility convention, and its history is the history of the screen.

RFC 3676, “The Text/Plain Format and DelSp Parameters,” published in February 2004, gives the clearest account of the reasoning. This document defines Format=Flowed, a mechanism for marking soft line breaks so that receivers can reflow text to fit their own displays. In describing how to generate flowed text, it states that lines “SHOULD be 78 characters or shorter, including any trailing white space and also including any space added as part of stuffing.” It then explains why:

“In addition to conformance to [MSG-FMT], there is a historical need that all lines, even when displayed by a non-flowed-aware program, will fit in a standard 79- or 80-column screen without having to be wrapped. The limit is 78, not 79 or 80, because while 79 or 80 fit on a line, the last column is often reserved for a line-wrap indicator.”

This is the terminal width that still shapes plain text. The 80-column screen — itself a descendant of the 80-column punched card — is the container that the 78-character line was designed to fit. The number is 78 rather than 80 because two columns are reserved: one for the wrap indicator, and one for the margin that keeps text from touching the edge.

RFC 3676 also notes that the number has never been stable. It suggests that paragraphs longer than 78 characters “could be wrapped using lines of 72 or fewer characters,” and observes that “it has been suggested that 66 character lines are the most readable.” Earlier, RFC 1855, the Netiquette Guidelines published in October 1995, advised a different number entirely: “Limit line length to fewer than 65 characters and end a line with a carriage return.” For interactive talk sessions, the same document suggested no more than 70 characters and no more than 12 lines.

The progression from 65 to 70 to 72 to 78 to 66 is not a story of increasing precision. It is a story of different documents addressing different contexts — mail, talk, flowed text, readability — and arriving at different numbers. The number has tracked display technology and reading practice, not protocol necessity.

What Format=Flowed changes

RFC 3676 is worth understanding because it represents a different approach to the same problem. Instead of asking senders to hard-wrap at 78 characters, Format=Flowed lets senders mark soft line breaks — a space followed by a carriage return and line feed — so that receivers can rejoin the lines and reflow them to fit their own displays.

The problem Format=Flowed addresses is what the document calls “embarrassing line wrap.” As plain-text messages are quoted in replies or forwarded, each line gradually increases in length, eventually being arbitrarily hard wrapped. The result is text that is hard to read and often confuses attributions. Format=Flowed allows the sender to indicate which line breaks are logical paragraph breaks and which are merely soft wraps, so that the receiver’s client can reflow the text appropriately.

This shifts the burden from sender discipline to receiver capability. A sender using Format=Flowed does not need to guess the receiver’s display width; the receiver’s client can reflow the text to fit. The specification notes that as devices with display widths smaller than 79 or 80 characters become more popular, embarrassing line wrap has become even more prevalent, even with unquoted text. Format=Flowed is an attempt to solve that problem at the format level.

For writers, the practical implication is that the 78-character line is not the only option. If your tooling supports Format=Flowed and your audience’s clients can reflow, you can write paragraphs as logical units and let the display handle the wrapping. If not, hard-wrapping at 78 or fewer characters remains the safer choice.

What to do with this

The useful question for a writer is not “what is the rule?” but “what is the receiver’s display likely to do?” The specification’s own rationale points at receiver-side display behavior. The writer’s job is to anticipate the container, not to satisfy a protocol.

A practical heuristic, drawn from the specifications themselves:

• 998 characters is the ceiling you must not cross. Lines longer than this may be rejected or truncated by transport and storage implementations.
• 78 characters is the target you should aim for in plain-text email. It accommodates displays that may truncate or wrap longer lines.
• 72 characters or fewer is a safer target when you expect quoting, forwarding, or narrow displays. RFC 3676 suggests this for wrapped paragraphs.
• Format=Flowed is worth using when your tooling supports it and your audience’s clients can reflow. It lets you write paragraphs as logical units and delegate the wrapping to the display.

None of these numbers is a protocol requirement except the 998. The rest are courtesies, extended from writer to reader, in anticipation of the container.

Why the container matters

The 78-character line is a small thing. But it illustrates a larger point about format: the container disciplines the content. A line length that was chosen to fit an 80-column screen shapes how paragraphs are broken, how quotations are nested, how signatures are formatted. The number is not neutral. It carries the assumptions of the display technology that produced it.

For writers who want to make deliberate format choices, the value of understanding this history is not nostalgia. It is the recognition that the defaults you inherit — the line length your client wraps at, the way it quotes replies, the way it handles long URLs — are not natural laws. They are conventions, with dates and documents behind them. Knowing which number is a rule and which is a courtesy is part of making deliberate choices instead of inheriting platform defaults.

The inbox is a site of editorial independence. The 78-character line is one of its small, persistent constraints. It is worth knowing where it came from, and what it is actually for.

Questions writers ask

Is 78 characters a hard rule?

No. RFC 5322 uses SHOULD, not MUST, for the 78-character limit. The hard limit is 998 characters. The 78-character recommendation is a courtesy aimed at accommodating displays that may truncate or wrap longer lines.

Did RFC 822 establish the 78-character line?

No. RFC 822, published in 1982, specifies message syntax but does not contain a line-length rule. The 78-character figure first appears in RFC 2822, published in 2001, and is carried forward into RFC 5322, published in 2008.

Why 78 and not 80?

RFC 3676 explains that the limit is 78 rather than 79 or 80 because while 79 or 80 characters fit on a line, the last column is often reserved for a line-wrap indicator. The 78-character line is designed to fit a standard 79- or 80-column screen without wrapping.

What is Format=Flowed?

Format=Flowed is a mechanism defined in RFC 3676 that lets senders mark soft line breaks so that receivers can reflow text to fit their own displays. It addresses the problem of “embarrassing line wrap” that occurs when plain-text messages are quoted and forwarded.

Should I use 72 characters instead of 78?

RFC 3676 suggests that paragraphs longer than 78 characters could be wrapped using lines of 72 or fewer characters, and notes that 66-character lines have been suggested as the most readable. The choice depends on your audience and how much quoting and forwarding you expect. Shorter lines are safer for narrow displays.

What about URLs and long words?

RFC 3676 advises that if a word exceeds 78 characters but is less than 998, the agent should send the word as is and exceed the 78-character limit. Breaking a URL across lines can make it unusable. The 998-character limit is the hard ceiling; the 78-character recommendation yields to content that cannot be wrapped.

The garment image shows a rectangle of black-and-white speckle, a dark binding strip down the left edge, and a white ruled label headed COMPOSITION. Inside that label, an outlined ghost and an outlined pumpkin sit side by side. The object is a printed notebook cover on a shirt, not a notebook; the costume is the surface, transferred to a person. I keep returning to that transfer, because a composition notebook is one of the few writing surfaces almost everyone can identify before they can read the label.

That recognition is the design’s real argument. The shirt does not spell out a schoolroom joke or lean on a slogan. It reproduces a container — the marbled cover, the binding, the ruled label — and lets the viewer finish the sentence. A ghost and a pumpkin inside the label tell you the season; the label itself tells you the genre. The joke is completed by whoever looks at it, which is a different kind of humor from a printed punchline. It is closer to a rebus than a caption.

I want to be careful about what the image actually shows. The label is white and ruled, the lettering reads COMPOSITION, and the two figures are outlines rather than filled shapes. The speckle is black on white, the binding strip is dark, and the whole cover sits as a rectangle on the garment. Those are visual observations from the retail image, not claims about fabric, fit, or how the print behaves after a wash. What I can say is that the design treats the notebook cover as a legible unit — a thing you read at a glance — and that the ghost and pumpkin are placed where a name or subject line would ordinarily go.

That placement is the interesting decision. On a real composition notebook, the label is where you write your name, your class, the thing that identifies the book as yours. Here the label is pre-filled with two seasonal figures, which means the shirt arrives already labeled — already claimed, in a sense, by the occasion. The wearer does not have to write anything. The costume is complete before it is put on. I find that slightly funny and slightly melancholy: a writing surface that has been relieved of the obligation to be written on.

There is a practical reading, too. Group costumes usually require coordination — matching shirts, a shared theme, a decision made in a group chat. A composition notebook cover is a low-effort unit of coordination because everyone already knows what it looks like. You do not have to explain it. The shirt does the explaining. That is the same reason the notebook survives in classrooms: it is a default, and defaults are legible. The design borrows that legibility and spends it on a Halloween joke.

If you are the reader who notices typography, the label is the part to look at. It is ruled, which means the lines are doing work even though there is no handwriting on them. The rules imply a hand that could write, and the ghost and pumpkin occupy the space where that hand would go. The design is therefore a kind of empty form — a form filled with a drawing instead of a name. I read that as a small joke about costume itself: you put on a surface that says I am a notebook, and the surface says I am a Halloween notebook, and the viewer supplies the rest.

The shirt is listed as Composition Notebook Costume Teacher Group Halloween by Quirky Cotton Collective. The retail title uses the phrase composition notebook shirt, and the image supports the description: a speckled cover, a binding strip, a ruled label, a ghost, a pumpkin. What the image does not support is any claim about comfort, durability, or how the print reads in person. I have not worn it. I am reading the artwork, which is the only thing the observation establishes.

The broader point is about containers. A composition notebook is a container for writing, and the shirt is a container for a joke about containers. The design works because it does not over-explain. It trusts the viewer to recognize the cover, read the label, and complete the seasonal reference. That is a modest craft, but it is craft: the choice to leave the punchline implicit, to let the surface do the talking, to make the costume a thing you read rather than a thing you announce.

For a reader who spends time thinking about format, the shirt is a useful reminder that recognition is a design material. You can build a joke out of a shape people already know. You can let a label carry the weight. You can trust the viewer to finish the sentence. The composition notebook cover does all three, and it does them without a single word of explanation beyond the one printed at the top.

Editorial note: This publication and Quirky Cotton Collective share an owner.