Turn TTML subtitle files into LRC lyrics format in a few clicks—upload your TTML, convert to LRC, and download the new file.
.ttml, .xml, or .dfxp file, or click "Add Files" to browse. Parsing runs entirely in your browser session — the XML never leaves your device. Batch is supported, so you can drop an album's worth of lyric files at once.<p> element's begin attribute, normalizes it from clock-time (00:01:23.456) or tick form (12345t) to LRC's [mm:ss.xx] two-decimal stamp, and emits one timestamped line per cue. <head> metadata that maps to LRC tags (title, creator, language) is rewritten as [ti:], [ar:], and [au:] headers; styling, regions, and tts:* attributes are dropped because LRC has no equivalent syntax.<br/> separators and <span> styling inside a cue. The converter flattens each <p> to a single text line (TTML's preferred unit), preserving plain text and stripping inline markup. If your TTML has overlapping cues (common in dual-speaker dialogue), the converter keeps them in document order — LRC has no concept of layered tracks..lrc file downloads instantly, UTF-8 encoded, ready to drop next to the matching audio file. No upload, no sign-up, no watermark.TTML (Timed Text Markup Language) is the W3C XML standard finalised in November 2010 (TTML1) and revised November 2018 (TTML2), and it's what professional video pipelines use — Netflix requires TTML1 for all partner subtitle deliveries (Japanese deliveries must use IMSC 1.1, a TTML subset). LRC, by contrast, is a plain-text format invented in the late 1990s for karaoke software and has stayed the universal sidecar format for synchronised song lyrics. Converting TTML to LRC is what you do when timed lyrics arrive in a broadcast container but need to live next to a local MP3 or FLAC in a music player.
.lrc files to overlay synced lyrics on your personal library — TTML isn't recognised by either.Track.lrc beside Track.flac and timed lyrics light up.[mm:ss.xx]Lyric line — Notepad++, VS Code, or any plain editor can re-time a chorus in seconds.| Property | TTML | LRC |
|---|---|---|
| Standardised by | W3C Recommendation (TTML1 2010, TTML2 2018) | De-facto standard from karaoke software (late 1990s) |
| Underlying syntax | XML with namespaces (xmlns="http://www.w3.org/ns/ttml") |
Plain text, line-based |
| Timestamp format | Clock time HH:MM:SS.mmm, frames 00:01:23:12, or ticks 12345t |
[mm:ss.xx] (hundredths of a second) |
| Cue boundaries | begin and end attributes per <p> |
Start time only — line shows until the next timestamp |
| Styling | Rich: fonts, colours, regions, CSS-like tts:* attributes |
None |
| Metadata | <head> block with <metadata>, <styling>, <layout> |
Tag headers: [ti:], [ar:], [al:], [au:], [by:], [length:], [offset:] |
| Per-word timing | Yes — nested <span begin="..."> inside <p> |
Enhanced LRC (A2) uses <mm:ss.xx> angle brackets inline |
| Multi-language | Yes — xml:lang per element |
Effectively no (one language per file) |
| Typical use | Netflix, Amazon Prime, BBC, broadcast, IMSC 1.1 | Music players, karaoke, lyric overlay apps |
| MIME type | application/ttml+xml |
application/x-lrc (informal) / text/plain |
| Typical file size (3-min track) | 8–15 KB | < 2 KB |
| TTML element | Behavior in LRC output |
|---|---|
<p begin="..."> text </p> |
Becomes [mm:ss.xx]text line |
Tick-time (12345t) and frame-time (00:00:01:12) |
Resolved against ttp:tickRate / ttp:frameRate and emitted as [mm:ss.xx] |
end attribute |
Dropped — LRC has no per-line end time |
<head> <metadata> <ttm:title> |
Becomes [ti:Title] |
<head> <metadata> <ttm:agent> (singer / performer) |
Becomes [ar:Artist] when present |
<head> <metadata> <ttm:copyright> |
Dropped (no LRC equivalent) |
<styling> and <layout> regions |
Dropped |
<span> inline styling (tts:color, tts:fontWeight) |
Stripped; inner text kept |
<br/> inside <p> |
Replaced with a space (LRC is one-line-per-cue) |
Multiple <div> blocks / <body> regions |
Flattened into a single chronological stream |
xml:lang per element |
Dropped — output is mono-lingual |
Per-word timing (<span begin="...">word</span>) |
Optionally emitted as Enhanced LRC <mm:ss.xx>word if the source has word-level spans |
| UTF-8 encoding | Preserved |
Three main sources. First, Apple Music ships its catalog lyrics as TTML internally (the @syncfm/ttml library was built specifically to parse the Apple Music flavour) and tools that scrape or export from Apple Music produce TTML. Second, music-video subtitle tracks from broadcasters are TTML because that's the W3C delivery format. Third, professional lyric-syncing services (Musixmatch's partner exports, in-house studio tools) can emit TTML. If you've got a .ttml or .xml file in front of you, it almost certainly came from one of those three pipelines — and almost none of the consumer music players that actually play your local files know what to do with it.
No. Spotify and Apple Music use closed, server-side lyric systems — both license from Musixmatch and neither accepts external .lrc files for catalog tracks. LRC is for local-library playback: third-party clients like LyricFever (macOS), Soor (iOS), foobar2000, MusicBee, AIMP, Poweramp, and most Chinese music players read a sidecar .lrc next to a local .mp3 or .flac and display synchronised lyrics. If you want lyrics on a Spotify Premium stream, this converter won't help — there's no integration point. If you want lyrics on your own ripped or purchased files, the LRC is exactly right.
Only if your source TTML has word-level spans. TTML allows nesting <span begin="00:00:01.250">word</span> inside a <p> — that's how Apple Music's karaoke-mode TTML encodes per-word timing. When those spans are present, the converter emits Enhanced LRC syntax with angle brackets: [00:01.20]<00:01.20>I <00:01.45>want <00:01.78>to. If your TTML only has paragraph-level begin attributes, the output is standard line-level LRC. Players that don't support Enhanced LRC simply ignore the inline <mm:ss.xx> tags and fall back to line-level timing — there's no compatibility penalty.
LRC has no end-time. Each line displays from its timestamp until the next timestamp arrives. If your TTML has a <p> with begin="00:00:10.000" end="00:00:13.500" followed by a 4-second pause and then the next line at 00:00:17.500, the LRC output shows that line from 0:10 to 0:17.50 — 7.5 seconds, not 3.5. To preserve gaps, the converter can optionally insert an empty [mm:ss.xx] line at the original end time, giving the player a "clear lyrics" cue. Most music players handle this correctly; karaoke apps with timed highlighting may prefer the gap markers.
Yes. TTML's ttp:tickRate (default 1, often set to 10000000 for hundred-nanosecond ticks) and ttp:frameRate (24, 25, 29.97, 30, 60) are read from the root <tt> element. The converter resolves any begin value expressed as 12345t ticks or 00:01:23:12 frames to absolute seconds before truncating to LRC's two-decimal precision. If the file is missing tick-rate metadata and uses ticks anyway, the W3C-default 1 is assumed and the converter flags a warning — usually it means the source file is malformed and needs the rate set explicitly.
DFXP (Distribution Format Exchange Profile) was the original 2010 name for what is now just called TTML1. The two are XML-compatible; the only practical difference is the file extension. Most DFXP files will parse here directly — rename to .ttml first if the file picker rejects the extension, or use DFXP to LRC which accepts the .dfxp extension natively. Netflix's IMSC 1.1 deliveries are also XML-compatible TTML and will convert, though you'll lose the IMSC-specific Japanese ruby annotations and positional formatting that LRC can't express.
Yes. TTML files are required by the W3C spec to be valid XML, which means a declared encoding (usually UTF-8 or UTF-16). The converter reads the declaration, decodes accordingly, and emits UTF-8 LRC. CJK characters, accented Latin characters, Cyrillic, Arabic, and combining diacritics all round-trip correctly. The output never includes a UTF-8 BOM because LRC parsers in older Windows players (legacy AIMP versions, foobar2000 pre-1.6) sometimes choke on the BOM byte; modern players don't care either way.
TTML supports multilingual cues via xml:lang on each <p> element (common in karaoke pop with English transliterations alongside the original Japanese, for example). LRC has no language attribute, so the converter picks the document's primary language (the xml:lang on the root <tt> element) and drops cues in other languages. If you need both languages, run the conversion twice with different language filters, or use TTML to TXT to extract the raw text first and assemble a bilingual LRC manually.
Yes — LRC to TTML is the reverse operation. The reverse loses some fidelity going LRC → TTML → music-player-app because TTML adds an XML wrapper that most local-library music players ignore, but it's the right path when you need to deliver lyrics to a broadcast or streaming partner that mandates TTML1. For other lyric-format destinations (SRT for video editors, VTT for HTML5 players, plain text), use TTML to SRT, TTML to VTT, or TTML to TXT instead.