Inductive vs deductive coding: differences, examples and codebooks

Inductive coding means developing codes from the data themselves, without a list prepared in advance. Deductive coding starts from codes derived from a theory, framework or earlier research and applies them to the data. Most qualitative projects combine the two to some degree, and a codebook keeps either kind of code consistent.

What are inductive and deductive coding?

A code is a short label you attach to a segment of data, such as a passage in an interview transcript, to capture something relevant to your research question. Inductive and deductive coding differ in where those labels come from.

• Inductive coding develops codes from the data. You read a transcript and name what you see, often in the participant’s own words. Johnny Saldaña’s The Coding Manual for Qualitative Researchers (fourth edition 2021; fifth edition 2025) calls codes taken directly from what participants say In Vivo codes.
• Deductive coding starts from codes defined before you read the data, drawn from a theory, a framework or earlier studies. Saldaña’s Provisional Coding is one example: a start list prepared before the analysis begins. Expect to revise it when the data challenge it.

In practice the two are ends of a continuum. No coding is purely inductive, because you always read with prior knowledge and assumptions, a point Braun and Clarke (2022) make about thematic analysis, and good deductive coding leaves room for data the framework does not cover. Coding also happens in cycles: Saldaña separates First Cycle methods, which label the data, from Second Cycle methods, which reorganise those codes into categories, themes or concepts.

The terms describe where codes come from, which is narrower than whether your whole study is inductive or deductive. A theory-led study can still code some data inductively.

Inductive, deductive, hybrid and abductive coding compared

The best-known account of hybrid coding is Fereday and Muir-Cochrane’s Demonstrating rigor using thematic analysis (2006). In a study of performance feedback in nursing, they drew up a code manual from their research questions and Schutz’s social phenomenology, applied it to transcripts and documents, and added data-driven codes where a segment showed something new. Trust and respect, for example, began inside a predetermined code and became a code of its own.

Abduction, as Timmermans and Tavory (2012) describe it, starts from findings that surprise you, given the theories you know, and works towards new explanations. You move between the data and several theories and look at the same case in more than one way. They argue that induction alone does not lead to new theory.

When to use inductive or deductive coding

Let your research question decide, along with how much is already known about the topic.

• Inductive coding suits exploratory questions and studies of experience that should start from participants’ own terms. For example: How do international students experience their first winter in Norway?
• Deductive coding suits questions built on a named theory, comparisons with earlier findings and evaluations against set criteria. For example: How do the basic psychological needs of self-determination theory appear in students’ accounts of thesis writing?
• Hybrid coding suits dissertations that take a framework from the literature review but stay open to what it misses.

Some supervisors expect a theoretical framework to guide the analysis; others prefer a data-led approach. Either way, justify the choice in your methodology chapter.

Is thematic analysis inductive or deductive? It can be either, or both. Braun and Clarke treat inductive and deductive as orientations that coding and theme development lean towards. In reflexive thematic analysis even deductive coding stays open, with no fixed codebook; codebook approaches such as template or framework analysis usually set up a structured codebook early. The guide to reflexive thematic analysis compares these versions.

Not the same as semantic and latent coding. Semantic codes capture what participants say explicitly; latent codes capture the ideas and assumptions underneath. That concerns the level of interpretation, not where codes come from, so the pairs combine freely. ‘Waits to be asked before speaking’ is an inductive semantic code, ‘silence as self-protection’ an inductive latent one, and a deductive code such as ‘competence’ can be applied to explicit statements or to what a participant implies.

How to code a transcript inductively

1. 1

   Read the transcript as a whole

   Read it once without coding, ideally while listening to the recording, and note your first impressions.
2. 2

   Code segment by segment

   Give each segment that bears on your question a short label. Stay close to the data: describe what is said, or borrow the participant’s own words as an In Vivo code.
3. 3

   Code what is relevant, including the awkward parts

   A segment can have several codes. Code everything relevant to the research question, especially passages that contradict your expectations, and leave small talk uncoded.
4. 4

   Write memos as you go

   Note why you created a code, what puzzles you and which codes seem related. Saldaña treats memo writing as a companion to coding. Memos often grow into drafts of your analysis.
5. 5

   Compare and revise across transcripts

   After two or three transcripts, rename vague codes, merge duplicates and split codes that cover too much. Then recode the earlier transcripts with the revised list.
6. 6

   Move to the second cycle

   Group related codes into categories or themes, depending on your method, and check each group against the data.

Inductive coding does not mean coding without a question. If you code everything a participant says, you end up with hundreds of codes and no direction. The research question decides what is relevant.

Deductive coding from a framework

Deductive coding begins by turning the concepts of your framework into codes you can apply consistently.

• Choose a framework that fits the question. It should come from your literature review and already shape your question.
• Operationalise each concept. Write a definition of each code in terms you can recognise in a transcript, with criteria for when to use it and when not to. This is your first codebook.
• Pilot the codebook. Code one or two transcripts, note where codes overlap or fail, and revise the definitions before you code the rest.
• Keep a place for what does not fit. Mark relevant segments that match no code. Reviewing them yields new inductive codes and stops you seeing only what the framework predicts.
• Report the misfits. What the framework could not capture is often among your most interesting findings.

DeCuir-Gunby, Marshall and McCulloch (2011) describe this sequence in a research project on teachers’ professional development. They first developed theory-driven codes from two theoretical perspectives, revised them against the interview data, and then added data-driven codes. Their article, Developing and using a codebook for the analysis of interview data, is a useful model if your dissertation uses a framework.

How to build a codebook for qualitative research

DeCuir-Gunby and colleagues define a codebook as a set of codes, definitions and examples that guides the analysis. They note that MacQueen and colleagues (1998) suggested six parts per entry: code name, brief definition, full definition, inclusion criteria, exclusion criteria and examples. DeCuir-Gunby et al. used three: the name, a full definition that folds in the criteria, and an example. For a dissertation, a middle way works well:

• Code name: short and distinct, so it is easy to apply.
• Definition: what the code means in this study, in a sentence or two.
• Use when: the inclusion criteria, with typical cases.
• Do not use when: the exclusion criteria, especially the line between this code and a similar one.
• Example quote: an extract that shows the code at its clearest.

The study below is invented. It asks how international master’s students stay motivated while writing their thesis, with the three basic psychological needs of self-determination theory (Ryan and Deci, 2000) as deductive codes and one inductive code added during coding.

Date each version and note what changed and why. Put the final version in an appendix, so your examiners can see how each code was defined.

Check your university’s rules before you upload recordings anywhere: a voice identifies the speaker, so a recording is personal data even without names. Spirelight offers no data processing agreement; your university, not you, would sign one. Transcription runs on EU servers, files are stored with Google Firebase in the US, and AI features run on OpenAI in the US, which your ethics application and participant information sheet must state.

Where your university allows it, you can transcribe your interviews, build one code list for the project and apply codes with a keyboard shortcut. The code overview shows every extract with a given code across all interviews. The code list holds names and colours, so keep the definitions and criteria in a document beside it. Nothing is coded automatically.

The reliability debate: do you need a second coder?

Whether a second person should code your data and measure agreement with you is a long-running debate in qualitative research. The answer depends on your approach.

In coding reliability approaches, such as Boyatzis (1998), the codebook works like a measuring instrument: several coders apply it independently and their agreement is calculated. DeCuir-Gunby et al. (2011) describe the usual measures, from simple percentage agreement to kappa statistics such as Cohen’s kappa. O’Connor and Joffe (2020) argue that measuring intercoder reliability can make coding more systematic and transparent, prompt reflexive discussion in a team and reassure varied audiences, and they give practical guidance on doing it.

Braun and Clarke (2022) take the opposite view for reflexive thematic analysis. Coding is interpretation, so there is no correct coding for a second coder to confirm, and an agreement score mainly shows that two people were trained to code alike. Discussing your codes with a supervisor or peer is welcome, but to deepen the analysis, not to reach consensus.

For a dissertation you will usually code alone. If you follow a codebook approach and your department expects a reliability check, ask someone to code part of the data, report how you measured agreement and resolved disagreements, and use the result to sharpen your definitions. If you follow reflexive TA, leave agreement scores out and describe your reflexive process. Either way, keep your memos and codebook versions, so a reader can follow how you reached your findings.