Codebook Builder & Check

Build a thematic-analysis codebook that a co-author or reviewer can actually follow.

Give each code a definition, when to apply it, when not to, and an example — the discipline that makes coding consistent and auditable. The quality check flags codes missing a definition or example, near-duplicate names, and definitions that overlap. It runs entirely in your browser and checks structure, not substance: it does not read your data and does not decide whether your codes are the right ones. Nothing is uploaded. Export to CSV or Markdown any time.

No account · no upload · nothing leaves your browser. Export saves a file to your device.

Thematic analysis & codebooks, in plain terms What a codebook is, why it matters, and the terms — written for people learning the method.

What a codebook is

A living document that lists each code, defines it, says when to apply it and when not to, and shows an example from the data. It’s what lets a second coder — or a reviewer — apply your codes the same way you would.

Why it matters

Without written definitions, “coding” drifts: the same label means different things across interviews or across coders. A clear codebook makes the analysis consistent, auditable, and defensible — a rigor marker reviewers look for.

Code vs theme vs category

A code is a small label on a data segment (“voicelessness”). A category groups related codes. A theme is a broader pattern of shared meaning built from them. Codebooks live mostly at the code level.

Inductive vs deductive

Inductive coding builds codes up from the data; deductive starts from a framework or prior theory. Most studies mix both. Either way, writing definitions down is what keeps it honest.

Braun & Clarke’s six phases The most widely taught route through reflexive thematic analysis — the codebook supports phases 2–4.

Familiarisation — read and re-read the data; note first impressions.
Generating codes — label meaningful segments. This is where the codebook starts.
Constructing themes — cluster codes into candidate patterns of meaning.
Reviewing themes — check themes against the coded data and the whole dataset.
Defining & naming themes — write a clear definition for each; refine the codebook.
Writing up — build the narrative, with quotes that evidence each theme.

Frequently asked

What makes a good code definition?

A good definition says what the code means, gives inclusion criteria (when to apply it) and exclusion criteria (when not to — often the hardest and most useful part), and shows at least one verbatim example. A counter-example — a near-miss that should not be coded — sharpens the boundary further. If a definition just restates the code name, it isn’t doing any work.

How many codes should a codebook have?

There’s no target. Early inductive coding often produces many fine-grained codes, which you then merge and organise into categories and themes. If you have dozens of codes with no grouping, that’s usually a sign to consolidate — not a rule, but worth a deliberate look.

Do I need a second coder, and what is intercoder agreement?

Not always. In reflexive thematic analysis, coding is interpretative and a second coder is not required — a clear audit trail can matter more than a statistic. In more codebook- or framework-driven work, a second coder and an intercoder agreement measure (percent agreement, Cohen’s κ) are common. If you want to compute κ on two coders’ labels, Vahtian’s ExtractVahti and ReviewVahti already do that.

Should my codes be inductive or deductive?

Both are legitimate; the choice follows your question and stance. Exploratory work leans inductive (codes emerge from the data); theory-testing or applied work often starts deductive (codes come from a framework). Many studies use a hybrid. What matters for rigor is that you state which you did and define the codes either way.

What’s the difference between a codebook and a coding frame?

They overlap. “Coding frame” usually means the structured set of codes (often hierarchical) you apply, common in framework analysis and content analysis. “Codebook” emphasises the definitions and rules behind each code. In practice a good codebook is a documented coding frame.

Terms, defined

Code: A short label attached to a segment of data that captures something meaningful about it.
Codebook: The document defining every code — its meaning, inclusion and exclusion criteria, and examples — so coding is consistent and auditable.
Theme: A broader pattern of shared meaning across the data, constructed from codes and categories.
Category: A grouping of related codes that sits between individual codes and higher-level themes.
Inclusion criteria: The rule for when a code applies — what a segment must show to be coded this way.
Exclusion criteria: The rule for when a code does not apply, including look-alike cases that belong to another code.
Inductive coding: Building codes up from the data itself, without a pre-set framework.
Deductive coding: Applying codes drawn from existing theory, a framework, or prior research.
Reflexive thematic analysis: Braun & Clarke’s approach, which treats the researcher’s interpretation as central and codes as analytic outputs rather than fixed measurements.
Intercoder agreement: How consistently two or more coders apply the same codes — reported as percent agreement or a chance-corrected statistic such as Cohen’s κ.

What this can’t do. The check sees the structure of your codebook — whether codes have definitions, examples, and distinct boundaries. It cannot read your transcripts, tell whether a code fits the data, or judge whether your themes are right. Those are interpretative judgements for you, your co-authors, and your reviewers.

Turn the codebook into a defensible methods section

A clear codebook is the evidence behind your analysis. The next question reviewers ask is whether the whole approach — sampling, saturation, and reporting — holds together. MethodVahti builds that COREQ/SRQR-grounded methods argument, with an audit trail of who decided what.

See what MethodVahti does → Check your findings’ wording