Readability Score: What It Means for Your Documentation

Your help article is accurate, complete, and reviewed. Readers still open a support ticket asking how to do the thing it explains. Often the problem isn't what the article says. It's how hard it is to read.

A readability score gives you a quick, objective signal about that. This guide explains what the score measures, which target fits your audience, where the number can mislead you, and the specific edits that move it in the right direction.

What is a readability score?

A readability score is a number that estimates how hard a piece of text is to read, based on how long its sentences are and how long its words are. Shorter sentences and shorter words produce an easier score. Most scores are reported either on a 0–100 scale or as a school grade level.

Usability researchers at Nielsen Norman Group separate three different things that are easy to mix up:

• Legibility: can people see and recognize the characters? That's typography.
• Readability: how complex are the words and sentences? That's what a readability score estimates.
• Comprehension: do readers understand the meaning and draw the right conclusions? That's the real goal.

A readability score only covers the middle layer. Keep that in mind; we'll come back to it.

How Flesch Reading Ease works

The most common readability score is the Flesch Reading Ease test, created by Rudolf Flesch. It uses two inputs: average sentence length and average syllables per word.

Flesch Reading Ease = 206.835 − 1.015 × (words ÷ sentences) − 84.6 × (syllables ÷ words)

Higher is easier. Scores usually fall between 0 and 100:

Because the syllable term carries a large weight, long words pull the score down fast. One "functionality" where "feature" would do costs you more than you'd expect.

Flesch–Kincaid grade level and its roots in technical manuals

The second score you'll see is the Flesch–Kincaid grade level. It uses the same two inputs but reports a U.S. school grade instead of a 0–100 number:

Grade level = 0.39 × (words ÷ sentences) + 11.8 × (syllables ÷ words) − 15.59

A result of 8.0 means a typical eighth grader should be able to read the text.

This formula has a direct link to documentation. In 1975, J. Peter Kincaid and his colleagues recalculated readability formulas for the U.S. Navy. They tested 531 enlisted personnel at technical training schools and measured how well they understood passages from the Navy's own training manuals. In other words, one of the most widely used readability scores was calibrated on people reading technical instructions.

What readability score should documentation aim for?

There's no single right number, because the right target depends on who reads your docs. Two reference points help:

• General audiences: Nielsen Norman Group recommends writing so that an eighth grader can understand the text with minimal effort. On the Flesch scale, that's roughly 60–70.
• Educated or specialist audiences: for B2B and specialist readers, the same researchers suggest a 12th-grade level is often a good target.

For most documentation, a sensible approach looks like this:

• Customer-facing help centers and user manuals: aim for plain English, around grade 8 or a Flesch score of 60 or above.
• Internal docs for specialists, such as admin guides or runbooks: grade 10–12 is acceptable, as long as the extra difficulty comes from necessary terms, not long sentences.

Don't assume experts want harder text, though. UK government content guidance notes that research shows people with higher literacy levels also prefer plain English, because it lets them take in information faster.

Where readability scores mislead

A readability score is a useful smoke alarm, not a verdict. Nielsen Norman Group calls the formulas "only an approximation" of how hard text really is to understand. Watch for these traps:

• Necessary terms lower the score. A word like "authentication" adds syllables, but if your readers know it, it helps them. Specialist audiences understand their own vocabulary.
• Short doesn't mean clear. "Toggle it. Then sync. Done." scores as very easy and still confuses people. Formulas can't tell whether a sentence makes sense.
• Layout is invisible to the formula. Readability formulas were originally developed for school books, and they ignore layout. A wall of text and a well-headed page with a numbered list can score the same, even though the second is far easier to use.
• Chasing the number backfires. Splitting every sentence and swapping every long word can make docs choppy and vague.

Use the score to find passages worth a second look. Then judge those passages as a reader would.

How to check your documentation's readability score

You don't need to score every page at once. A quick, repeatable check works better:

1. Pick your most-visited pages. Start where readability problems affect the most readers, such as getting-started guides and your top help articles.
2. Score each topic separately. An average across a whole manual hides the one dense page that generates tickets.
3. Sort by worst score. Fix the hardest pages first. They usually have a few very long sentences doing most of the damage.
4. Edit, then re-score. Make the changes below and check that the score moved for the right reasons, not just because you cut useful detail.
5. Set a team standard. Agree on a minimum score per audience so every author aims at the same target.

How to improve readability in technical writing

These five edits do the most work, and each one raises your score for the right reasons.

1. Split long sentences

Sentence length is half the formula. GOV.UK's content guidance suggests splitting sentences over 25 words. In instructions, aim for one action per sentence.

Before (29 words): "Before you begin the configuration process, you should make sure that all of the necessary permissions have been assigned to the user accounts that will be accessing the dashboard."

After (3 sentences, 19 words in total): "Before you start, check permissions. Each user who needs the dashboard must have access. Assign any missing permissions first."

2. Choose shorter, everyday words

Swap formal words for common ones when the meaning is the same: "use" for "utilize," "help" for "facilitate," "start" for "initiate," "buy" for "purchase." Keep the technical terms your readers actually need, and explain each one the first time you use it.

3. Use the active voice

"Select Save" is shorter and clearer than "The Save button should be selected." Active voice tells readers who does what, which matters most in step-by-step instructions.

4. Keep paragraphs short

GOV.UK guidance suggests no more than five sentences per paragraph. In docs, two or three is often better. Short paragraphs give readers more places to rest and more entry points when they scan.

5. Add structure the formula can't see

Descriptive subheadings, numbered steps, and bulleted lists won't change a Flesch score much. They do make pages much easier to use. Check that headings appear regularly, so no section turns into a wall of text.

Make readability part of your publishing workflow

Readability checks work best when they happen while you write, not after a reader complains. Sonat includes a built-in readability analyzer that scores each topic as you write. It checks Flesch Reading Ease, passive voice, transition words, paragraph length, and how evenly subheadings are spread. You can also set readability rules in your approval workflow, so a topic that falls below your standard can't be published until someone fixes it. Readability metrics are included on every plan, including the Free plan.

Write for the reader, check with the score

A readability score won't write clear documentation for you. But it will point to the long sentence, the stacked jargon, and the paragraph that never ends. Pick a target that fits your audience, fix what the score flags, and read the result as your customer would.

For more on clear writing, see our guides to plain-language technical writing and writing step-by-step instructions, or explore Sonat's documentation features.