How to Prompt AI to Change Reading Level

"Rewrite this at a 6th grade level" produces something shorter that has quietly dropped the condition your legal team put there.

Steve Jefferson
Steve Jefferson
Developer Advocate
27 August 20261 min read

The reliable way to prompt AI to change reading level is to stop naming a grade and start naming the four things a grade number is a proxy for: sentence length, vocabulary, structure and assumed knowledge. Ask for "8th grade" and you get text optimised for the shape of a readability formula. Ask for "sentences under 20 words, no term a non-specialist would need to look up, one idea per paragraph, and define any word you cannot avoid" and you get text a person can actually follow.

The difference is not cosmetic. Grade-level prompts routinely produce output that scores well and means less than the original.

Why grade numbers fail when you prompt AI to change reading level

Readability formulas like Flesch-Kincaid count syllables and sentence lengths. They do not read. A sentence can score at fourth-grade level and be incomprehensible, and a long sentence can be perfectly clear.

Ask a model to hit a grade and it optimises toward the visible signal. Two failure modes follow, and both are easy to miss on a skim.

It cuts rather than simplifies. Simplifying "you must submit the form within 30 days of the decision, unless you have applied for an extension" into "send the form within 30 days" scores beautifully. It also deleted the exception, and someone is going to miss a deadline because of it. The model shortened the sentence and lost a clause that carried a condition.

It replaces precision with vagueness. "Anaphylaxis" becomes "a bad reaction". "Your claim will be assessed" becomes "we will look at it". Shorter words, less information. In a medical or legal context that is not a simplification, it is a different statement.

Both come from the same root: the model was told to hit a number and nothing told it what must survive.

The four constraints that actually work

Replace the grade with the mechanics.

Sentence length. Give a ceiling and permission to split. "No sentence over 20 words. Split long sentences into two rather than using semicolons." A ceiling with a splitting instruction is far more effective than "use short sentences", which the model interprets loosely and abandons by the third paragraph.

Vocabulary. Name the test rather than the level. "Replace any word a general reader would need to look up. If a technical term cannot be replaced without losing accuracy, keep it and define it in the same sentence on first use." That last clause is what prevents the vagueness failure. It gives the model a legitimate way to keep a precise word.

Structure. "One idea per paragraph, maximum three sentences. Use a bulleted list wherever the original has three or more parallel items. Put the action the reader needs to take first." Structure carries more of the perceived difficulty than word choice does, and it is the constraint most people omit.

Assumed knowledge. "Assume the reader has never used this product and does not know what an API is." Naming the reader is more useful than naming a grade, because it tells the model which specific gaps to fill.

Add a preservation list

This is the part that separates a usable rewrite from a liability. Before the model rewrites anything, tell it what it is not allowed to lose:

text
Preserve exactly, without rewording:
- every number, date, deadline and monetary amount
- every condition, exception and "unless" clause
- all legal or regulatory terms, defined in place if needed
- the sequence of any numbered steps

If a sentence cannot be simplified without losing one of the above,
keep the original sentence and add a short plain-language sentence
after it that explains what it means.

That final instruction is the important one. Without an escape hatch, a model given an impossible constraint will pick one to violate, and it usually picks accuracy because that is the invisible one. Giving it a legitimate alternative means it takes that instead of quietly dropping a condition.

A prompt that puts it together

text
Rewrite the text below for a reader with no background in this subject.

Rules:
1. No sentence over 20 words. Split rather than joining with semicolons.
2. Replace any word a general reader would look up. If a term is
   necessary for accuracy, keep it and define it in the same sentence
   on first use.
3. One idea per paragraph, maximum three sentences. Convert any run of
   three or more parallel items into a bulleted list.
4. Lead with what the reader has to do, then explain why.

Preserve exactly: all numbers, dates, deadlines, amounts, conditions
and exceptions, and the order of any steps. If a sentence cannot be
simplified without losing one of those, keep it as written and add one
plain-language sentence after it.

After the rewrite, list every place where you kept the original wording
and say why.

TEXT:
"""
{text}
"""

The closing instruction is the quality control. A list of five preserved sentences with reasons is a genuine signal that the constraints were applied. An empty list on a dense legal paragraph means the model steamrolled something, and you know exactly where to look. This is the same self-reporting trick as prompting AI to check its own work, applied to a specific risk.

Going the other direction

Raising the reading level comes up less often and goes wrong differently. Asked to make text "more professional", models reach for padding: nominalisations, passive voice, and phrases that add syllables without adding meaning.

Be specific about what you want instead. If you need precision, say "use the exact technical term for each concept and remove hedging". If you need concision for an expert audience, say "assume the reader knows the field, cut all background explanation, keep every specific detail". Neither of those is "more formal", and both produce something better than what "more formal" returns.

The one genuinely useful upward rewrite is the domain translation: taking a plain description and rendering it in the vocabulary of a specific profession, so a clinician or an auditor recognises it as written for them. Name the profession and the document type rather than a register.

Checking the result

Three checks, in increasing effort.

The number sweep. Extract every number, date and amount from the original and confirm each one appears in the rewrite. This is mechanical, it takes a minute, and it catches the most damaging class of error. Do it every time.

The condition sweep. Search the original for "unless", "except", "only if", "must", "may not", "before" and "after". Every one of those marks a constraint. Confirm each survived in some form.

The naive reader test. Give the rewrite to someone who does not know the subject and ask them what they are supposed to do. If they get it right, you are done. If they hedge, the structure is still wrong, and no amount of vocabulary work will fix a structure problem.

Run the first two on every rewrite and the third on anything that goes to customers. The number sweep in particular is worth scripting if you are doing this at volume: pull every digit sequence, date and currency amount out of both versions and diff the two lists. It takes an afternoon to write and it catches the errors that would otherwise reach a reader, which is a better use of effort than another round of prompt tuning.

If you are producing plain-language versions for a public-facing service, the W3C guidance on reading level sets out what accessibility standards actually ask for, which is usually a supplementary plain version rather than a replacement. The same instinct applies to product interfaces, and making an AI-built app accessible covers the rest of that ground.

Keeping it consistent across a set of documents

For a one-off, the prompt above is enough. For a batch, two additions matter.

Fix the vocabulary decisions in advance. Give the model a short glossary of the terms it must keep and the approved plain-language equivalents for terms it should replace. Otherwise each document invents its own translation and your set becomes inconsistent, which is worse than uniformly difficult.

Do one document, correct it by hand, then feed the corrected pair back as an example for the rest. Two or three worked examples move output quality further than any amount of instruction refinement, which is the same effect at work in following a style guide without repasting examples and in matching a brand voice. The general principles behind all of this live in our prompt engineering guide.

FAQ

What reading level should I target?

For general public communication, aim for something a competent adult can read quickly rather than a school year. Most plain-language guidance lands around the level of a broadsheet news article. If a regulator has given you a specific target, use theirs.

Can AI tell me the reading level of the output?

It can estimate, and the estimate is unreliable because the model is not running the formula, it is guessing at it. If you need a score, compute it with a readability library rather than asking.

Why does the model keep adding words like "simply" and "just"?

Those are its idea of friendliness, and they are worth banning explicitly. "Do not use simply, just, easy, or obviously" is a one-line addition that improves the output, since telling a struggling reader that something is easy is the opposite of helpful.

Should I rewrite or add a summary?

For anything with legal weight, add rather than replace. Keep the authoritative text and put a plain-language summary above it. You get comprehension without accepting the risk that a rewrite changed an obligation.

Does this work for languages other than English?

The four constraints transfer, but the sentence-length ceiling does not. German and Finnish carry more meaning per word than English does, so a 20-word ceiling is unnaturally tight. Set the ceiling from a sample of good writing in that language rather than reusing the English number, and see translating text while keeping the tone for the related problem.

How did this land?

About the author

Steve Jefferson
Steve Jefferson

Developer Advocate

Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.

Share

Get the next post in your inbox

One email a month. Product updates, engineering posts, and the best of Built with Swarmz.

I agree to receive emails about AI building tips and Swarmz product news. Unsubscribe any time.