Two ways to import a transcript into NVivo
NVivo handles a transcript two ways, and the choice decides how you code the rest of the project. Bring it in as a plain document and you get one source to code by hand or autocode by speaker. Attach it to an audio or video file instead and NVivo imports timed rows.
The timed-rows path is a different job. You map one field to Timespan and one to Content, with Speaker as an optional third. NVivo reads timespans written with a hyphen or a forward slash between the start and end. A transcript entry there is a start-to-end time paired with what was said.
For most coding work you want the plain-document path. It's simpler and it autocodes by speaker, without asking you to align text to media timings you may not need. This guide covers that route. The timed-transcript route is worth knowing only if you're analyzing the audio alongside the text.
Format the DOCX before you import it
The formatting you do before import decides whether autocoding works. NVivo's autocode-by-speaker needs each speaker's name at the very start of a line, with nothing in front of it, no tabs and no spaces. Each speaker needs a unique, consistent name. That is the rule the official help states.
The name can sit on the same line as the response or on its own line above it. A colon after the name is a readable convention many transcripts use, but NVivo's help doesn't require one. What it checks is the line-start position and a unique name. Keep 'Interviewer' as 'Interviewer' throughout, and don't switch to 'Q' halfway.
Start from a transcript that already carries speaker labels. If you have the recording, run it through speaker diarization to get who-said-what, then export a Word .docx with each name on its own line. Typing that hour by hand would cost up to six hours of manual work, so an AI first pass plus light cleanup is far quicker.
What NVivo imports, and who makes it now
NVivo imports five document formats: Word .docx, Word 97-2003 .doc, Rich Text .rtf, Plain Text .txt, and PDF .pdf. The current help lists exactly these. For a transcript you'll code, .docx is the safe default, because it keeps the paragraph structure autocoding reads.
Choose Word over PDF when you can. A PDF imports fine, but its text layer is less predictable, and autocode-by-speaker depends on clean line starts that a .docx preserves. Plain .txt works too if your transcript is simple and unformatted.
One naming note that trips up citations: NVivo is now a Lumivero product. QSR International became Lumivero, LLC effective July 1, 2023. The current help lives on Lumivero's community site, though the older QSR-hosted help pages still describe the same import behavior.
Autocode by speaker or by heading style
NVivo gives you two autocoding routes once the document is in, and they produce different things. Autocode by speaker creates a case for each unique speaker and codes their turns to that case. Autocode by heading style creates a code for each styled paragraph instead.
The style route suits a structured document. NVivo creates a code for every paragraph in a chosen style and codes the text beneath it, with the order of styles setting the nesting hierarchy. That's how you'd code a semi-structured interview by its standard questions.
Use speaker autocoding to separate participants, and use style autocoding to separate topics or questions. Many projects use both. For how the coding choice ties back to your method and verbatim style, see the qualitative-research transcription companion.
Will the same import work on NVivo for Mac?
Mostly, with one caveat around autocoding. The import formats match, so Word, RTF, TXT, and PDF open on both Mac and Windows. But NVivo's Mac help says not all autocoding methods are available to Mac users, or to Windows users on organization accounts.
An independent CAQDAS review from the University of Surrey reached the same read: the Mac version has most, but not all, of the Windows functionality. Autocode by speaker and by paragraph style both exist across platforms, but the exact options can differ.
If your team crosses platforms, confirm the autocoding step you rely on before you commit a project to one machine. Either way, the upstream work is the same: produce a clean, speaker-labeled interview transcript first, then import and code.