We Transcribed Two Million Words. Most Jobs Produced Under a Hundred.

Every figure below is measured on VidClean's own traffic. Quote any of them with attribution.

• 2,269,873 words across 1,397 jobs, July 20 to August 19, 2026.
• 37.2% of jobs produce under 100 words (520 of 1,397). Transcription, for most people who use it, is a clip-checking activity.
• 21.9% of jobs produce over 2,500 words (306 jobs), and those are where nearly all of the two million actually came from.
• The mean job is 1,625 words. The median job is in the 100 to 500 band. When a mean sits four to sixteen times above the median band, the mean is describing the tail, not the typical job.
• English is down to 59.8% of jobs (835 of 1,397), from 71% in late July. The corpus now spans 48 detected languages, 13 of which appear exactly once.
• 22.2% of jobs are over 30 minutes long (310 jobs), but there is no second peak there. That is a bucket-width artifact, and there is a section below about why.
• 82.3% of jobs are served by Parakeet rather than Whisper.

One window, one sample: all figures cover July 20 to August 19, 2026, n=1,397 completed transcription jobs. Every dimension sums to 1,397 exactly. Language is detected by the system, never declared by the user. See methodology.

The word-count distribution is the most useful thing in this dataset, and it is lopsided in a way that the phrase "two million words" actively hides.

37.2%

of transcription jobs produce fewer than 100 words

520 of 1,397 jobs, July 20 to August 19, 2026

A hundred words is about forty seconds of ordinary speech. Whatever people are doing with a transcription tool a third of the time, it is not transcribing a podcast. It reads like checking: pulling the text out of a clip to see what was said, grabbing a quote, confirming a name, captioning something short.

Words out	Jobs	Share
under 100	520	37.2%
100 to 500	283	20.3%
500 to 1,000	97	6.9%
1,000 to 2,500	191	13.7%
2,500 to 5,000	156	11.2%
over 5,000	150	10.7%

n=1,397. Shares sum to 100% by construction; each job increments exactly one bucket.

Read the two ends together. 57.5% of jobs come in under 500 words. At the other end, 306 jobs cleared 2,500 words and 150 of those cleared 5,000. Those 306 jobs, 21.9% of the total, are carrying most of the two million.

The mean makes this concrete: 1,625 words per job, against a median that sits in the 100 to 500 band. A mean that far above the median band is a warning label, not a summary. If you are sizing a transcription product on "average job length," you are sizing it for a job almost nobody runs.

Before anything else: the language recorded here is the one the system detected from the audio, not one the user declared. Nobody picks a language in the interface. The first window of audio goes through automatic detection and whatever comes back is what gets counted. Detection errors are therefore counted as facts, and they will be more common on short, noisy or code-switched clips, which the previous section established are a third of the corpus.

With that said, English is 835 of 1,397 jobs, or 59.8%. In the pull taken in late July it was 71%. It has been falling steadily as the tool has picked up traffic outside the English-speaking web.

Language	Jobs	Share
English	835	59.8%
Spanish	129	9.2%
Portuguese	59	4.2%
Chinese	46	3.3%
Russian	33	2.4%
Indonesian	27	1.9%
French	23	1.6%
Hindi	22	1.6%
Lithuanian	22	1.6%
Arabic	21	1.5%
Tagalog	19	1.4%
Japanese	15	1.1%

n=1,397. The remaining 36 languages account for 180 jobs between them. All 48 are in the CSV.

Two things stand out. The first is Lithuanian at 22 jobs, ahead of Arabic, ahead of Japanese, ahead of German. Lithuania has under three million people. A tool with no marketing in a language can still land in it, and small-language traffic does not scale with population.

The second is the shape of the tail. Beyond the top ten, 180 jobs are spread across 38 languages, and 13 of those languages appear exactly once in the entire corpus. Afrikaans once. Albanian once. Bosnian once. Each of those is a single person who needed something transcribed and found a free tool that happened to handle it.

Non-English is now 40.2% of jobs. Whatever a transcription tool is built for, in practice a large minority of the work is not in the language it was built in.

Here is the duration distribution, and here is a mistake I nearly published.

Input length	Jobs	Share	Bucket width	Jobs per minute
under 1 min	434	31.1%	1 min	434.00
1 to 5 min	335	24.0%	4 min	83.75
5 to 15 min	200	14.3%	10 min	20.00
15 to 30 min	118	8.4%	15 min	7.87
30 to 60 min	196	14.0%	30 min	6.53
over 60 min	114	8.2%	open	n/a

n=1,397. Bucket widths are set by the counter code, not chosen for this analysis, and they are unequal.

Look at the Jobs column alone and there is an obvious story: counts fall from 434 down to 118, then jump back up to 196 at 30 to 60 minutes. A second peak. Two populations, clip-checkers and podcasters, showing up as two humps in one distribution. It is a good finding, it matches what the word counts imply, and I had already written it up.

It is not there. The 30 to 60 minute bucket holds more jobs than the 15 to 30 bucket because it is twice as wide. Divide by width and the density goes 7.87 jobs per minute in the 15 to 30 band, then 6.53 in the 30 to 60 band. It keeps falling. Every bucket in this table is less dense than the one before it, all the way down. There is one mode, at zero, and a long tail.

This is the oldest trap in histogram reading and it survives right up to the point where somebody divides by the bin width. It is worth stating plainly because unequal bins are the norm in this kind of instrumentation, not the exception: these buckets are 1, 4, 10, 15 and 30 minutes wide, and any comparison of raw counts across them is meaningless.

The two-population idea is still probably true. The word-count distribution supports it, 37.2% under 100 words against 21.9% over 2,500 is a real split in what people are doing, and 310 jobs over half an hour is a substantial group in absolute terms. But the duration histogram is not evidence for it, and I am not going to publish a chart artifact as a finding.

The counters record a words-per-minute distribution. It is not in this post, it is not in the CSV, and the script that regenerates this article's figures asserts that it never appears in either.

The reason is that it does not measure what its name says. The counter computes words divided by the full duration of the media file, silence included. An earlier study in this series found that roughly a quarter of a typical recording is dead air, and the spread on that is enormous: some recordings are almost continuous speech, others are mostly pauses. So a "words per minute" figure computed this way is speaking rate multiplied by an unknown, highly variable speech-density factor.

Two speakers talking at identical speed will land in different buckets if one of them leaves longer gaps. A recording with a long silent intro will read as slow speech. Nothing in the counters can separate the two, because the silence measurement lives on a different tool, in a different hash, with no job identifier joining them.

Published as "words per minute," it would have been the most quotable number in the post and the only wrong one. A metric you cannot interpret is worse than a metric you do not have, so it stays out.

VidClean deletes uploaded files within an hour of processing and keeps no per-file records, so this analysis is built on aggregate counters. When a transcription job completes, the backend increments a handful of running totals: one coarse duration bucket, one output word-count bucket, the detected language, the engine that served it, and the word count added to a running sum. No filenames, no user identifiers, no timestamps and no per-job rows exist anywhere. No individual transcription can be reconstructed, and the analysis is limited to exactly the cuts shown above.

One window, one sample. Everything covers July 20 to August 19, 2026, and totals 1,397 jobs. Each of the four families, language, word count, duration and engine, sums to 1,397 exactly, which is the check that catches a partially instrumented dimension before it becomes a wrong percentage.

The counters are independent increments, so no dimension can be crossed with any other. I cannot tell you whether the 48th language ran long files or short ones, whether English jobs are wordier than Spanish ones, or which languages sit in the sub-100-word group. Those joins do not exist in the data by design, and every statement in this post is confined to a single dimension at a time.

Language is detected by the system from the audio itself. There is no language selector in the interface, so no user ever declares one. Detection runs on the first window of audio and the result is reused for the rest of the file. A misdetection is recorded as a fact, and short or noisy clips are the most likely to be misdetected, which is a real limit on the long tail specifically: a language seen once may be a genuine single user or a detection error.

The word count is the number of whitespace-separated tokens in the output text. For languages written without spaces between words, Chinese and Japanese in particular, that is not a word count at all and will read low relative to how the same content would be counted in English. Those two languages are 61 jobs, 4.4% of the sample, so their effect on the 2,269,873 total is small but not zero, and it is downward.

Only plain transcription jobs are counted. Transcriptions that run as a stage inside another tool, generating burned-in subtitles or feeding the clip generator, complete on a different code path and never reach this counter. Style-profile reference extractions are deliberately excluded too, so the corpus is transcriptions people asked for as transcriptions.

Two engines serve these jobs. Parakeet handles 82.3% and faster-whisper the remaining 17.7%, routed by detected language. That split does not affect any usage figure above, but it matters for anyone reading the word counts as a quality signal, since the two engines are different models with different error profiles. A companion post measures what those two engines cost to run on the same hardware.

Numbers in this post were pulled fresh at publication time rather than reused from earlier notes, using the same script that regenerates the CSV and then greps this page for every figure it publishes. The full counter dump is available as a CSV file, with the window and sample size on every row.

This data is licensed CC BY 4.0. Feel free to reuse the numbers with credit to VidClean.

This is VidClean's user base, not a random sample of anyone's audio. People who reach a free browser transcription tool with no account skew toward short one-off tasks and away from anyone with a paid workflow already in place. A newsroom transcribing interviews all day never appears here. I make no claim that these proportions describe transcription in general.

Free-tier length limits shape the duration distribution directly. The "over 60 minutes" bucket is bounded by the cap that applied during the window, so the tail is truncated by policy rather than by user behaviour, and its 8.2% should be read as "jobs at or near the ceiling" rather than as the real distribution of long recordings.

The language tail is thin enough to be fragile. Thirteen languages appear once. At n=1, the difference between a real user and a detection error is invisible, and a single additional job moves a language's share by 0.07 percentage points. Treat anything outside the top ten as directional.

The English share is falling but the window is one month. 71% to 59.8% is a large move, and part of it is genuine growth in non-English traffic that other measurements support, but a single month of a growing sample can move a percentage a long way for uninteresting reasons. The direction is trustworthy; the slope is not yet.

And the counters keep running. Two million was a milestone, not a conclusion. When these distributions say something new, we will write it down.

If the data suggests anything practical, it is that your job is probably a short one, and short jobs are the case most transcription pricing is worst at. You can transcribe a video or audio file here, free in the browser, with no account needed. Language detection is automatic, so there is nothing to pick, and it handled 48 of them in the month covered by this post.

VidClean is a solo project. Questions about the data or the methodology are welcome at hello@vidclean.net.