In Vivo Coding: Definition, Steps and Examples

In vivo coding is usually the first coding method qualitative methods students meet in Saldaña's Coding Manual, and one of the easiest to get subtly wrong. The rule sounds trivial (use the participant's words), but in practice analysts paraphrase, tidy grammar, pull phrases from the interviewer's turn, or wrap their own concepts in quotation marks. This guide gives a precise definition, two worked examples, a side-by-side comparison of in vivo vs descriptive vs process coding, and a checklist for proving in a methods chapter that your in vivo pass really is verbatim.

It also covers the 2026 question that supervisors now ask: can an AI tool do in vivo coding? The short version is that language models are good at finding exact spans and bad at resisting the urge to paraphrase them, so the method needs tighter constraints than most other coding when software is involved.

Last updated: October 7, 2026

Key takeaways

• In vivo coding means coding in the participant's own words: "it just fights me", not Usability frustration.
• It is a first-cycle method, not a whole analysis. Saldaña positions it as an early pass that feeds a second cycle of pattern, focused or axial coding.
• In vivo vs descriptive vs process: in vivo captures how people say it, descriptive captures what the passage is about, process captures what people are doing (gerunds).
• Its main value is anti-drift. Because the code is the participant's phrase, you cannot quietly substitute your own framing in week one and forget you did.
• AI coding tools are structurally biased against it. Language models paraphrase by default, and paraphrase is the one thing in vivo coding forbids.
• Use the In Vivo Fidelity Checklist below before your first-cycle codes go into a second cycle.

What is in vivo coding?

In vivo coding is a qualitative data analysis method in which each code is a word or short phrase taken verbatim from the participant's own speech or writing. The Latin in vivo, "in that which is alive", is the point: the code stays inside the living language of the data instead of being translated into academic or product vocabulary.

The term comes from grounded theory, where Anselm Strauss distinguished in vivo codes (terms the people studied actually use) from codes the sociologist constructs. Johnny Saldaña's The Coding Manual for Qualitative Researchers made it one of the standard first-cycle methods; the 5th edition (SAGE, 2025) profiles more than 35 coding methods and adds discussion of generative AI. A June 27, 2026 review in The Qualitative Report summarizes the edition's stance: computational tools are supportive, while interpretation, contextual judgment and ethical accountability remain the researcher's duties.

The method also appears under the names verbatim coding, literal coding and indigenous-term coding (see the Wiley International Encyclopedia of Communication Research Methods entry on In Vivo Coding). Convention is to wrap in vivo codes in quotation marks so that anyone reading the codebook can see which labels came from participants and which came from the analyst.

How to do in vivo coding: five steps

1. Read the transcript once without coding. You need to hear the participant's register before you can tell which phrases carry weight.
2. Mark candidate phrases. Look for words that are repeated, emphasized, metaphorical, emotionally loaded, or in-group jargon. Saldaña's practical advice is to watch for what the participant seems to stress.
3. Trim to a label. Cut each phrase to roughly two to eight words that carry the meaning on their own. Do not change the words, reorder them, or correct grammar.
4. Record provenance. Store transcript ID, speaker and line or timestamp with every code, and wrap the code in quotation marks.
5. Write a short analytic memo. Note why each phrase looked important. The memo, not the code, is where your interpretation goes in the first cycle.

Worked example 1: a product interview

Take one line from a hypothetical onboarding interview:

"I didn't finish setup. I kept waiting for it to tell me what it wanted and it never did, so I just closed the tab and went back to the spreadsheet."

Coding method	Code applied	What it preserves	What it loses
In vivo	"waiting for it to tell me what it wanted"	The participant's mental model: they expected to be led	Comparability across participants who said it differently
Descriptive	Setup abandonment	Where in the journey the event sits	Why it happened, in their terms
Process	Reverting to prior tool	The action and its direction	The affective texture of the giving-up
Concept / analytic	Guidance expectation violation	A construct you can theorize with	All original wording; the abstraction is now yours

The concept code is not wrong. It is simply a claim, and in vivo coding's discipline is that you make that claim in cycle two, on the record, rather than in cycle one by accident.

Worked example 2: an academic interview

A hypothetical early-career teacher, interviewed for a study on workload:

"Sundays are basically school days now. You're not marking, exactly, you're just sort of carrying it around in your head the whole time, and my partner calls it the Sunday dread."

Defensible in vivo codes: "Sundays are basically school days", "carrying it around in your head", "the Sunday dread". A descriptive code would be Weekend workload; a process code would be Ruminating about work. Note that "the Sunday dread" is the partner's phrase, reported by the participant. Keep it, but memo that it is reported speech: whose language a code belongs to is part of the data.

In vivo vs descriptive vs process coding

These three are the first-cycle methods most often confused. The difference is what the code is made of. In vivo codes are the participant's words; descriptive codes are the analyst's noun for the topic; process codes are the analyst's gerund for an action. All three are legitimate, and many studies combine them.

Criterion	In vivo coding	Descriptive coding	Process coding
Code is made of	Participant's exact words, in quotes	Analyst's word or short noun phrase	Analyst's gerund ("-ing" word)
Answers the question	How do participants put it?	What is this passage about?	What are people doing?
Example (teacher interview)	"the Sunday dread"	Weekend workload	Ruminating about work
Comparability across cases	Low until grouped in cycle two	High	High for sequences and routines
Best for	Exploratory, grounded theory, language-sensitive or marginalized-voice studies	Inventories, document analysis, large or mixed datasets	Routines, change over time, interaction and strategy
Main risk	A sprawling code list; paraphrase creeping in	Flattening meaning into topics	Imposing action where there is none
AI-assist fit	Exact-span extraction only, with provenance	Good for first drafts, check coverage	Moderate; check the actor is right

A common hybrid is in vivo plus process coding in the first cycle, then focused or axial coding to group both into categories. For how codes become categories and themes, see codes vs categories vs themes, and for the grounded-theory sequence, see open, axial and selective coding.

When in vivo coding earns its cost

In vivo coding is slower per transcript than descriptive coding and produces a larger, messier initial code list. That trade is worth making in four situations.

• Early, exploratory studies where imposing your categories too soon would foreclose the finding. If you already know the categories, you are doing deductive coding; see inductive vs deductive coding.
• Jargon-dense or subcultural domains. When a participant says "shadow IT", "the dirty list" or "vibe check", the term itself is data. Flattening it into Informal process destroys the signal.
• Studies about language. Naming research, positioning, messaging tests and anything that will ship as copy should code in the respondent's words, because the deliverable is words.
• Power-asymmetric or sensitive research. When participants are described by institutions that have historically named them badly, keeping their terms is an ethical position as well as a methodological one. It pairs naturally with reflexivity practice.

Who this is for

PhD students and academic qualitative researchers doing first-cycle coding for a thesis or article; research labs that need two coders to produce comparable codebooks; qualitative and market research firms working in categories with strong in-group vocabulary (clinicians, developers, traders, teachers); and UX or insights teams running discovery interviews.

When not to use this approach

Skip it, or demote it to a spot check, when you are coding at scale against an established framework; when your transcripts are machine translations (the "verbatim" wording is already the translator's, see whether to translate interviews before AI analysis); when the research question is about frequency rather than meaning; or when transcript quality is poor enough that verbatim phrases are artifacts of speech recognition rather than of the speaker.

Choosing a first-cycle coding method

If your goal is…	Use	Why
Hearing how participants themselves frame the problem	In vivo	Codes cannot outrun the data
Mapping what happened, in order	Descriptive / process coding	Comparable across cases
Testing a pre-existing framework	Deductive / a priori codebook	Coverage and reliability; see the codebook template
Building theory from the ground up	In vivo, then focused / axial coding	Grounded-theory sequence; see thematic analysis vs grounded theory
Counting themes across hundreds of responses	Content analysis or LLM-assisted coding	In vivo does not aggregate; see LLMs vs ML for open-ended coding

In vivo coding meets AI: the paraphrase problem

Large language models are trained to produce fluent, normalized, abstracted language. In vivo coding requires the opposite: unpolished, participant-owned language. Ask a general-purpose model to "code this transcript" and it will mostly return analyst-voice concept codes such as Onboarding friction or Trust barrier, because that is what coding looks like in its training data. The model is not malfunctioning; it is answering a different question than an in vivo pass asks.

The evidence supports being specific about what you delegate. In a CHI 2026 study of ChatQDA, an on-device open-source LLM coding tool, researchers reported conditional trust: they valued the system for explicit content extraction but doubted it on deeper interpretation, because the open-source models tended to identify surface-level statements close together in the conversation. That is a small study (four participants, one 5-page transcript each), so treat it as a signal about failure modes, not an effect size.

Read against in vivo coding, that limitation is convenient. Finding the phrase a participant actually used, anchored to its line, is a retrieval-shaped job. Deciding that three different phrases are one construct is an interpretive job, and it is the one to keep. A 2025 Sociological Methods & Research study on qualitative coding with generative LLMs found models can approach supervised-ML performance at matching hand-coded output, while the QualAnalyzer work argues the practical requirement is process auditability: every code traceable to the span that produced it. For in vivo coding, span-level traceability is the method's definition of correctness.

A prompt pattern that actually yields in vivo codes

If you use a model for a first in vivo pass, constrain it against its defaults:

For each meaningful segment, return: (1) the code as an exact verbatim span copied from the transcript, 2–8 words, no paraphrase, no synonyms, no reordering; (2) the line or timestamp it came from; (3) the speaker. Do not create categories, themes, or analytic labels. If no span in the segment carries the meaning on its own, return NO_VERBATIM_SPAN rather than inventing a label. Preserve the participant's grammar, slang, hedges, and profanity exactly as spoken.

The NO_VERBATIM_SPAN escape hatch matters. Without it, a model asked for verbatim codes will produce near-verbatim ones: a quote-shaped string that is not a quote. That is the failure class covered in our piece on hallucinated quotes in qualitative analysis.

The In Vivo Fidelity Checklist

An original Qualitati asset. Run it over any in vivo pass, human or AI-assisted, before the codebook goes to a second cycle. Score one point each; 8 or more is defensible, 5–7 needs a repair pass, under 5 is analyst-voice coding wearing quotation marks.

1. Verbatim check. Every code string appears character for character in the transcript. Spot-check 10% with a literal text search, not by eye.
2. Provenance check. Every code carries transcript ID, speaker and line or timestamp.
3. Speaker check. No code is drawn from the interviewer's or moderator's turn. This is the most common silent error, and it is worse with AI moderation, where the moderator's phrasing is fluent and quotable.
4. Register check. Codes keep hedges, slang and disfluency where those carry meaning. A corpus of grammatically clean codes is a corpus of edited codes.
5. Abstraction check. No code is a noun phrase no participant would say out loud. "it just fights me" passes; "usability friction" does not, even in quotes.
6. Coverage check. Segments with no codable verbatim span are marked as such rather than force-fitted.
7. Distribution check. Codes are not concentrated in the first third of each transcript, a signature of both fatigued human coders and truncated model context.
8. Duplication check. Near-identical phrases stay distinct at this stage. Merging is a cycle-two decision, made explicitly.
9. Translation check. For non-source-language data, codes are stored in the original language with a gloss, not replaced by the translation.
10. Second-reader check. A second person can re-derive at least 80% of the codes from the marked spans. On reliability generally, see intercoder reliability in AI qualitative coding.

Where Qualitati fits

Qualitati is a European, budget-friendly qualitative research platform for universities and research companies, with data privacy and GDPR as central priorities. Two parts of it touch in vivo coding directly.

• QDA Workspace supports AI-assisted inductive and deductive coding, codebook generation and theme visualization. That is where a first-cycle verbatim pass lives and where you promote it into higher-order codes in a second cycle you control.
• ThemeLens runs a map-reduce thematic analysis across up to 100 transcripts at once, mapping codes to research questions and synthesizing themes with participant-anchored quotes, so themes can be audited back to the speaker.

Data collection matters too. In vivo coding is only as good as the language it works with, so AI-moderated interviews that probe rather than accept the first answer produce more codable verbatim material, and Active Listener mode keeps a human interviewer in charge with real-time prompts when the wording is the point. Research in 10 languages makes checklist item 9 practical rather than aspirational.

Qualitati publishes per-credit usage rates and starts free with 30 monthly credits, no credit card required.

Limitations and trade-offs

In vivo coding does not scale, and that is partly the design. A hundred transcripts of verbatim codes is not an analysis; it is a concordance. The output has to be reduced by a human who is willing to own the abstraction. Teams that adopt in vivo coding and skip cycle two end up with rich, unusable data.

Verbatim is not the same as authentic. A phrase is only the participant's if the transcript is accurate, the moderator did not supply it first, and a translation did not create it. Speech-recognition error rates are not uniform across accents (see transcription accent bias), so verbatim fidelity can be unevenly distributed across your sample.

The AI evidence base is thin and recent. The studies cited here are small-N user studies and exploratory comparisons, not benchmarks with established construct validity. Human-review note: if your methods section claims that an AI-assisted pass preserved participant voice, that claim needs your own documented verification on your own data.

FAQ

What is the difference between in vivo coding and descriptive coding?

In vivo codes use the participant's exact words in quotation marks; descriptive codes use the analyst's own word or noun phrase to summarize the topic of a passage. In vivo preserves voice and framing; descriptive coding gives comparable topic labels across cases. Many studies use both in the first cycle.

Is in vivo coding inductive?

Yes. Because codes come from the data rather than from a pre-existing framework, in vivo coding is an inductive, data-driven method. It can run alongside a deductive codebook as a check on what the framework has no slot for.

Is in vivo coding the same as quoting?

No. A quote is evidence you present; an in vivo code is a label you analyze with. The code is short enough to recur across the dataset and is attached to a span, not to a paragraph of illustration.

How long should an in vivo code be?

Short enough to be a label, long enough to carry meaning on its own. Two to eight words is the working range. A full sentence is usually a quote that has not yet been coded.

Can an LLM do in vivo coding reliably?

It can do the extraction step usefully under tight constraints (exact spans, line references, an explicit refusal option), but it should not decide which distinct phrases mean the same thing. The CHI 2026 ChatQDA study found that split: acceptable on surface extraction, weaker on meaning distributed across a transcript.

What comes after in vivo coding?

A second cycle: pattern, focused or axial coding that groups in vivo codes into categories, then theme development. In Saldaña's framing the first cycle is deliberately provisional; treating it as final is the method's most common misuse.

Bottom line

In vivo coding is a small, strict discipline with an outsized effect: it forces the first pass over your data to stay in the participant's language, so every later abstraction is a visible decision rather than an invisible one. That discipline matters more as AI enters the coding workflow, because a fluent model's default is to abstract immediately. Use AI for exact-span extraction with provenance, and keep the judgment about what those spans mean.

Start free with 30 credits and run a first-cycle coding pass in QDA Workspace, or view transparent pricing. Comparing tools? See how Qualitati sits against NVivo, ATLAS.ti, MAXQDA and AI-native research platforms, or create an account and code a transcript today.