How to Write a Summary That Proves You Understood It

Here is how to write a summary: read the source once, close it, and state its main claim from memory in one sentence. Then add the two or three supporting points that hold that claim up, in your own words, in the order the author argued them. Cut examples, asides and anything you would not defend if challenged. Check the result against the original, fix what you got wrong, and stop. Most summaries fail because they start with step four.

I have written a few thousand summaries in four years of building small reading tools: for clients, for myself, and for a pile of saved links that never shrinks. What follows is the version I would give a friend.

What is a summary actually for?

A summary is a decision, written down. You are deciding what the source says, and what part of it matters to the person who will read your version. Those are two different decisions, and mixing them up is the most common mistake.

A school summary answers "did you understand this?" A work summary answers "what do I need to know without opening the original?" A personal summary answers "will I want this back in six months?" The same article produces three different pieces of writing.

Before you write a word, name the reader. If the reader is you in six months, you can be blunt and keep one odd detail that only you would care about. If the reader is a manager, lead with the conclusion and the number. If the reader is a teacher, show that you tracked the argument, not just the topic.

How do you find the main idea without rereading everything?

Read the source once at normal speed. Do not highlight. Highlighting feels like work, and a large review of study techniques found that summarization, highlighting and rereading all rated low utility compared with practice testing and spacing. That finding is about studying, but the warning carries over: the tools that look busiest are rarely the ones doing the thinking.

Instead, stop at the end of each section and ask one question: what did that section add that the previous one did not? Write the answer in five words or fewer, in the margin or on a card. After a long article you will have six to ten scraps. Those scraps are your outline, and you made it without copying a single sentence.

Then look at the scraps and find the one the others lean on. That is the main claim. If two scraps seem equally central, the author probably has two arguments, and you should say so in the summary instead of picking a winner.

Why close the source before you write?

Because the first sentence you write with the source open is almost always the author's sentence with a few words swapped. That is paraphrase, not summary, and it hides whether you understood anything.

Close the tab. Turn the book face down. Write the main claim from memory, as if you were explaining it to someone across a table.

Two things can happen. Either the sentence comes out clean, and you can move on. Or it comes out vague, full of "it discusses" and "it looks at", and you have learned something useful for free: you did not understand the piece yet. Go back, reread the one section you are missing, and try again.

A meta-analysis of ten learning techniques put summarization at an effect size of 0.44, the lowest of the ten but still a real effect, while practice testing reached 0.74. Writing from memory is a small act of practice testing. That is why this step matters more than any template.

How long should a summary be?

The old classroom rule says no more than a third of the original, or half at the outside. It is a fine rule for an essay and a bad one for the real world, because it ties the length of your summary to the length of the source rather than to the job.

A better rule is to set the length by the decision it supports:

• One sentence if the reader only needs to know whether to open the source.

• Around 150 words if the reader needs the claim, the evidence and the catch.

• A page if the reader must act on it without ever seeing the original.

I keep most of my own at 150 words, because that is roughly what fits on an index card and what I will actually reread. Past 250 words, a summary stops being a summary and becomes a second, worse article.

What belongs in the summary, and what gets cut?

Keep the claim, the strongest reason, the number that carries the argument, and the author's conclusion. Cut the anecdote, the second and third examples, the history of the problem, and every sentence that begins with "interestingly".

Write in the present tense and name the source once at the top: "Dunlosky and colleagues argue that...". Reporting verbs such as argues, finds, concludes and disputes keep the ideas the author's and leave your opinion out of it. If you do have an opinion, put it in a separate line, clearly marked, after the summary. A summary with your verdict smuggled in is neither honest nor useful.

Skip the habit of lifting the first sentence of every paragraph. It works on badly structured news articles and fails on anything with an argument, because the topic sentence is often a setup and the point arrives in the third line.

Use transitions. Summaries compress, and compressed text jumps. Words such as "however", "because" and "as a result" are the only thing keeping a reader from feeling the jolts.

When should a tool do the first draft?

Honestly, often. If the goal is to decide whether a long article deserves your time, a model can give you a 150-word read in seconds, and that is exactly the pain the whole category of reading tools exists to solve. Use it as triage.

But a tool cannot do the one part that makes a summary yours, which is deciding what matters to your reader. The risk is real: a smooth paragraph that reads well and quietly drops the caveat the author spent a page building. I have shipped that mistake myself, in a client brief, and it was the caveat that mattered.

My rule is short. Let the tool summarize what you will skim. Write by hand what you will rely on. And when the two disagree, believe the source.

Tools that keep your reading and your own notes in one place make this easier, because the machine draft and your corrected version sit side by side.

If you keep your summaries as linked notes, a plain local app is hard to beat.

For summaries that live inside team documents, Notion's built-in assistant is the shortest path from page to draft, as long as you read the draft with the source open.

And if your saved links are the real problem, a quiet read-later app with a short queue does more than any summary template.

Does the method change for papers, videos and books?

The order stays the same. Only the place where you look for the main claim moves.

For a research paper, start with the abstract and the final paragraph of the introduction, then read the results and the limitations. Your summary should say what was tested, what was found, and how sure the authors are. The last part is the one people drop, and it is usually the most useful.

For a video or a podcast, the structure is hidden, so you build it yourself. Pause every few minutes and write one line. Spoken arguments wander, and a transcript with timestamps lets you check a claim in seconds instead of scrubbing through an hour.

For a book, summarize by chapter and then summarize your summaries. A book-length argument almost never fits in one pass, and trying to hold it all in your head is how you end up quoting the opening and the epilogue and nothing between them.

For a news story, the job is the reverse. The key facts sit at the top, so your effort goes into checking what is missing: who is quoted, who is not, and what the headline claims that the body does not support. A short summary of a thin story should come out short. If it does not, you are padding.

In every case, keep one line at the bottom for what you still do not know. It costs ten seconds and saves you from treating your own summary as the whole truth later.

To see the gap between a good summary and a bad one, take a hypothetical article arguing that remote teams meet less but decide slower.

A bad summary: "The article discusses remote work and how meetings affect decisions. It looks at several teams and talks about communication. The author has interesting views on the future of work."

A good one: "The author argues that remote teams hold fewer meetings but take longer to reach decisions, because context that used to travel in hallway conversation now has to be written down. Across the three teams studied, decisions slowed by about a day once they depended on written approval. The author concludes that teams should write shorter decision memos rather than add more calls."

The first could describe a thousand articles. The second could describe only one. That is the test: if your summary fits many sources, it is a topic label, not a summary.

A five-minute routine that holds up

You do not need a method with a name. You need an order that keeps you honest:

1. Read once, with no highlighter in reach.

2. Note five words per section.

3. Close the source and write the main claim from memory.

4. Add the two or three supporting points, then cut examples.

5. Reopen the source and correct only what is wrong.

Do this on ten articles and the process disappears into habit. Do it on one and you will already notice how many things you thought you understood.

Should you summarize everything you read? No. Most of what we save does not deserve a summary, and the honest answer for a third of any reading pile is to delete it. Summarize what you will use, quote, or argue with. Skim and release the rest.

A summary is a small act of respect for a text and for a future reader. It is not a chore to be cleared by Friday. Ask what the piece said, say it plainly, and let the original go.

That is the whole practice. It is less a technique than a habit of saying what you know and noticing when you cannot.