Subtitle Converter

What this converter converts

A subtitle converter normally takes a subtitle file and rewrites it in another subtitle format. This one starts one step earlier: it takes the recording and gives you a subtitle file that did not exist yet. Drop an audio or video file, the speech is transcribed inside this tab, and the same pass produces three things you can switch between with the buttons above.

SRT is a numbered list of cues, each with a start time, an end time and the words, and a comma before the milliseconds. VTT is the same list with a WEBVTT line on top, a dot before the milliseconds and no numbers. TXT is one line per cue with the start time in square brackets, which is what you want when the next stop is a document rather than a player.

Everything below was measured by putting files through this page, not copied from a specification. That matters here more than usual, because the thing people search for when they type "subtitle converter" is usually a file that is already broken in a way no conversion will fix — and the only way to say that usefully is with numbers from a real file.

The seven pages this phrase returns, and the one thing none of them shows

The results page for this phrase is not about transcription at all. Read one by one on 2026-10-20, the seven tool pages that came back — GoTranscript, EditingTools, SubtitleKit, Maestra, Ebby, HappyScribe and OTTEngine, in the order they appeared — are all converters of the other kind: you hand them a subtitle file and they hand it back in a different wrapper. One of them, SubtitleKit, also accepts audio and video in its file picker — but for pulling an embedded subtitle track out of a video, or for a transcription tool it links to, not as a format to convert to or from.

That is a fair thing to build. What none of the seven does is show you the file at the other end of the chain — the one a machine made, which is what most people are holding when a player rejects their subtitles and they go looking for a converter. Specifically: not one of the seven reports how long a cue stays on screen, or how many characters a line holds. One of them — EditingTools — comes closest, with a checkbox labelled for lines of 42 characters or less and preset guideline checks named after broadcasters; it never shows what its check flags on a real file, so you cannot tell what it would say about yours.

The rest is thinner than the format lists suggest. Maestra is the one that says outright what a conversion does to the timing, and it says it correctly: the timing and the line breaks carry over as they are. OTTEngine is the one that warns about overlapping cues and offers a time offset. SubtitleKit and Maestra both build subtitles from audio as well, but on separate tool pages, not in the converter. And the conclusion none of them draws is the one that matters when a file will not behave: because the words and the timing pass through a conversion unchanged, a converter cannot repair a wrong word and cannot repair a cue that is too long to read.

So the section below is the one that is missing from all seven. It is a real file, produced here, measured line by line.

What an 87-second recording turns into

The file is 87.36 seconds of continuous narration, dropped in as MP3 and transcribed on whisper-base on 2026-10-20. The export was taken as SRT and then as VTT from the same run, and every number below comes from those two files.

• 24 cues covering 87.360 seconds — about one every 3.6 seconds.
• Cue length: 1.879 s at the shortest, 5.982 s at the longest, median 3.432 s.
• Characters per cue: 28 at the shortest, 88 at the longest, median 51.
• 16 of the 24 cues are longer than 42 characters, and one is longer than 84.
• 0 of the 24 cues contain a line break. A cue is one line of text, however long it gets.
• 23 boundaries between cues, all of them a gap of exactly 0.000 s. The cues are laid end to end.

That is not a quirk of this one page. The author of a Go subtitle toolkit wrote the cause down in the project's own issue tracker: speech-to-text tools “write long segments, often one per breath, and a subtitle needs short cues that fit 2 lines.” The six numbers above are what that looks like in a file.

Those six numbers are the whole argument of this page. A cue of 88 characters on a single line is not wrong in any format — it is a legal SRT cue and a legal VTT cue — but it is not a subtitle anybody wrote by hand, and a conversion will not change it. The 42-character figure is not this site's invention either: it is the number that appears in the line-length option on one of the seven pages above.

One more measurement, because it explains why the cue lengths look so even. Across the 24 cues the reading rate came out between 14.29 and 14.91 characters per second — a band barely half a character wide over a minute and a half of speech. That is not a coincidence about the speaker. The time inside a stretch of speech is divided among its sentences in proportion to how many characters each one has, so the rate is nearly constant by construction, and what varies from cue to cue is how much text a cue has to carry.

Where the cue times actually land

Every cue above carries a start time, and the question worth asking is whether that time is where the words are. It is not a yes-or-no answer, so it was measured. Five sentences were cut out of one 30-second narration at its pauses, so each slice begins exactly where speech begins, and the slices were then laid end to end with a known silence between them. That makes the true start of every sentence known to the millisecond without asking this page for it. Four assemblies went through the page once each on whisper-base on 2026-10-22, and every cue's start was compared with the moment its sentence begins.

• 18.26 s, five sentences, 1.000 s between them: the furthest cue start was 0.641 s after its sentence had begun.
• 15.26 s, the same five sentences, 0.250 s between them: 0.164 s.
• 10.54 s, three sentences: 0.306 s before. This one is under the fifteen-second limit, so it went in as a single piece and the time inside it was divided by text length alone.
• 23.26 s, the same five sentences with one 6.000 s silence in the middle: the cue before the silence started 1.594 s after its sentence, and the later cues started between 1.023 s and 1.668 s before theirs.

Three things follow from those four files.

• Wider pauses made the timing worse, not better. The file with 1.000 s between sentences drifted almost four times as far as the one with 0.250 s, and the file with the most silence in it drifted furthest of all.
• There is no single offset to apply afterwards. In the 23.26 s file one cue was late by 1.594 s while the cues around it were early by more than a second. Moving every timestamp by one constant would bring some cues towards their words and push others further away.
• A boundary can land inside a sentence. That file's cut fell at 14.980 s, mid-sentence, and the export says “first one” twice — once ending one cue, once starting the next. In the other three exports no word appeared twice.

Every seam in all four exports was a gap of exactly 0.000 s: each cue starts at the exact millisecond the previous one ended. That is the same fact as the reading-rate paragraph above, seen from the other side. The silence between two sentences does not sit between two cues; it sits inside one of them, and where the boundary falls inside that stretch is decided by how many characters each line carries.

What to do with that: check the first cue, and check the first cue after the longest silence in the recording. If a stretch of silence is longer than a sentence — a demo, a music sting, a gap while somebody finds a file — the cues around it will be early or late by a second or more, and cutting the recording at that silence and running the parts separately keeps it out of the timing. Otherwise treat the export as a first pass. The words are right, the times are close, and a player that lets you nudge a cue by hand will finish the job faster than another run will.

Scope: one narration, one model, one machine, one run per assembly, measured on 2026-10-22. Those four numbers describe these four files; they are not a promise about every recording, and a different speaker, a noisier room or a longer file will move them.

What a conversion changes, and what it cannot

The same run, exported twice. The SRT came out at 2106 bytes and the VTT at 2051, and the difference is exactly three things:

1. A WEBVTT line and a blank line at the top of the VTT, which the SRT does not have.
2. The separator inside each timestamp: a comma in the SRT (00:00:01,947), a full stop in the VTT (00:00:01.947).
3. No number in front of each cue. The SRT counts 1 to 24; the VTT has no counters at all.

That is the entire conversion. All 24 cues came through with the same start times, the same end times and byte-identical text. Neither file began with a byte-order mark, neither ended with a trailing newline, and both used plain line feeds. If your player accepts one and refuses the other, the cause is one of those three edits or the file's encoding — not the words, and not the timing.

This is also the answer to a question the seven pages handle badly. A conversion is a wrapper change, so it cannot repair anything inside the wrapper: a misheard name stays misheard, an 88-character line stays 88 characters, and a cue that starts a millisecond after the last one still does. The only way to fix those is to go back to the recording and run it again, or to edit the cues by hand afterwards.

Three implementations, three files, one result

The three edits above are simple enough that any tool can make them, which raises a question worth measuring: do different tools produce the same file? The same SRT was converted to VTT by two independent libraries and by this page, and the bytes were compared.

• pysubs2: 2116 bytes. It keeps each SRT cue number and writes it into the VTT as a cue identifier, and it ends the file with a blank line.
• webvtt-py: 2052 bytes. No cue identifiers, and a single trailing newline.
• This page: 2051 bytes. No cue identifiers, no trailing newline.

Three different files from one source, spread across 65 bytes, and all three are valid WebVTT. Read back through the same parser, each one returned the identical 24 cues, the same words, the same times. So when a converted file behaves differently in two places, the format is rarely the explanation — the differences above are. That is worth knowing before you spend an afternoon re-converting a file that was already correct.

SRT to text, without a tool

Getting plain text out of a subtitle file is the smallest conversion of all: every cue is three things — a number, a timestamp line, and the words — and the words are the only part you want. Measured on this export, the 24 cues held 248 words, and removing the number lines and the timestamp lines reproduced the plain-text export exactly, line for line, with the times taken off.

So you do not need a converter for it. In any editor that supports regular expressions, drop the lines that contain only digits and the lines that contain -->, then remove the blank lines left behind. The TXT button above does the same thing from the recording, and keeps the start time in square brackets at the front of each line — which is the version to keep if you might need to find a moment in the audio again.

What to check before you convert

If you already have a subtitle file and a player is refusing it, the four things worth looking at are these, in this order. They are cheap to check and they account for most of what goes wrong.

1. The first line. A VTT must begin with WEBVTT. A file that starts with a cue, or with a byte-order mark before the word, is an SRT wearing a .vtt extension.
2. The separator. Commas mean SRT, dots mean VTT. A file with dots and a missing header is the single most common half-conversion.
3. The line length. Look at the longest line. In this page's own export 16 of 24 cues ran past 42 characters, and no cue was broken into two lines at all.
4. The gaps. If every cue starts where the last one ended, nothing on screen marks a new line. A gap of a tenth of a second is enough to make the change visible.

None of those four is a format problem, which is the point. They are all things a converter copies through faithfully.

Supported input formats

MP3, WAV, M4A, OGG, AAC and FLAC, plus the common video containers when the recording came with pictures. That list describes what browsers already decode rather than a filter applied here. A phone recording is usually M4A, a podcast export is usually MP3, a screen recording is usually MP4 — all three go in without conversion, and the audio is taken out of the video before transcription starts.

A subtitle file dropped into this box is not a recording. It fails at the decode step with a message in words, which is the honest outcome: this page has no subtitle-file input, and the answer block at the top says so before you spend a minute finding out.

Accuracy

No percentage is printed here. Word error rate moves with the microphone, the room, the music and how fast people talk, and a single headline number would describe none of those. What can be said precisely: the models are the official Whisper checkpoints converted to ONNX by the Xenova project — tiny, base and small — and a larger one generally writes more of the line, at the cost of memory and time.

For subtitles specifically, the things worth checking by eye are names, numbers and the first cue. Names and numbers are where a speech model substitutes something plausible, and the first cue is where an intro or a music bed lands. Everything else about a cue — its length, its gaps, whether it is broken into lines — is a property of the export, and the numbers above tell you what to expect.

Privacy

The recording stays on this device. There is no account, no upload step and nothing to delete afterwards — closing the tab ends it. The visit itself is counted twice, by Cloudflare Web Analytics, which sets no cookies, and by Google Analytics, which keeps _ga and _ga_KJ155PR9B7 in this browser for two years. The privacy policy lists what each records.

Other kinds of recordings

A single audio file with no video around it is the shortest route on MP3 to text, which also covers the container-versus-codec problem that makes some .m4a files fail to open at all. A phone memo has its own page at voice memo to text, where the recording level is the thing that decides the result. For an episode with an intro bed, podcast transcription shows what the music does to the first cue, and for a short vertical clip, the Instagram Reel transcript page covers captions that exist only as pixels. The YouTube transcript generator runs the same engine over video files and explains why it takes a file rather than a link.

FAQ