What are the VLC subtitle delay shortcuts?

H moves the subtitles later, G moves them earlier, in steps of 50 milliseconds, and VLC prints the running total on screen as “Subtitle delay 250 ms”. The same value lives in Tools then Track Synchronization, under Subtitle track synchronisation, where it is shown in seconds and can be typed straight in. If the keys do nothing on your build, check Preferences then Hotkeys for “subtitle delay up” and “subtitle delay down” — the menu path is the same on every version and every platform.

Why is nudging more accurate than scrubbing to the timestamp?

Because it asks your ears an easier question. Scrubbing makes you read a clock at the instant a sound happens, which means hitting a moving target by hand and trusting your reaction time. Nudging makes you judge whether two things happen at the same moment, which people are good at to within a tenth of a second — it is the same sense that makes bad lip sync unwatchable. You stop when it looks right, and the player has already done the arithmetic.

Is VLC's subtitle delay in milliseconds or seconds?

Both, in different places, and mixing them up is a factor of a thousand. The on-screen readout after pressing G or H is in milliseconds: 2500 ms. The Track Synchronization dialog is in seconds: 2.500 s. Anything you type into a subtitle editor is almost always seconds, so divide the on-screen number by 1000 before you use it. 250 ms is 0.25 seconds, not 250.

Does the delay VLC saves fix the file?

No. It is a playback setting for that session on that machine: close VLC and it is gone, and your TV, your phone and anyone you send the file to still get the broken timings. Use VLC as the measuring instrument and then write the number into the subtitle file itself. That takes about thirty seconds and holds everywhere, forever, for everybody.

The delay I need is different at the start and the end. What does that mean?

That your subtitles drift rather than sit at a constant offset, which is a different repair. Measure the delay at a line near the start and again at a line near the end. If the two readings agree to within about a tenth of a second, it is a constant delay and one shift fixes the file. If the late one is bigger, the error is growing and you need a linear retime with two anchor points, using each measured delay to work out when its line should actually appear.

Guides2026-09-05

How to measure subtitle delay in VLC

Every guide to fixing subtitles, this site's included, starts with the same instruction: measure how far off they are. Then it moves on, as if measuring were the easy part. It is not — a sloppy measurement is the single most common reason a fix does not work. Here is the accurate way to get the number, and what to do with it once you have it.

Stop scrubbing for the timestamp

The obvious method is to find a line with a hard edge, scrub the video to the moment the sound happens, read the player’s clock, and subtract that from the timestamp in the subtitle file. It works, and it is what the constant-delay guide describes. But it asks you to do the one thing people are bad at: read a clock at an exact instant. You overshoot the slam, drag back, overshoot again, and settle for “about two and a half”. Half a second of slop is enough to leave the file visibly wrong after you have fixed it.

There is a better instrument, and it is already installed. Instead of measuring an absolute time, change the delay while the film plays until the subtitles land on the dialogue, and let the player tell you what you changed it by. You are no longer reading a clock; you are judging whether two things happen together, which is the sense that makes badly dubbed film unwatchable from across a room. It is good to about a tenth of a second, which is five times better than you will manage by scrubbing.

The trick is inverting the question. “What time is it when the door slams?” is hard. “Did the subtitle and the slam happen together?” is easy, and the player is keeping score.

Getting the number out of VLC

Play the film, let it run through a stretch of dialogue you can follow, and adjust:

Press H to move the subtitles later, or G to move them earlier. Each press is 50 milliseconds, and VLC prints the running total across the top of the picture: Subtitle delay 250 ms.
Keep going until the lines land on the speech. Do not stop at “better”. Go one or two presses past the point where it looks right, notice that it got worse, and come back. The last correct value is your reading.
For anything over a second, type it instead. Twenty presses to get to a second is a waste of a minute. Open Tools → Track Synchronization, put a rough value in Subtitle track synchronisation, and use G and H to refine from there.
Write the reading down with its sign. Positive means the subtitles needed to be pushed later, which means the file is running early. Negative means the file is late.

The menu path is the reliable one: it is in the same place on every version, on Windows, macOS and Linux. If G and H do nothing on your build, look under Preferences → Hotkeys for “subtitle delay up” and “subtitle delay down”. Other players work the same way with different keys, and the sign convention is near-universal: a positive delay means the subtitles appear later.

Milliseconds on screen, seconds in the dialog. VLC’s overlay says 2500 ms and its Track Synchronization box says 2.500 s for the same delay. Subtitle editors take seconds. Divide the on-screen number by 1000 before you type it anywhere, or you will shift the file by forty minutes.

Measure twice: start and end

One reading tells you how far off the subtitles are at one moment. It does not tell you whether that number holds for the whole film, and that is the question that decides which repair you need. So take a second reading: jump to a line near the end and nudge again from scratch.

The two readings agree, to within a tenth of a second or so — the file has a constant delay. One shift fixes everything.
The late reading is bigger — the error is growing as the film plays. That is drift, and no single shift can fix it.
They agree, then a third reading in the middle does not — the timing jumps at one point rather than sliding. Your copy is a different cut, and each side of the break is fixed separately.

Turning the readings into a fix

A delay measured in VLC transfers into a subtitle editor unchanged, same sign, once you have converted milliseconds to seconds. Positive is later in both. So if the two readings agreed at +2500 ms, the fix is a constant shift of +2.5 seconds and you are done.

If they did not agree, you need two anchor points: a cue near the start and a cue near the end, each with the time it should appear. That is where the readings earn their keep, because the arithmetic is one addition:

true time = the time in the subtitle file + the delay you measured there

A worked example. Open the subtitle file in a text editor and read the two timestamps off it. Say the early line is at 00:01:40.000 and needed +300 ms, and the late line is at 01:40:00.000 and needed +6200 ms. Convert and add: the early line should appear at 00:01:40.300, the late one at 01:40:06.200. Those two pairs are exactly what a two-anchor retime asks for, and every cue in between is placed proportionally.

The two readings also identify the cause, which is worth ten seconds of arithmetic. The drift here is 6.2 − 0.3 = 5.9 seconds, accumulated over the 5900 seconds between the two lines: 0.1 percent, or 0.6 seconds per 10 minutes. That is the signature of the 23.976 against 24 frames-per-second pair, and if you recognise it you can skip the anchors entirely and apply the framerate preset in one click. A drift closer to 25 seconds per 10 minutes is the 4 percent PAL family instead — and one that large is also the case where nudging is the wrong instrument, because you would be measuring minutes of offset 50 milliseconds at a time.

Then throw the VLC setting away

Once you have the number, reset VLC’s delay to zero. It was a measuring instrument, not a repair: the value lives in that session, dies when you close the player, and never reaches your TV, your phone, your media server, or anyone you hand the file to. Half the “I fixed it and it came back” reports are somebody who fixed the player instead of the file.

Writing the correction into the subtitle file takes about as long as one more nudge. The timings are then right in every player, permanently, for everybody — and if you got the sign backwards, you will know within one line and can flip it.