How to transcribe a WebM file to text, the format your browser picked for you
Transcribe WebM to text in the browser. What Opus audio, a missing duration and a screen recording with no audio track mean for the file you were handed.
To transcribe a WebM file to text, drop it on the home page. The browser decodes the audio track, mixes it to mono and writes out the words, and nothing is uploaded. You almost certainly did not choose WebM. A screen recorder, an in-tab meeting recorder or a browser voice recorder handed it to you, and when a web page records it is the browser that picks the format. That explains most of the odd things these files do, including the one that sends people looking for help: a screen recording with no audio in it at all.
WebM is what the browser hands you, not a format you picked
The WebM project describes it plainly: “WebM files consist of video streams compressed with the VP8 or VP9 video codecs and audio streams compressed with the Vorbis or Opus audio codecs”. MDN calls it “a format based on Matroska which is designed specifically for use in modern web environments”.
It keeps turning up in your downloads folder because of the recording interface browsers give web pages. MDN’s guide to the MediaStream Recording API describes a stream being captured into a blob “in the default encoding format of your browser”, and the MediaRecorder reference lists the container as something a developer may set, such as video/webm or video/mp4. When nobody sets it, MDN’s page for the mimeType property says the type is the one “chosen by the browser”. A WebM is not a statement about quality, just a by-product of where the recording happened.
Opus is usually the audio inside, and it suits speech
WebM carries Vorbis or Opus, and MDN says compliant implementations must support both. Opus is the one we find in the browser recordings we test with, which is good news for a transcript. RFC 6716, the Opus specification, says the codec “is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat”, and its linear prediction layer “is based on the SILK codec”, which came out of voice work. MDN’s codec guide calls Opus “a good general-purpose audio codec that can efficiently handle low-complexity audio such as speech”.
What makes it unusual is that it does not sit still. RFC 6716 describes an encoder that switches between its operating modes mid-stream “to adapt to varying content and network conditions”. MDN lists its profiles by effective sample rate, narrowband at 8 kHz up to fullband at 48 kHz, and calls them effective rates because “Opus uses an algorithm based on audio bandwidths rather than sample rates”.
So one WebM can hold audio of different quality from minute to minute, and a stretch recorded while a call was struggling comes out narrower than the rest. The words are still there, but the consonants are thinner, and thin consonants are where transcripts go wrong.
Sample rates from web recorders vary, and mostly that does not matter
Recorders built on browser APIs do not dictate the rate their audio arrives at. MDN describes a track’s sampleRate as the value that “was selected to comply with your specified constraints”. Selected, not demanded: the device, the operating system and the browser settle it between them, which is why the same web app produces different files on two machines.
For us it is a non-event. Everything is mixed to mono and resampled to 16 kHz before the model sees it, for the same reason an MP3’s bitrate matters less than people expect. What nothing fixes is audio that was already narrow when it was recorded, and the recording habits post covers that at source.
A browser recording may arrive with no duration at all
WebM inherits its structure from Matroska, and Matroska has a written-as-you-go mode. RFC 9559, the Matroska specification, makes the Duration element optional, and says a live stream “is different from a file because it usually has no known end”, with the Segment’s size left undeclared. Its performance advice follows from that: “Unless Matroska is used as a live stream, it SHOULD contain a Cues element”, the element “used to seek when playing back a file by providing a temporal index for some of the Tracks”. Without it, a reader “would have to ‘hunt and peck’ through the file to look for the correct timestamp”.
We could not find documentation of what any particular browser recorder writes when a recording ends, so take what follows as the symptom rather than the cause. The file arrives with no usable duration and no seek index: 0:00 in the player, a dead seek bar, scrubbing that lands in the wrong place. That is the usual state of a recording that stopped badly, after a crashed tab or a copy taken while the file was still being written. The audio is normally intact, because what is missing is the description of it rather than the packets.
That matters less here than in a video editor. The transcript comes from reading audio packets in order, so a file with no duration still transcribes and only the progress estimate misbehaves. If it has to work elsewhere, convert it once; the MP4 post covers that route.
A screen recording can arrive with no audio track at all
Capturing a screen and capturing its sound are two separate permissions, and the second one fails quietly. In MDN’s documentation for getDisplayMedia(), the call behind browser screen recording, asking for audio “indicates that the returned MediaStream will contain an audio track, if audio is supported and available for the display surface chosen by the user”, and “browser support for audio tracks varies”. Then the line that explains the empty file: “the returned stream might contain no audio track even when audio is true and systemAudio is include”.
So the recorder asked, something between the browser and the operating system said no, and the recording carried on: a flawless video of your screen with nothing to transcribe.
Check before you spend an hour on it. Play the file with headphones from a point where someone was talking, not from the first second. VideoLAN’s documentation describes selecting “the designated Track option in the Audio Track from the Audio menu”, with a Disable option alongside it. If Disable is all VLC lists there, the file has no audio. Our page says the same rather than grinding through a silent file.
Nothing recovers audio that was never recorded, so the job becomes finding another copy. If the session ran on Meet, where Meet puts the file is the place to start.
| What you see | Likely cause | What to do |
|---|---|---|
| Duration shows 0:00, seek bar dead | No duration and no cue index in the file | Transcribe it anyway; convert it if other tools choke |
| No sound in any player | The audio track is missing entirely | Check the Audio Track menu, then find another recording |
| Only your voice, none of the call | Microphone captured, tab or system audio was not | Nothing in the file to fix; use the platform’s recording |
| File keeps growing on disk | The recording has not been stopped | Stop it, then use the finished file |
| Muffled, telephone-sounding stretches | Encoder dropped to a narrow audio bandwidth there | Expect errors there; fix it at the next recording |
| Very large file, mostly picture | Video stream is most of the bytes | Drop it in as it is; only the audio track is read |
Transcribe WebM to text without uploading the file
Open the home page, drag the WebM onto it or use the file picker, and text appears after the first window rather than at the end. The first run downloads the speech model, about 200 MB, which the browser caches. Export TXT, SRT or VTT; which export you want is a short read.
The limits, plainly. It runs on desktop Chrome or Edge with a working WebGPU adapter, so Firefox, Safari and phones are out for now, and it is English only. No export carries speaker labels; what happens with two voices is honest about that gap. It uses the base size of OpenAI’s open-source Whisper model, so names, jargon, strong accents and noisy rooms are the weak spots. Read it through before relying on it.
Nothing leaves the tab: the file is decoded in a worker and discarded as it goes, and the wider case for keeping it that way shows how to verify that. If a WebM has been sitting in your downloads folder since last week’s meeting, drop it on the home page. For other formats, start from the audio to text hub.
Frequently asked questions
Why is my file a WebM when I never chose that format? Because a browser wrote it. MDN describes a recorded stream being captured in the browser’s default encoding format, and says the type is whatever the browser chose when the page did not specify one.
Does a WebM with no duration still transcribe? Yes. The duration and the seeking index are both optional in the format, and a file that stopped badly often has neither, but the audio packets stay readable in order.
How do I check whether a screen recording has audio? Play it with headphones from a point where someone was speaking, then open VLC’s Audio Track submenu, which lists the tracks the file contains. Our page also tells you when there is no audio track.
Is Opus worse than MP3 for a transcript? No reason to think so. Opus was designed for interactive voice applications, and either way the audio is reduced to 16 kHz mono before the model reads it.
Sources, checked 15 September 2026
- https://www.webmproject.org/about/ - WebM Project: VP8 or VP9 video, Vorbis or Opus audio
- https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Containers - MDN: WebM as a Matroska-based format
- https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Audio_codecs - MDN: Opus for speech and music, effective sample rates
- https://www.rfc-editor.org/rfc/rfc6716.html - RFC 6716, Opus: applications, the SILK layer, mode switching
- https://www.rfc-editor.org/rfc/rfc9559.html - RFC 9559, Matroska: optional Duration, the live stream with no known end, the Cues recommendation
- https://developer.mozilla.org/en-US/docs/Web/API/MediaRecorder - MDN: container MIME type as an option
- https://developer.mozilla.org/en-US/docs/Web/API/MediaRecorder/mimeType - MDN: the type is chosen by the browser when the page does not specify one
- https://developer.mozilla.org/en-US/docs/Web/API/MediaStream_Recording_API/Using_the_MediaStream_Recording_API - MDN: the browser’s default encoding format
- https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getDisplayMedia - MDN: a stream may carry no audio track
- https://developer.mozilla.org/en-US/docs/Web/API/MediaTrackSettings/sampleRate - MDN: the rate selected for a track
- https://wiki.videolan.org/Documentation:Audio/ - VideoLAN: the Audio Track submenu