Timestamped transcripts — formats, word-level timing, and how to add or remove timestamps

What is a timestamp in transcription?

A timestamp is a marker that ties a piece of transcribed text to a specific moment in the original audio. It typically takes the form of a time offset from the start of the recording — 00:01:23,450 means “1 minute, 23 seconds, 450 milliseconds from the start.” In a transcript file, timestamps appear in different places depending on the format: at the beginning of each subtitle cue (SRT, VTT), as numeric properties on each word (JSON), or in brackets before a paragraph (TXT).

Disambiguation. “Timestamp” in transcription is different from a few related concepts. A timecode in video editing usually refers to SMPTE timecode (HH:MM:SS:FF, frames-based) used for video synchronization. An offset is the raw seconds-from-start number (e.g., 83.45) used internally by transcription engines. A cue is the subtitle/caption unit that contains a timestamp range (start and end), not a single moment. For transcription work, “timestamp” usually means “an HH:MM:SS,mmm formatted marker tying text to audio time.”

Modern transcription engines produce timestamps automatically as a byproduct of the speech recognition process — the model aligns each detected word against the audio waveform as part of generating the text. There's no separate “timestamping” step in 2026; if you have a transcript from a current tool, the timing data exists, even if the export you're looking at doesn't show it.

Word-level vs sentence-level vs phrase-level

The most important distinction on this page. Granularity is how often a timestamp appears in the transcript — once per word, once per sentence, once per phrase, or once per paragraph. The right level depends on what you're going to do with the transcript.

When word-level is worth it. Three cases: (1) subtitle generation, where cue boundaries need to land on real word starts and ends to sync with speech; (2) interactive transcripts (word-by-word highlighting as audio plays, jump-to-word UX); (3) video editing where you're cutting on specific words. For these, sentence-level timing interpolated across a sentence is noticeably wrong.

When sentence-level is fine. Reading the transcript as prose. Qualitative research coding in NVivo/ATLAS.ti/MAXQDA. Show notes with chapter markers at structural breakpoints. Meeting summaries. Most note-taking workflows. Adding word-level data here adds noise without analytical benefit.

The honest catch. Most consumer transcription tools default to sentence-level in their UI even when the engine produces word-level timing data. Otter, Sonix, Trint, and Rev all use Whisper-class engines (or proprietary equivalents) that produce word-level timing internally, but the default exports show sentence-level. If you need word-level, check your tool's export options — the data usually exists; it's a checkbox away.

Word-level timestamps from a transcription API

Every major speech-to-text API can return a start and end time for each word. They differ in whether you get it by default, what the fields are called, and what else rides along with each word. Those differences decide how much parsing code you write.

What the JSON actually looks like

We run two engines, so we put the same file through both. Standard tier is Whisper Large-v3 Turbo — the thomasmol faster-whisper build on Replicate, paired with pyannote for diarization. Premium tier is Speechmatics Melia-1. The output below is unedited, from an 11-second clip of John F. Kennedy’s 1961 inaugural address — the jfk.flac fixture shipped with OpenAI’s Whisper repository, which is public domain.

Whisper Large-v3 Turbo — the first word, “And”

{
  "start": 0.22,
  "end": 0.52,
  "word": " And",
  "probability": 0.83447265625,
  "speaker": "SPEAKER_00"
}

Speechmatics Melia-1 — the same word, same audio

{
  "alternatives": [
    { "content": "And", "confidence": 1.0, "language": "en", "speaker": "S1" }
  ],
  "start_time": 0.24,
  "end_time": 0.68,
  "type": "word"
}

Field names verified against the cog-whisper-diarization source, Speechmatics batch output docs and the OpenAI speech-to-text guide, August 2026.

Where the two engines put the same word

Both engines produced 22 word tokens for this clip and identical text. What differs is where each one places the boundaries, because they treat the silence around a word differently.

Neither is wrong. A word boundary is a modelling choice, not a fact in the audio — the gap before a word and the breath after it have to be assigned somewhere. The practical consequence is that timings from two engines are not interchangeable. If you build subtitle cues against one and later switch, the cue boundaries move even though the text is identical.

Punctuation, shown on one word

The clearest illustration in this clip is the comma after “so”. Whisper returns it attached to the word string. Speechmatics returns it as a separate token with zero duration:

// Whisper: the comma is inside the word
{ "start": 0.52, "end": 0.86, "word": " so,", ... }

// Speechmatics: two tokens for the same audio
{ "start_time": 0.68, "end_time": 1.04, "type": "word",
  "alternatives": [{ "content": "so", ... }] }

{ "start_time": 1.04, "end_time": 1.04, "type": "punctuation",
  "attaches_to": "previous", "is_eos": false,
  "alternatives": [{ "content": ",", ... }] }

In this file that produced 22 word tokens plus 4 punctuation tokens from Speechmatics, against 22 word entries from Whisper. Iterate the Speechmatics results array without checking type and you get 26 “words”, four of which have identical start and end times. The upside is that is_eos marks sentence-ending punctuation for you — in this clip it was true on both full stops and false on both commas, which is enough to split a transcript into sentences without writing your own rules.

Three things that catch developers out

The leading space is part of the string. Every word Whisper returned in this file begins with a space, including the first: " And", not "And". Joining without trimming gives you double spaces; trimming every word gives you none. Concatenate the raw strings, then normalise once at the end. Speechmatics returns bare content with no padding, so the same join logic will not work across both.

Speaker labels use different conventions. Whisper with pyannote returned SPEAKER_00; Speechmatics returned S1 for the same single speaker. Neither format is a standard, so any code that merges or compares output from both needs a mapping layer. Labels are also per-file: SPEAKER_00 in one recording has no relationship to SPEAKER_00 in the next. Identifying the same person across recordings is speaker recognition, a different problem from diarization.

Content sits inside an array. Speechmatics nests the word under alternatives[0].content, not a flat content field. The array shape leaves room for N-best hypotheses; in the batch output here it contained exactly one entry on every token. Read it as an array anyway — assuming a flat field is the kind of thing that works in testing and breaks later.

Fields you should not assume are always populated. From our own production runs rather than this clip: Whisper can return speaker: null when pyannote cannot attribute a segment, with the word and timing still present. Speechmatics uses "UU" for the same situation. And we have seen probability come back a hair above 1.0 on rare tokens — floating-point rounding, not a meaningful value. If you bucket by speaker or assert a 0–1 range, handle all three.

What to test before committing to an API

Vendor accuracy figures are measured on clean, read speech. The cases that break word alignment are the ones nobody publishes numbers for, so test them on your own audio:

• Overlapping speech. Published diarization error rates on spontaneous overlapping conversation sit in the 10–20% range across commercial and academic systems alike. Word timing degrades along with it, because the boundary between two speakers is exactly where alignment is least certain.
• Long silences and music. Gaps give the model nothing to anchor against, and timing after a long pause can shift.
• Accented and non-English speech. Both vendors state that accuracy varies by language. Neither publishes per-language word-alignment figures, so your language is an open question until you test it.
• Punctuation settings. Speechmatics documents that restricting punctuation through permitted_marks reduces diarization accuracy. Timing and speaker assignment are coupled more tightly than the API surface suggests.

Timestamp format syntax — SRT, VTT, JSON, TXT

Reference table for each format. The decimal separator difference between SRT and VTT is the most common cause of conversion bugs.

SRT format example

1
00:00:01,500 --> 00:00:04,200
Hello, welcome to the show. Today we're going

2
00:00:04,201 --> 00:00:07,850
to talk about something genuinely useful.

SRT is the universal subtitle format — every video editor, YouTube and standalone player accepts it. Each cue is a sequential number, a timestamp range, and one or more lines of text. Milliseconds are separated by a comma.

VTT (WebVTT) format example

WEBVTT

00:00:01.500 --> 00:00:04.200
Hello, welcome to the show. Today we're going

00:00:04.201 --> 00:00:07.850
to talk about something genuinely useful.

VTT is what HTML5 video expects. The differences that matter in practice: a WEBVTT header line, optional cue numbers, a period rather than a comma before the milliseconds, and support for cue styling that SRT has no equivalent for.

Translation preserves timestamps exactly. When a subtitle file is machine-translated — via a subtitle translator that preserves timestamps or equivalent tool — timestamps carry through byte-identical. Only the text content changes. This is what enables the same video track to work with any of 133 language versions without re-syncing: the 00:00:04,500 --> 00:00:08,200 timing anchors stay stable regardless of whether the dialogue line is 25% longer in Spanish or 40% shorter in Chinese.

JSON format example (word-level)

{
  "text": "Hello, welcome to the show.",
  "words": [
    { "word": "Hello,", "start": 1.500, "end": 1.890 },
    { "word": "welcome", "start": 1.920, "end": 2.380 },
    { "word": "to", "start": 2.410, "end": 2.530 },
    { "word": "the", "start": 2.560, "end": 2.680 },
    { "word": "show.", "start": 2.710, "end": 3.150 }
  ]
}

JSON preserves the most data, normally word-level timing as fractional seconds. This is what you want for search indexing, interactive transcripts, clip extraction and word-by-word highlighting. Schemas differ between tools — see the engine comparison above for two real examples.

TXT bracket notation

[00:01.50] Hello, welcome to the show. Today we're going to
talk about something genuinely useful.

[00:07.85] Let's get started with the first topic.

Bracketed plain text is the most readable format and the least standardised — conventions vary by tool. Used for note-taking, show notes and research transcripts, where a human reads the timestamps rather than a parser.

How to add timestamps to a transcript

In modern transcription tools, timestamps are generated automatically as part of the transcription — you don't add them separately. The question is usually whether they appear in your specific export. Here's the practical workflow:

1. Upload your audio or video to a transcription tool (VexaScribe, Otter, Sonix, Rev, etc.) and wait for processing.
2. When exporting, check the timestamp options. Most tools default to including timestamps in SRT and VTT exports automatically. For TXT and DOCX exports, the “include timestamps” checkbox is often unchecked by default — toggle it on.
3. Choose the right granularity if your tool supports it. Word-level is best for subtitles and developer use; sentence-level for prose reading and research coding.
4. For JSON output (developer use): export to JSON; word-level timing is standard.

What if you only have the text (no audio)? You generally can't add real timestamps to text alone — timing data comes from aligning the text against the audio waveform during transcription, and that step requires the audio file. Two workarounds:

• ● Re-transcribe the audio with timestamps enabled. This is the practical answer for most workflows. If the original audio is available, run it through your transcription tool again with timestamp output configured. You can then use the new transcript's timestamps with your edited text.
• ● Forced alignment — upload existing text plus the audio, get word-by-word timing matched. Uncommon in consumer tools but available in some research-focused platforms (Montreal Forced Aligner, FAVE, some academic Whisper wrappers). Setup is non-trivial; the re-transcribe path is usually faster.

How to remove timestamps from a transcript

The reverse-intent search. You have a transcript with bracket-style timestamps or SRT timing lines, and you want clean prose for publishing, blog posts, or quote extraction. Three methods, ranked from cleanest to most fragile:

# Remove bracket-style timestamps
sed -E 's/\[[0-9:.,]+\]//g' transcript.txt > clean.txt

# Remove SRT timing lines and cue numbers
sed -E '/^[0-9]+$/d; /^[0-9:.,]+ --> [0-9:.,]+$/d' subtitles.srt > prose.txt

Which granularity each job needs

Granularity is a workflow decision, not a quality ranking. Word-level timing costs nothing extra on either of our tiers, so the question is not whether you can have it — it is whether it changes anything for the job in front of you.

For most reading and searching, it does not. Where it matters is anywhere a machine consumes the timing rather than a person: subtitle cues that have to land on a real word boundary, playback that highlights the word being spoken, or alignment against a second track.

Two caveats worth stating plainly. Sentence-level timing is not a downgrade — for coding interviews in NVivo or ATLAS.ti it imports more cleanly than word-level, which adds noise the analysis does not use. And for legal work, timestamps of either kind locate a passage for a human to verify; an AI transcript is a working draft, not a certified record, and no granularity setting changes that.

Why word-level timestamps matter for subtitles

Subtitle generation is the use case where word-level vs sentence-level granularity has the most visible impact. Here's why.

The drift problem. When a transcription tool only has sentence-level timing (one timestamp per sentence), it must interpolate across the sentence to figure out where to break subtitle cues. The interpolation is linear: if a 6-second sentence is split into two cues at the comma, the first cue gets ~3 seconds and the second cue gets ~3 seconds, regardless of where the comma actually falls in the speech. If the speaker said the first half quickly and paused before the second half, the subtitle for the first half stays on screen too long (~3 seconds vs the actual ~1.5 seconds of speech) and the second half appears late. Viewers see subtitles drift visibly relative to speech.

The word-level fix. When each word has its own start and end time, cue boundaries can land on real word starts and ends. If the comma falls after “world,” at 2.4 seconds, the first cue ends at 2.4 seconds — not at the interpolated halfway point of 3 seconds. The subtitle appears and disappears in sync with what's being said.

Dramatic pauses. Word-level timing also handles dramatic pauses correctly. In a motivational speech with 2-3 seconds of silence between sentences, sentence-level interpolation produces a sub-second subtitle flash followed by a blank screen. Word-level lets a cue stay on screen across the silence (the cue ends at the real end of the last word and the next cue starts at the real start of the next word — closer to professional captioner behavior).

See cue timing and reading speed for how word-level timestamps map onto subtitle cues, and the reading-speed standards to aim for.

Which transcription tools give which granularity

Honest snapshot of where the major tools stand as of June 2026. Verify with each vendor before committing — defaults change.

The honest summary: word-level timestamps are not unique to any single tool in 2026. Every Whisper-based tool (VexaScribe, Whisper API, AssemblyAI, Deepgram, self-hosted) exposes them. The differentiator is in how the word-level data is used downstream — specifically, whether the SRT/VTT exports use word-level timing for cue splitting or fall back to sentence-level interpolation. That's where downstream subtitle quality genuinely varies.

Editing timestamps when they're off

Sometimes a transcript's timestamps are close but not quite right — drift, a missed cue boundary, a translated subtitle that needs shifting. Three tiers of editing tools:

Methodology & disclosure

Sources: SRT format conventions verified against the original SubRip specification (1996) and the Matroska container wiki. WebVTT format verified against the W3C WebVTT 1.0 specification. Word-level timestamp capabilities verified against vendor API documentation: OpenAI Whisper API docs, AssemblyAI docs, Deepgram docs, Whisper paper (arXiv:2212.04356). Tool-by-tool granularity defaults verified against each vendor's help documentation as of June 2026.

Engine output: the JSON examples and the word-boundary table come from a single 11-second file — the jfk.flac fixture from OpenAI’s Whisper repository, public domain — submitted once to each engine on 26 August 2026. Standard tier ran Whisper Large-v3 Turbo via the thomasmol/whisper-diarization build on Replicate; Premium tier ran Speechmatics Melia-1 in json-v2 batch format. Both responses are published above unedited and downloadable. This is a structural comparison of output shape and boundary placement on one recording, not an accuracy measurement, and one clip of clean single-speaker speech should not be read as representative of either engine across languages, speakers or recording conditions. Where we describe behaviour we have seen in production rather than in this file, we say so in the text.

Disclosure: This page is published by VexaScribe. Word-level timestamps are not unique to us — every Whisper-based tool exposes them. The differentiator we describe (using word-level data for SRT cue splitting) is documented on our SRT generator page; the same approach is feasible for any tool built on Whisper or equivalent engines.

Editorial standards: See our editorial standards.