SpeechRecognition­Result Timestamps (WebSpeech API)

at a glance

why it exists

The Web Speech API has always been a “black box” about timing: a SpeechRecognitionResult tells you what was recognized, but nothing about when in the audio it was recognized. The explainer frames two concrete problems this creates:

• Timeline association — developers cannot map transcribed text back to specific segments of the audio source, which blocks automated subtitle cue alignment and media-editing workflows that need to know where in a recording each phrase sits.
• Latency tracking & backend failover — as recognition moves on-device (SODA and related backends) to improve privacy and cut server cost, processing speed depends on the user's hardware. When a constrained device falls behind real time, caption lag accumulates silently. With no timing signal, an application cannot detect the lag or fail over to a cloud ASR backend — the user just sees stale captions in a live call.

Two segment timestamps per result answer both: caption tools get cue bounds, and latency-sensitive apps can compare audioEndTime with the event's delivery time to compute how far behind the engine is running (see measuring latency).

how it works

1. The recognition engine (on-device SODA, or a remote service) processes audio and emits results tagged with timing information. In Chromium's speech pipeline the engine reports a TimingInformation struct per result: audio_start_time (“start time in audio time from the start of the SODA session” — the amount of audio input) and audio_end_time (“elapsed processed audio from first frame after preamble”).
2. Blink constructs each SpeechRecognitionResult with those optional bounds (speech_recognition.cc passes result->audio_start_time / audio_end_time into SpeechRecognitionResult::Create). This applies to interim (provisional) results as well as final ones — the aggregation path in speech_recognition.cc builds both from the same struct, so live-caption use cases get timestamps on interim hypotheses too.
3. When script reads audioStartTime/audioEndTime, Blink returns null if the engine supplied no value, otherwise the value floored to a 2 ms multiple (FuzzTimestamp in speech_recognition_result.cc) before it crosses the binding layer.
4. The application reads the bounds on each result event, aligns text to its media timeline, or derives processing latency (below).

measuring latency

The explainer's flagship pattern: because both the result timestamps and Event.timeStamp are relative to the same time origin, subtracting audioEndTime from the event's timeStamp yields the processing lag between when the audio ended and when the result was delivered:

const processingLatencyMs = event.timeStamp - result.audioEndTime;

An application can watch that value and fail over to a cloud backend when it breaches a threshold (the explainer uses 1500 ms as an example). Two honest caveats: the measure includes binding/IPC delivery time, not pure engine time; and the 2 ms quantization floors both attributes, so latencies below ~2 ms are not resolvable — irrelevant in practice for a failover threshold measured in hundreds of milliseconds.

syntax

Proposed spec IDL (WICG/speech-api PR #192, open — quoted verbatim):

partial interface SpeechRecognitionResult {
    readonly attribute DOMHighResTimeStamp? audioStartTime;
    readonly attribute DOMHighResTimeStamp? audioEndTime;
};

Shipping Chromium IDL (speech_recognition_result.idl at trunk, 2026-07-29 — quoted verbatim, including the runtime gate):

[
    LegacyNoInterfaceObject
] interface SpeechRecognitionResult {
    readonly attribute unsigned long length;
    getter SpeechRecognitionAlternative item(unsigned long index);
    readonly attribute boolean isFinal;
    [RuntimeEnabled=WebSpeechTimestamps] readonly attribute DOMHighResTimeStamp? audioStartTime;
    [RuntimeEnabled=WebSpeechTimestamps] readonly attribute DOMHighResTimeStamp? audioEndTime;
};

The two attributes are the entire surface: no new methods, no options, no events. SpeechRecognitionAlternative (transcript, confidence) is unchanged — timestamps live on the result, not on each alternative hypothesis.

reference

• SpeechRecognitionResult.audioStartTime — start of the audio segment for this result (nullable, 2 ms-quantized)
• SpeechRecognitionResult.audioEndTime — end of the audio segment; the input to the latency computation

examples

Live captioning with latency-based failover (adapted from the explainer):

const recognition = new SpeechRecognition();
recognition.continuous = true;
recognition.interimResults = true;

recognition.onresult = (event) => {
  const result = event.results[event.resultIndex];

  if (result.audioEndTime !== null) {
    // How far behind the audio is the engine?
    const processingLatencyMs = event.timeStamp - result.audioEndTime;

    if (processingLatencyMs > 1500) {
      console.warn(`ASR lag detected (${processingLatencyMs}ms) — failing over to cloud`);
      switchToCloudBackend();
    }
  }
};

recognition.start();

Aligning a caption to a media timeline (the audio source is a <video> element routed into recognition):

recognition.onresult = (event) => {
  for (let i = event.resultIndex; i < event.results.length; i++) {
    const result = event.results[i];
    if (result.isFinal && result.audioStartTime !== null) {
      cues.push({
        start: result.audioStartTime / 1000,  // ms → s for VTTCue
        end:   result.audioEndTime   / 1000,
        text:  result[0].transcript,
      });
    }
  }
};

browser compatibility

Interim table. There is no BCD key for audioStartTime/audioEndTime (the file covers only length, item(), isFinal, verified 2026-07-29) and a webstatus.dev query returns no feature for the attributes. Rows below are compiled from the linked primary sources, not from BCD.

For reference, BCD records the host interface SpeechRecognitionResult as Chrome 33+, Safari 14.1+ (prefixed lineage), Firefox never — the attributes above ship independently of that baseline.

security and privacy

• Fingerprinting via precise timing — sub-millisecond timing enables hardware profiling (CPU speed, thermal throttling, system load) and cross-origin tracking. The spec PR adds a mitigation clause: user agents MUST apply timestamp fuzzing and precision reduction to both attributes before exposing them to script, “e.g. by rounding to 2ms precision”.
• Chromium implements exactly that — FuzzTimestamp floors each value to a multiple of 2 ms (kFuzzInterval = base::Milliseconds(2)) inside the getter, so unquantized values never reach the binding layer (speech_recognition_result.cc).
• No new capability — the attributes expose timing metadata about audio the page already routed into recognition under the existing Web Speech API permission model (microphone permission / MediaStreamTrack input); they grant no access to new audio, engines, or devices.
• Null, not zero, for unsupported engines — an engine that cannot supply timestamps yields null, so the API does not leak a bogus “zero latency” signal that applications might misread as healthy.

The quantization in concrete terms:

// Engine reports:   audio_start_time = 1234.5678 ms
// Attribute reads:  result.audioStartTime === 1234   (floored to a 2 ms multiple)
// Engine absent:    result.audioStartTime === null   (no fuzzing applied)

specifications

see also

• Chrome Platform Status — SpeechRecognitionResult Timestamps (WebSpeech API) (API record)
• MDN — SpeechRecognitionResult (host interface; MDN does not cover these attributes — the page has no timestamp mention and the member URL 404s, verified 2026-07-29)
• MDN — Event.timeStamp (the other operand of the latency computation)
• Chromium CL 8129198 — the implementation (merged 2026-07-28)
• Chrome Platform Showcase — interactive demos for this feature
• webstatus.dev — speech-recognition feature (Baseline limited)