In Vivo Coding 101 (With Examples)
When (and how) to use your participants' own words as codes
The 30-second summary
In vivo coding is a qualitative technique where the participants’ own words become your codes. If your interviewees call their garden their “little oasis”, that’s the code.
- It’s inductive: codes emerge from the data, not from theory you bring.
- It suits studies where language matters: “going into battle” says what a tidier label strips out.
- Verbatim codes also lower the risk of reading data through your own cultural lens.
- Read through once, build a code list, apply it on a second pass, then categorize.
Once categorized, your data is ready for thematic analysis.
Navigate
In vivo coding is the technique where you stop paraphrasing your participants and use their exact words as your codes. This post covers what it is, which projects it suits, when it works against you, and how to run it start to finish, with worked examples throughout.
First, the big picture
At the most basic level, qualitative coding is the process of labeling and categorizing textual data. The coding process is foundational because it sets the scene for you to start identifying themes and patterns within your data, and ultimately, extracting insights from it. In other words, coding is the first step in the broader qualitative analysis process.
Coding comes in three overarching approaches: inductive (codes emerge from the data), deductive (codes come from existing theory) and hybrid, which blends the two. In vivo coding sits firmly in the first camp, since the codes can only come from what participants actually said.
Which approach fits your study depends on your research aims and research questions. Our guide to inductive vs deductive coding compares all three, and works through the same extract coded inductively and then deductively.
What is in vivo coding?
The term “in vivo” originates from Latin, where it means “within the living”. More practically though, it refers to the act of studying something in its natural environment. So, within the context of coding, in vivo refers to a technique where you use the participants’ own words as your codes, as opposed to creating codes based on your interpretation of their words.
The obvious question is why anyone would strip coding back this far. One benefit of in vivo coding is that it helps you avoid inferring meaning by staying as close to the original phrases as possible. That matters most in studies where the phrasing itself carries the meaning, and a tidier label would strip it out.
In vivo coding can also be useful when your data are derived from participants who speak different languages or come from different cultures, as it reduces the risk of you interpreting the data through your own cultural lens.
For example, English speakers typically view the future as in front of them and the past as behind them. However, this isn’t true for all cultures. Speakers of Aymara in the Bolivian Andes view the past as in front of them and the future as behind them. In a situation like this, in vivo coding would help avoid misinterpretation due to this subtle but significant cultural difference.
What it looks like on the page
Here is a short extract from an interview about workplace culture, with in vivo codes applied:
| Interview extract | In vivo code |
|---|---|
| “You learn pretty quickly to keep your head down.” | Keep your head down |
| “Everyone’s just fighting fires all day, no one plans anything.” | Fighting fires |
| “I dropped the ball on a report and heard about it for weeks.” | Dropped the ball |
| “The team feels like a family, honestly.” | Like a family |
Notice that not one of those codes is a word you would have chosen yourself. “Keep your head down” carries a caution that “self-protective behavior” does not, and it came free. There are more worked examples of this and other techniques if you want to see them side by side.
How to do in vivo coding
In vivo coding runs in four steps.
- Gather and prepare your dataset. This may be interview transcripts, field notes, or secondary data such as organizational documents.
- Read through once, without coding. The point is to understand the dataset as a whole rather than getting tunnel vision on one or two portions of it. Note any patterns you see, and start a list of candidate in vivo codes. Remember that these have to be lifted from the text verbatim.
- Read again, applying your codes. New codes will keep emerging as you go, so add them to the list and apply them. This usually means cycling back and forth through the data so that everything is coded consistently.
- Group your codes into categories. This step is called code categorization, and the categories need to reflect patterns that are relevant to your research aims.
There is no single correct way to categorize a set of codes. Different threads run through any dataset depending on what you are looking for, so the test is whether your categories link clearly to your research aims. A study of emotional states might group the same codes under anger, fear, surprise and disgust instead.
Once you’ve applied your codes and categorized them into logical groups, your dataset should, in principle, be ready for analysis. This might take the form of something like thematic analysis or content analysis, depending on your specific research aims. Our guide to choosing a qualitative analysis method covers the most popular options.
When not to use in vivo coding
In vivo coding is not the right default for every study, and the reasons are practical rather than theoretical.
When your codes need to compare across cases. Verbatim codes are particular by design. If three participants describe the same experience as “treading water”, “spinning my wheels” and “stuck in the mud”, you have three codes for one idea, and comparing across your sample means categorizing them anyway. Descriptive coding gets you there faster.
When your dataset is large. Code proliferation is the standard complaint. Verbatim codes multiply roughly with the number of participants, which is manageable for 12 interviews and painful for 60. On a corpus that size, an indexing pass with structural coding first will at least let you work through one research question at a time.
When your aims are confirmatory. If you are testing an existing framework, you need its constructs as your codes, which is deductive work. In vivo can still be a useful first pass to stay close to the data, but it will not answer the question you set. If what you are after is what participants value rather than how they phrase it, values coding is the better fit.
When the language is not the point. In a study of processes or sequences, what people did matters more than how they phrased it, and process coding fits better.
A practical compromise: run in vivo on a first pass to stay close to participants’ language, then categorize those codes into broader groups on a second pass. You keep the fidelity and get something you can compare. The University of Connecticut’s research basics guide places in vivo within grounded theory’s open coding phase for exactly that reason.
In vivo coding vs NVivo
These get confused constantly, and they have nothing to do with each other.
In vivo coding is the technique described on this page: using participants’ exact words as codes. The term is Latin, meaning “within the living”.
NVivo is a software package, made by Lumivero, for managing qualitative data. You can use it to do in vivo coding, and you can equally use it for deductive coding, or for no coding at all. You can also do in vivo coding with no software whatsoever, which is what most students do.
The confusion is understandable and it costs people time, so if an advisor or a paper mentions one, check which is meant before you go looking for a download.
Still have questions?
What is an in vivo code?
A code lifted word for word from what a participant said, rather than a label you wrote to summarize it. If an interviewee describes their workload as “drinking from a firehose”, the in vivo code is “drinking from a firehose”. The test is simple: if you cannot point to the phrase in the transcript, it is not an in vivo code.
How many in vivo codes should I end up with?
More than you would from other techniques, which is the nature of it. Expect dozens rather than a handful after a first pass on ten interviews. That is not a sign you have done it wrong; it is the reason categorization is a separate step, and why in vivo is usually a first pass rather than the whole analysis.
Can I edit a participant’s wording to tidy up a code?
Not if you are calling it in vivo. Trimming a filler word is fine, but the moment you rephrase for neatness you are writing a descriptive code and should say so in your methodology. Half the value of the technique is that the code is defensibly theirs rather than yours.
Does in vivo coding work with translated transcripts?
It works, but the code belongs to the translation rather than the participant, which weakens the main argument for using it. If language is central to your study and your data are translated, say so explicitly in your methodology, and keep the original phrase alongside the translated code where you can.
Can’t find your answer here? Ask a Grad Coach directly – the initial chat is free.
Speak with a friendly coach →
