Somewhere around transcript six, you look up and realise you have 140 codes. Half of them have been used once. Two of them are "Worry" and "Worries". Here's the short version: the count itself is rarely the problem. Most applied projects settle somewhere between 30 and 70 codes, and drifting past 100 usually means a consolidation pass is overdue. But the real test isn't a number. It's whether you can still tell your codes apart without checking.
How many codes is normal in a qualitative analysis?
Most applied qualitative projects land between 30 and 70 codes by the end of analysis. Under 20 often means you're coding too coarsely to say anything specific; past 100, most researchers benefit from consolidating, unless they're deliberately mid-way through a first inductive pass.
There's no official guideline here, and anyone who gives you a single magic number is selling something. One QDAS consultant reports that the smallest codebook they've used on a substantial project had 22 codes, while other projects genuinely needed several hundred. Quirkos points out that ending up with a hundred-plus codes is common and, with software, often fine. CleverX takes the opposite line for applied user research: hundreds of overly specific codes make pattern recognition impossible.
Both are right, and the disagreement dissolves once you factor in the stage of analysis. A sprawling code list during first-cycle coding is raw material. The same list at write-up time is a warning sign.
If you want a rule of thumb to pin above your desk:
Under 20 codes: probably too general. You're summarising topics, not analysing them.
30 to 70 codes: the working range most interview studies and applied projects end up in.
Over 100 codes: time for a consolidation pass, unless you're still in an early inductive cycle with software doing the heavy lifting.
What are the warning signs you actually have too many?
You have too many codes when you can no longer distinguish them from memory, not when you cross some numeric threshold. The symptoms are behavioural, and they're easy to spot once you know them.
The classic tell is the accidental near-duplicate. If your codebook contains "Worry" and "Worries", or "lack of planning time" and "insufficient planning time", that's not a labelling quirk. It means the list has outgrown your working memory, and you're now re-inventing codes instead of applying them.
A few more red flags worth checking for. Retrieving a code returns fragments so small they mean nothing out of context. Most of your codes sit orphaned, connected to no category and no other code. And you coded "helter-skelter", without a plan for what the next analytical step would be, so the codes describe everything and explain nothing. Any two of these together is enough reason to stop coding and tidy.
How do you shrink a bloated code list without losing nuance?
Merge near-duplicates first, then build parent-child hierarchies, then cut codes that don't serve your research question. Done in that order, you can usually halve a code list in an afternoon without losing a single insight.
Start with the cheap wins: fold "customer" into "customers", "Worry" into "Worries". Then merge codes that name the same phenomenon in different words. In one worked example from a user research project, "can't find feature", "feature discovery problem", and "unclear feature location" collapse into a single code, "feature findability issues". Nothing is lost; the pattern just becomes visible.
Next, build hierarchy instead of deleting. If you're carrying "teachers are tired", "teachers are hungry", and "teachers don't have enough planning time", nest all three under a parent code like "burnout". The nuance stays retrievable; the top level of your codebook becomes readable again. And sometimes the fix runs the other way: a dumping-ground code like "collaboration challenges" gets more manageable when you split it into "real-time editing conflicts", "permission confusion", and "notification overload", because the boundaries finally become clear.
The prevention, as opposed to the cure, is a codebook with real definitions: what the code means, when to apply it, and explicitly what it should not be applied to. Code drift happens when those definitions live only in your head. This is also where software honestly earns its keep. In Paideias, definitions travel with the code, and the AI flags likely near-duplicates and suggests merges, which you approve or reject; the judgement call stays yours. If you're still building those instincts, our walkthrough on coding your first transcript covers how to set the codebook up before bloat sets in.
One last pass: relevance. It's normal to have coded genuinely interesting material that has nothing to do with your research question. Don't delete those codes; mark them as out of scope for this project and set them aside. Your list tightens immediately, and the material is still there for the next paper.
When are hundreds of codes perfectly fine?
Hundreds of codes are legitimate during first-cycle inductive coding with software, and on genuinely large or complex projects where the data demands it.
Inductive coding is supposed to balloon early. You generate specific codes as you meet the data ("Fast food", "Mexican", "Chinese") precisely because merging them later under "Restaurant" is a two-click operation in any decent tool. What would be unmanageable with highlighters and paper is routine in software, which is why experienced coders will tell you not to fear specificity on the first pass. Deductive projects run the opposite trajectory: you start with a small framework of broad codes and split them as the data reveals variation.
The trap isn't having many codes at some point. It's never leaving that state. At some stage you have to stop coding altogether and start theming, querying, and writing, and a code list that's still growing at transcript twenty is usually a sign you're avoiding that shift. We've written before about knowing when to stop interviewing; knowing when to stop coding deserves the same discipline.
FAQ
Should I merge codes or delete them?
Merge by default, park by exception, delete almost never. Merging preserves the coded data under a new label, so nothing is lost if you change your mind. Codes that are genuinely off-topic are better marked out of scope than destroyed; qualitative data has a habit of becoming relevant to a later question.
Does inductive coding always produce more codes than deductive?
Early on, almost always. Inductive coding generates codes as you encounter concepts, so first-cycle counts run high before merging brings them down. Deductive coding starts from a leaner theoretical framework and grows by splitting. By the final cycle, the two approaches often converge on similar-sized codebooks.
Will more codes make my analysis more rigorous?
No. Rigour comes from applying codes consistently and being able to show how you got from data to themes, not from granularity. A 200-code book applied inconsistently is weaker than a 40-code book with clear definitions. If consistency is what you're worried about, our post on intercoder reliability covers when it's worth formalising and when it isn't.
Discussion
or sign in to comment with your account