LRC vs SRT vs WebVTT: Which Timed-Text Format Your Site Actually Needs
If you publish audio or video on your own site, sooner or later you want the words to follow along — captions on a tutorial, scrolling lyrics under a track, a transcript that highlights as it plays. All three come from the same underlying thing: a list of timestamps paired with text. What changes is the file format, and picking the wrong one means the player quietly ignores your file and shows nothing.
Here is what each format is actually for, and how to produce the timing without tapping a key on every line.
They are all the same data, serialized differently
Strip away the syntax and every timed-text format is a table: start time, end time, some words. WebVTT writes it one way, SRT another, LRC a third. Once you have accurate timings, converting between them is mechanical. Which is why the real work is never the format — it is getting the timestamps right in the first place.
That matters for how you plan the job. Generate the timing once, export it four ways, and you have covered your video player, your audio player, YouTube, and your editing timeline in a single pass.
WebVTT: the one browsers understand natively
WebVTT is the only format in this list that HTML5 knows about out of the box. You attach it with a track element inside your video or audio tag:
<video src=”lesson.mp4″>
<track kind=”captions” src=”lesson.vtt” srclang=”en” label=”English” default>
</video>
No plugin, no JavaScript library, no extra request beyond the file itself. The browser renders the cues, handles positioning, and exposes them to screen readers. If your goal is accessible captions on a page you control, this is the default answer and you should stop reading here.
Two practical notes. WebVTT files must begin with the literal line WEBVTT, and they must be served as text/vtt — a misconfigured MIME type is the single most common reason a perfectly valid caption file shows up as nothing at all. Cross-origin caption files also need CORS headers, which trips people up when the media sits on a CDN and the VTT does not.
SRT: the interchange format
SubRip is older, simpler, and understood by more software than anything else in this space. YouTube accepts it, Premiere and Resolve import it, most social platforms take it, and every subtitle tool on earth can read it.
Its limitations are real — no positioning, no styling, no metadata worth mentioning — but that is also why it survives. If you are handing a file to someone else, or uploading to a platform you do not control, SRT is the safe currency. Keep a WebVTT for your own site and an SRT for everywhere else; they are trivially convertible.
LRC: the music player format
LRC is the odd one out, and it is the one people reach for last even when it is the right answer. It is a plain-text lyrics format where each line is prefixed with a timestamp:
[ti:Song Title]
[ar:Artist Name]
[00:12.50]The first line of the chorus
[00:17.20]The second line arrives here
Music players — VLC, foobar2000, Rockbox, most mobile players — look for an .lrc file sitting next to the audio with the same base filename, and display scrolling lyrics with no import step at all. song.mp3 plus song.lrc in the same folder is the entire integration.
There is also an enhanced variant that adds a timestamp to every individual word:
[00:12.50]<00:12.50>The <00:12.78>first <00:13.10>line
That is what powers karaoke-style highlighting, where the colour sweeps across words as they are sung rather than jumping line to line. If anything on your page animates in time with the vocal, you need word-level timing, and standard LRC will not give it to you.
Getting the timestamps without doing it by hand
The traditional route is a desktop LRC editor: paste the text, hit play, tap a key at the start of each line. It works and it is free. It also takes fifteen to thirty minutes for a typical song once you account for the lines you mistime on the first pass — and it only ever produces line-level timing. Nobody taps out word-level timestamps by hand twice.
The alternative is forced alignment: hand a model the audio and the transcript, and let it work out when each word was spoken. This is well-established in speech research; applying it to music is harder because the vocal is buried under the instrumentation, but separating the vocal stem first makes it tractable.
Tools like Lacuna’s LRC generator chain those steps together. You upload the track — MP3, WAV, FLAC, M4A or OGG — and the model transcribes the vocals and assigns a start time to every word rather than every line. If you already have the words, pasting them in before generating is both faster and more accurate: the generator keeps your exact text and line breaks and only computes the timing, so it is not guessing at proper nouns or ad-libs. Output lands in an editor where you can play against the waveform, nudge a line by a tenth of a second, snap it to the playhead, or split and merge lines, then export standard LRC, word-by-word LRC, SRT, WebVTT or plain text from the same timing data. Language detection is automatic across English, Chinese, Japanese, Korean, Spanish, Portuguese, French, German, Italian and Russian, with a manual override for bilingual tracks where the guess is least reliable.
Choosing, in one line each
- Captions on your own pages — WebVTT, via a track element. Native, accessible, no dependencies.
- Uploading anywhere else — SRT. Universal, boring, always works.
- Audio files people download or play in a music app — LRC, same filename as the audio.
- Anything that animates per word — enhanced LRC. Nothing else carries word-level timing.
Three things that break timed text in production
Encoding. Save as UTF-8. Older editors default to a local codepage and every non-Latin character arrives as garbage. This is the number one support ticket for lyrics files and it is entirely avoidable.
Filename drift. For LRC the match is by filename, including case on case-sensitive filesystems. Song.mp3 and song.lrc will not pair up on a Linux host even though they did on your Mac.
Treating captions as decoration. Timed text is indexable and machine-readable in a way that burned-in text on a video frame never is. If you have gone to the trouble of producing accurate timings, ship them as a file rather than baking them into the pixels — and if you are turning a track into something visual, feed the timed file into your video editor instead of dragging text blocks around a timeline by hand.
The short version
Pick the format by where the file is going, not by which one you have heard of. WebVTT for your own pages, SRT for everyone else’s, LRC for music players, enhanced LRC when something needs to move per word. Generate the timing once — ideally by letting a model listen rather than tapping it out — and export whichever wrapper the destination expects.
