← Blog

The 125-Character Alt Text Myth — Where It Came From, and What Actually Matters

Where the 125-character alt text "limit" really comes from (hint: it's not WCAG), why it's a myth, and what actually matters when writing alt text.

Panopt ·
Person's hands on a white keyboard typing while viewing a tablet displaying the Pexels website with a gallery of landscape and nature shots including mountains, valleys, and scenic views

If you’ve written alt text professionally, you’ve run into the number. 125 characters. Sometimes 120, sometimes 150, depending on which style guide you’re reading, but always presented the same way: as a hard ceiling. A rule. The thing your screen reader will punish you for ignoring.

It’s not a rule. It’s a 20-year-old misreading of one screen reader’s reading behavior, and it’s been repeated so often that almost nobody bothers to check where it actually came from. So let’s check.

Where the number actually comes from

The trail leads back to JAWS 6.0, a screen reader released in 2005. Terrill Thompson documented its behavior in his long-running ALT Length Test: JAWS 6.0 read alt text in chunks of 125 characters, and if the text exceeded that, it split the announcement into multiple segments — each one picking up exactly where the last one left off. Nothing was lost. Nothing was cut. It just got read in pieces, like a long sentence broken across two breaths instead of one.

That’s a chunking behavior, not a limit. But it looked like a limit if you weren’t listening closely, and over the next two decades, “JAWS chunks long alt text at 125 characters” quietly mutated into “alt text gets truncated at 125 characters” — which is a different, and false, claim.

What’s been genuinely useful to confirm is just how thin the original guidance actually was. Someone went back through accessibility books published between 2002 and 2012 — Thatcher, Slatin and Rush, Joe Clark, Sarah Horton, Wendy Chisholm — looking for the source of the limit. Almost none of them mention a character count at all. The ones that do are nowhere near consistent: Joe Clark’s Building Accessible Websites puts the convention at 1,024 characters. Jeremy Sydik’s Design Accessible Websites suggests 40–80. A French accessibility guide recommended 80 characters, but explicitly as a soft cutoff before you’d want a long description, not a hard wall. None of this looks like the tidy, universal “125” you see cited today. The number didn’t come from a standard. It came from one screen reader’s internal text-chunking logic, and it calcified into folklore because it was easy to repeat and nobody circled back to the source.

Why it doesn’t hold up today

Modern screen readers don’t truncate alt text, full stop. A CSS-Tricks investigation that went looking for the actual technical justification behind the 120–125 character conventions used across major platforms came up empty — no current screen reader stops announcing partway through. Lynx reads the whole thing. JAWS today reads the whole thing, just possibly in chunks. The myth isn’t just outdated; it was never quite accurate even when the chunking behavior it was based on was current.

The W3C’s own accessibility working group has spent years openly resisting the idea of an official character limit, for reasons that are worth sitting with: a hard limit discourages people from describing images that genuinely need more words, language and writing-system differences mean the same description runs to wildly different lengths across languages, and most formats and platforms don’t even offer a “long description” fallback for when short alt text isn’t enough. A number that works for English doesn’t work for German. A number that works for a product photo doesn’t work for a data-dense chart. WCAG has deliberately never codified one.

So why does “keep it short” still hold up?

Here’s the part that’s easy to lose in the mythbusting: the advice to stay concise is still good advice. It’s just not anchored to the reason most people think it is.

The real constraint is about pausing, not character counts. As a screen reader user navigating element by element, you don’t get to pause partway through an alt text announcement, skim ahead, and pick back up — moving to the next element abandons what’s playing and starts the new one. You either hear the whole thing or you move on. There’s no skimming a long alt text the way you can skim a paragraph of body copy with your eyes. That’s friction that scales with length regardless of whether anything technically cuts the text off. NN/g frames this directly in their guidance on writing alt text: people can’t pause and resume mid-alt-text without going back to the beginning, so length itself becomes a tax on the listener’s patience and working memory.

Which is also the actual argument for front-loading: lead with the most important information first, because the user might disengage before the announcement finishes, and you want them to have gotten the point of the image even if they bail with a few words left to go.

The contradiction worth being honest about

Here’s where it gets genuinely interesting, and where I think most guidance oversimplifies. NN/g’s claim — that you can’t pause and resume without restarting — is true for ordinary element-to-element navigation. But it’s not the whole story on every platform.

On Mac VoiceOver, there’s a dedicated pause command: hit Control mid-announcement and the speech halts. Hit it again, and VoiceOver resumes exactly where it left off, not from the top. Two independent sources document this — a recent rundown of go-to VoiceOver commands and a longer practitioner guide on taming VoiceOver’s chattiness — and both describe the same behavior: it’s a real pause, not a restart.

So both things are true at once, and the nuance matters. If a user navigates away from an alt text mid-read, they do lose their place and have to start over on return. But if they deliberately invoke the pause gesture, they don’t. NN/g’s framing makes pausing sound categorically impossible, when it’s actually navigation-method-specific — true for the common case, not true for every case. The honest version of the advice is: don’t write alt text banking on the user being able to bail and return seamlessly, because for most of how people actually move through a page, they can’t. But don’t repeat “screen readers can never pause” as a blanket technical fact either, because for the smaller set of people who know the pause gesture, it isn’t one.

What this actually means for writing alt text

Drop the character count as your north star. It was never really a technical ceiling, and treating it as one leads to two predictable failure modes: chopping real information out of a description to satisfy an arbitrary number, or writing to the number instead of writing to the image.

Write to the image instead. Some images need 40 characters. Some — a complex chart, a screenshot dense with on-screen text — genuinely need more, and a long description or restructured page copy is the right tool, not a tighter word count. The actual discipline isn’t counting characters; it’s asking what a listener needs to know, leading with that, and stopping once you’ve said it. Concise because the content earned it, not because a 20-year-old screen reader’s chunking behavior says so.

This is the same instinct behind how Panopt, our Chrome extension for AI-generated alt text, approaches tone. We didn’t build five tone options — Neutral, Editorial, Conversational, Technical, Marketing — to help people hit a number. We built them because the right alt text for a product photo and the right alt text for an infographic aren’t the same shape, and a single rigid rule was always going to fail one of them. Taste includes accessibility, and taste doesn’t come from a character counter.

Add Panopt to Chrome →

Sources