Transcription Timestamps: Word-Level, Sentence-Level, and How to Add or Remove Them

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.

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 (SubRip) was developed in the late 1990s. Each cue has a sequential number, a timestamp range, and one or more lines of text. The comma decimal separator is the historical default. SRT is the universal subtitle format — every video editor, YouTube, and standalone player accepts it.

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.

WebVTT is the W3C standard for HTML5 video. Notice the WEBVTT header line, no sequential cue number (optional in VTT), and the period decimal separator. VTT also supports cue styling (positioning, fonts, voice tags) that SRT doesn't. For HTML5 <track> elements, VTT is required.

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 output preserves the most data — typically word-level timestamps as fractional seconds. This is the format developers use for search indexing, interactive transcripts, clip extraction, and word-by-word highlighting. Each transcription tool's JSON schema differs slightly (Whisper, AssemblyAI, Deepgram all have their own structures), but the pattern is consistent: a words array with start and end times.

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.

Plain text with bracket-style timestamps is the most human-readable format. Typically used for note-taking, podcast show notes, and qualitative research transcripts. There's no formal standard — different tools use slightly different bracket conventions ([HH:MM:SS], [HH:MM:SS.mmm], [HH:MM]) — but the format is robust enough to import into Microsoft Word, Notion, or research software with minimal cleanup.

Why SRT and VTT use different decimal separators

Historical and regional. SRT was developed by a French author in the late 1990s, and the comma is the decimal separator in French and most European number conventions. WebVTT was standardized by the W3C between 2010-2014 and chose the period to align with JavaScript, JSON, and broader web conventions. Both are valid in their respective ecosystems — but converting between them requires finding all commas in timestamp lines and replacing with periods (and vice versa). Tools that export both formats handle this automatically; manual conversion in a text editor with find-replace is fragile because commas in dialogue (“Hello, world”) will be caught and broken.

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

Use cases by profession

Different audiences need different timestamp granularity. The pattern below is what we see in practice from the workflows VexaScribe users describe.

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 our SRT cue splitter for the full algorithm — 80-char/5-second target, sentence-end preference, dramatic pause handling, trailing merge — and the before/after examples on real audio.

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.

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.