How to Write a Plain Language Summary for Your Paper

A funder's grants officer sends back a plain language summary with one line of feedback: this reads like the abstract. The two documents sit one page apart in the same submission, cover the same study, and are judged by completely different rules. Treating the second as a shorter version of the first is the single most common way a plain language summary fails. Increasingly, funders and journals need both, and treat them as distinct.

Learning how to write a plain language summary means unlearning some habits first. An abstract rewards density, technical precision and careful hedging, compressing a study into as few words as a specialist reader will accept. A plain language summary rewards the opposite: short sentences, defined terms, and a reader who has never heard of your method and is not going to look it up.

What a Plain Language Summary Actually Is (and Who Requires One)

A plain language summary is a short, jargon-free account of what a study asked, what it did, and what it found, written for a reader outside the field entirely: a funder's board, a patient charity, a journalist, a future version of you skimming your own back catalogue years later. Cochrane's own standard for writing one, in place since 2013, caps it at 850 words, shorter than the 1,000-word abstract sitting next to it. UKRI, the NIHR and Horizon Europe now expect one from grant holders, in an application or a final report, and a growing number of journals ask for one alongside the technical abstract at submission. It is one more field to get right inside the wider journal submission process, alongside the cover letter, the keywords and the reference list.

Why Good Abstract-Writing Habits Work Against You

The opposite is true for plain language summaries. Everything that makes an abstract good makes a first-draft plain language summary bad. If you write something that's designed to be dense and technical with the goal of getting your key concepts across in 250 words, say, to a specialist skimming a database, it reads like a wall of unexplained terms if you try to make it readable to someone outside the field. The same goes for hedging language, the qualifiers a careful researcher adds so a claim is not overstated to a peer reviewer, which does the opposite job for a lay reader: it reads as uncertainty about whether the finding is real at all, rather than precision about its exact scope.

The fix relocates the caution instead of deleting it. Cochrane's own guidance recommends narrative statements in place of raw statistics: instead of a hazard ratio and a confidence interval, write that a treatment probably reduces a symptom, or that the evidence so far is too limited to say either way. That one word, probably, carries the hedge a specialist would expect from three lines of statistics, without asking a lay reader to interpret an interval they were never trained to read.

What to Do With a Technical Term You Cannot Cut

Some terms cannot be cut, only explained. A study about anticoagulants has to name the drug class somewhere, and swapping in a vaguer phrase just moves the confusion rather than removing it. Cochrane's guidance for its own reviewers gives a specific technique: put the plain-language version first and the technical term in brackets directly after it, in the same sentence it first appears, rather than defining it in a glossary the reader has to scroll back to. Blood thinners (anticoagulants) is the example Cochrane's own guidance uses. The reader who already knows the drug class gets the precise term, and the reader who does not gets a working definition in the same breath.

• Define a term the first time it appears, in the same sentence, not in a glossary at the end
• Use the everyday word first and the technical term in brackets after it, not the reverse
• Replace a broad research-jargon word with what it actually names: swap 'participants' for 'the 40 people in the study'
• Explain an acronym on first use even when it feels like common knowledge inside your own field
• Keep a technical term only if a reader searching for your work by its proper name would expect to see it

A first draft generated by a general-purpose chatbot usually fails the same way an abstract does: it keeps the hedging and the vocabulary of whatever you fed it, because it is mimicking your register rather than replacing it. An AI humanizer for academic writing rewrites sentences you already drafted into plainer, more natural ones without inventing new claims, which is a more useful starting point than a prompt written from scratch, though the reading-level and glossary work above still has to happen by hand afterward.

Reading-Level Targets, and Who Sets Them

There is no single reading-level rule, because there is no single body that owns the format. Each funder or publisher that requires a plain language summary sets its own target, and the targets differ by design, not by accident, because the audiences differ too.

Cochrane's own reasoning is the most explicit, and worth borrowing even for a summary that has nothing to do with Cochrane. It indicates starting from 84 percent, which is what the UK's 2011 Skills for Life survey found was the percentage of adults who read at a level of 11 years old or older, the same reading age UK newspapers and the National Health Service's own content guidelines target, suggesting aiming there for a UK audience. It then says that, since reading levels vary in other countries, this number is a starting point. It is a suggestion, not a fixed rule for every summary everywhere.

Who sets the target	Length	Reading level guidance
Cochrane (systematic reviews)	400 to 850 words, including the title	Around an 11-year-old UK reading age, as a starting point for a UK audience
NIHR and UKRI (UK research funders)	Commonly 150 to 300 words	No single published formula; written for a member of the public with no research background
Horizon Europe (EU research funding)	No fixed word limit, one short stand-alone paragraph	Plain, jargon-free language for a non-specialist reader
A journal requiring one alongside the abstract	Often 100 to 150 words	Set by that journal's own author instructions, not a shared standard

How to Write a Plain Language Summary: A Worked Example

Here is the kind of sentence most abstracts contain, built to be typical rather than quoted from any real paper, next to a plain language version of the same claim.

Abstract version: Adherence to the intervention was moderate (62%), and although a statistically significant reduction in HbA1c was observed in the treatment arm relative to control (p<0.001), the clinical significance of this effect remains uncertain given the heterogeneity of baseline glycaemic control across sites.

Plain language version: About 62 out of 100 people stuck with the programme for its full length. People taking part had lower blood sugar (measured by HbA1c, a blood test that shows average blood sugar over 2 to 3 months) than people who did not take part. We do not yet know how much this would matter for someone's day-to-day health, because people's blood sugar levels at the start varied a lot between the hospitals taking part.

Four moves did the work: the percentage became a plain count out of 100, the p-value disappeared in favour of a narrative statement about what was actually found, the technical term got a bracketed definition in the sentence where it first appeared, and the hedge moved from a phrase about statistical significance to a plain sentence about what is not yet known. None of the underlying finding changed. Only the reader it was written for did.

Choosing keywords for a research paper is covered separately, as is getting the paper indexed and found once it is published.

A plain language summary generator that starts from this register instead of your abstract's is a faster way in than beginning from the abstract and cutting it down. Whichever way you start, hand the result to someone outside your field before you submit it. If they cannot explain your finding back to you in one sentence, the summary is not finished yet, no matter how many words are left in the limit.