VSL Script Word Count: Words Per Minute, by VSL Length

How many words per minute does a VSL narration run?

The working range is 130-150 WPM, with 135-150 WPM as the safer production band. That range fits plain English narration, not speed-reading. It also matches what voice-over guidance and speech-rate research keep bumping into: narration usually sits slower than casual conversation, and recording adds pauses you do not see on the page.

Voice-over guidance commonly puts narration around 120-150 WPM, while a PMC study on reading aloud reported 160 WPM for reading aloud and 176-180 WPM for talking about daily routines. That does not mean every VSL should copy those numbers. It means your pace depends on task, sentence shape, and how much information you pack into each minute. Voiceovers.com and PMC both point in the same direction: context changes the rate.

Speed is a tool.

Stop using one global WPM target for the whole VSL. The hook, body, proof stack, and close do not deserve the same pace. A single number makes the draft easy to count and easy to ruin. The better approach is to pace the piece by section, then total the words.

That matters because a VSL is not a podcast. You are selling, correcting, and restarting attention, often inside the same minute. The read speed changes with those jobs. If you keep the number constant, the pauses will change it for you anyway.

The practical spread inside the 130-150 band comes from sentence load. A line with a price, a year, and a claim reads slower than a clean line with one promise and one proof point. Numbers drag. So do URLs, acronyms, and parenthetical clauses that force the voice to re-balance mid-sentence. If your script has a lot of those, plan on the low end.

How many words is a 10, 20, or 30-minute VSL?

At 130-150 WPM, a 10-minute VSL is 1,300-1,500 words, a 20-minute VSL is 2,600-3,000 words, and a 30-minute VSL is 3,900-4,500 words. If you want the desk's working production band, use 135-150 WPM and treat the 20-minute target as 2,700-3,000 words. That is the cleanest planning number for most scripts.

If you insist on a strict 130 WPM floor, use the left column and call it a conservative estimate. If you are actually recording the script, the middle and right columns will usually be closer to reality because the read will slow around proof, tighten around hooks, and breathe around transitions. The table is the calculator. The voice is the reality check.

A quick rule helps here: every 10 minutes of runtime equals about 1,300-1,500 words at a hard read, but only if the script stays clean. Once you add proof bullets, pauses, and any line that needs a beat before the next claim, the effective count moves up. That is why pages that promise exact runtime from raw word count usually miss by a little. Often enough.

How does pacing change between hook and body?

The hook should move faster than the body. Plan the opener around 145-165 WPM, then let the body settle closer to 125-145 WPM. The listener needs a burst of momentum up front and breathing room once you start naming the problem, showing the mechanism, and stacking proof. If both sections sound identical, the script feels flat.

The hook earns speed because it has a different job. It has to interrupt, orient, and pull the viewer into the next sentence before the skip impulse lands. The body has to hold attention after the click, which means clarity matters more than tempo. Timing beats creative.

• Hook: keep sentences short, strip secondary clauses, and land the promise early.
• Problem frame: slow down when you name the buyer pain or the market friction.
• Proof stack: pause after claims, numbers, and case-study references so the listener can separate them.
• Close: speed can rise again, but only if the CTA stays simple.

That split is also how you avoid fake urgency. A hook can tolerate compression because it is usually saying one thing. A proof section cannot. The moment you stack three claims, two numbers, and a transition in one breath, the listener loses a beat of comprehension. That beat is expensive. It is the difference between a line that lands and a line that blurs.

Use the body as your pacing anchor. If the opener runs at 160 WPM and the proof section only survives at 128 WPM, do not flatten the opener to match the body. Keep the opener brisk. Then decide whether the body needs cutting, not just slowing. The script should follow the job, not the spreadsheet.

How do AI voices change effective words per minute?

AI voices do not change the math, but they change the variance. Some voices read tight and clean. Others stretch around commas, numbers, and abbreviations, which makes the same script feel slower even when the word count stays fixed. If your tool supports SSML, you can set speaking rate with prosody tags, but the output is still approximate. Google Cloud Text-to-Speech SSML documents speech customization, and Amazon Polly says the actual speed depends on the voice you choose.

That means you should test the actual voice, not the vendor demo voice. A script that lands at 2,800 words in one neural voice may feel like 3,000 words in another because of pause handling. Numbers, URLs, acronyms, and parenthetical asides are the usual drift points. They create tiny stalls that add up fast in a 15-minute or 20-minute read.

Google Cloud's SSML guide shows that you can add breaks and adjust prosody. Polly exposes preset speed controls and percentage-based speed changes, but it warns that the result stays approximate. That is the point. AI voices are predictable enough for planning, not precise enough to skip timing tests.

Measure the voice you will publish with.

One more practical issue: some voices sound faster at the same WPM because they articulate consonants more crisply. Others sound slower because they stretch vowels and leave cleaner sentence gaps. The page count does not tell you that. The waveform does. If you are choosing between two voices, record the same 200-word sample in both and compare the elapsed time before you commit to the full draft.

How long will your draft run once recorded?

Divide the word count by the actual voice's WPM, then add a buffer for pauses. A 2,850-word script at 142 WPM runs 20.1 minutes on paper. Add breaths, pauses after claims, and awkward numbers, and you are closer to 22 minutes. If the script is proof-heavy, call it 22.5 minutes and do not fight the math.

Use this manual method instead of guessing from the page count alone. Record 300 to 500 words in the intended voice, time the file, and calculate your real WPM from that sample. Do it once with a hook section and once with a proof section. The two rates are usually different, and that gap matters more than the average.

1. Write 300-500 words from the actual script.
2. Record them in the exact voice and style you will publish.
3. Count the finished words and divide by the elapsed minutes.
4. Use that number as your runtime baseline.

DIY monitoring works.

Example: you draft 3,120 words for a 20-minute VSL because the hook is punchy and the proof section is dense. In a 140 WPM test read, that script wants 22.3 minutes before you add breath space. If the close includes 8 short pauses and 3 emphasized numbers, the final file will probably sit around 23 minutes, not 20.5. That is the kind of drift that matters when your media buyer needs a cut by 5 p.m.

Do not measure against silence. Measure against the final voice. A text file has no pauses, no emphasis, and no reset points. Your recording does. That is why a script that looks under 20 minutes on the page can still export as a 21-minute or 22-minute asset. The page is a draft. The audio is the asset.

When should you cut words versus slow the read?

Cut words when the line can be shorter without losing proof. Slow the read when the line contains information the listener has to retain: prices, dates, steps, caveats, or a claim that needs one beat of mental processing. If the copy is dense, cutting usually wins first because it improves clarity and shortens runtime at the same time.

Use speed only after the script is structurally clean. A 10% slowdown on a 20-minute VSL adds 2 minutes. Cutting 200 filler words often saves close to the same amount, and it does not ask the listener to work harder. That is why the fastest way to fix a long script is often subtraction, not a new voice setting.

• Cut repeated claims, duplicated transitions, filler adjectives, and any sentence that restates the previous one.
• Slow around pricing, compliance language, numbers, URLs, and any step where the viewer must remember sequence.
• Keep the CTA short. The close should feel simpler than the body, not heavier.

Think in thresholds. If the draft is 8% over target, trim first. If it is 20% over target, rewrite the dead weight before you touch pacing. A slower read can rescue a clean script. It cannot rescue a bloated one. The script has to earn its minutes.

Amazon Polly notes that speed controls are approximate, so you still need a real test read. The platform can help you tune pacing. It cannot rescue a bloated script.

Frequently asked questions

What is the safest planning speed for a sales VSL?

Use 140 WPM. It sits in the middle of the 130-150 band and gives you room to speed up the hook or slow a proof block without reworking the whole draft. If the voice runs fast, trim later. If it runs slow, you still stay close.

Do pauses count in the script total?

They count in runtime, not in word count. A 2,800-word script can still run long if you leave space around claims, prices, and transitions. Count the words first, then add a buffer after the first recorded read. That buffer is where most timing misses live.

Should AI voices change my word target?

Use the same target, then test the voice. AI voices change how the script feels, not the arithmetic of words per minute. Some voices run tighter, others stretch around punctuation, but the right move is to measure the exact voice you will publish with.

How do I size a 20-minute VSL?

Start at 2,700-3,000 words. That range assumes a real narration pace, not a silent reading pace, and it leaves room for the pauses that appear once proof, numbers, and transitions hit audio. If the draft is dense, stay near 2,700 and tighten from there.

What if my draft runs long?

Trim before you speed up. Remove repeated claims, filler transitions, and any sentence that restates the last one. If the line carries pricing, compliance, or a sequence step, keep the line and slow the delivery instead. Cutting dead words usually fixes the runtime faster.