Short answer
- Computer programs for qualitative data analysis, often called qualitative data analysis software or QDA software, help researchers organize, label, search, and compare nonnumeric material such as interview transcripts, field notes, open ended survey answers, documents, images, audio, and video. The central task is coding: attaching short labels, called codes, to passages that share a meaning, so related material can be retrieved together later. The software does not interpret material for the researcher. It keeps source material, codes, notes about decisions, and links between them in one project, so patterns can be checked against the original words, images, or recordings rather than remembered loosely. Think of these programs as a structured workspace: they make a large, messy set of material searchable and traceable, while judgment about what a passage means stays with the researcher. These programs are also known as computer assisted qualitative data analysis software, shortened to CAQDAS. University library guides use QDA software, QDAS, and CAQDAS for the same broad family of tools. When a project has only a few short documents, a word processor and careful notes may be enough. When a project has dozens of transcripts, hundreds of open ended answers, or material in several formats, a dedicated program can save time and reduce errors, mainly because retrieval, comparison, and an audit trail are built into the workflow.
What Counts as Qualitative Material
Qualitative material is material that is not primarily numbers. The University of Delaware library guide puts it plainly: qualitative data is essentially any data that is not numbers, and it often consists of words but can also be the interpretation of images and videos. Interviews explore thoughts, experiences, and perspectives in depth. Observations record behavior in natural settings. Documents can include letters, reports, diaries, and other written content relevant to a research question. Fieldwork adds firsthand notes from time spent in a research setting. Open ended survey answers sit at the boundary between qualitative and quantitative work, since one survey can produce counts for closed questions and rich text for open questions.
That variety matters for software choice, because not every program handles every format equally well. Text is the most widely supported format. Audio and video support varies: some programs link a transcript to time points in a recording, so a reader can jump from a coded passage to the exact moment in the recording. Image support also varies: some programs allow coding of regions of an image, while others treat an image mainly as a document to annotate. Before settling on a program, list the actual formats a project will use and test a small sample in each format.
What the Software Actually Does
At its simplest, a qualitative analysis program does five jobs. First, it imports and organizes source material into a project, often grouped by participant, site, time point, or document type. Second, it supports coding: selecting a passage and attaching one or more labels to it. Third, it retrieves coded material on demand, for example all passages coded as trust in local services. Fourth, it supports comparison, through queries, matrices, and visualizations that show where codes overlap and where they differ across groups. Fifth, it keeps a record of the analysis itself, through memos, code definitions, and project logs that show how codes changed over time.
Those five jobs explain why researchers describe the software as an aid to rigor, not as a shortcut. Retrieval makes it possible to return to every passage behind a theme, rather than relying on a few memorable quotations. Comparison makes it possible to test an emerging idea, for example by asking whether a pattern holds for all groups or only for one subgroup. Memos record why a code was created, merged, split, or renamed. None of that guarantees a good interpretation, but it makes weak support, inconsistent coding, and quotations read out of context easier to find and correct, because the evidence trail is visible.
What the Software Does Not Do
Three limits deserve emphasis. First, the software does not code on its own in the sense that matters for research quality. Some programs offer text search, automatic coding by keyword, or newer automated assistance, but a keyword hit is not the same as a judgment that a passage expresses a particular meaning. Automated help can suggest candidates, but the researcher still needs to read, confirm, correct, and document decisions. Second, the software does not choose a method. Thematic analysis, grounded theory, content analysis, discourse analysis, and narrative analysis each carry their own assumptions about evidence and themes. A program can support several approaches, but it cannot decide which fits a research question. Third, the software does not make findings trustworthy by itself. Trustworthiness comes from a clear question, careful data collection, consistent coding, checking interpretations against the full data set, and honest reporting of limits, including cases that do not fit a theme.
Counts inside qualitative programs need the same caution. Counts of coded passages, word frequencies, and code co-occurrence tables can show whether a pattern is widespread or rare. They do not turn qualitative work into quantitative work, and a high count does not by itself prove importance. A single detailed account can matter more than a frequently repeated phrase, depending on the question. Use counts as a prompt to look closer, not as a final answer.
Coding Explained in Plain Language
A code is a short label that captures what a passage is about or what it illustrates. In interviews about using a local clinic, passages might be coded as waiting time, cost worry, trust in staff, or travel difficulty. Coding starts with reading and rereading material to get familiar with it, a step university methods guides treat as essential. The University of Delaware guide describes the sequence as familiarizing with the data, identifying patterns and groups, and applying codes that group similar pieces of material together. A guide from the University of British Columbia describes thematic analysis in six steps: familiarize with the data, generate initial codes, search for themes, review themes, define and name themes, and produce the report.
Researchers distinguish three broad ways to build codes. In an inductive approach, codes develop from the data itself, with no preset list. In a deductive approach, codes come from an existing theory or framework, useful when a project aims to test or apply that framework. In a hybrid or abductive approach, a project starts with some preset codes and adds new codes as patterns appear. None is automatically better. The choice depends on the question, prior literature, and openness to unexpected findings. What matters is that the choice is stated, so a reader can judge whether analysis matches its aims.
Codes are usually organized in a codebook, a living document inside or alongside the project. A codebook lists each code, gives a clear definition, gives an example that fits, gives an example that does not fit when the boundary is unclear, and notes when the definition changed. Early in a project, a researcher may code three or four representative transcripts, then discuss the draft codebook with a second researcher who coded the same subset independently. That discussion often reveals vague definitions and overlapping codes. Fixing them early saves rework, since renaming or splitting a code after hundreds of passages have been coded is far more disruptive.
Open coding breaks material into discrete concepts and categories. Axial coding then explores how those concepts relate, for example what conditions shaped a pattern, what context surrounded it, and what consequences followed. A later stage refines categories into core themes. Programs support this by allowing codes to be grouped into hierarchies, merged, split, renamed, and linked to memos. A tidy code tree is a tool for thinking, not a result in itself: it does not prove themes are well supported.
Memos, Themes, and the Audit Trail
Memos are short analytical notes written during coding. A memo might record why a passage was coded in a surprising way, why two codes were merged, what a pattern might mean, or what to check next. Codes label material, while memos record thinking about material. Over a project, memos become a diary of decisions, helping a researcher remember why an early idea was set aside and helping a team discuss interpretations without relying on memory alone.
Themes are the next level up from codes. In thematic analysis, a theme is a pattern across the data set that helps answer the research question. Themes are developed through analysis, not simply found by counting codes. The British Columbia guide stresses returning to raw data throughout, so themes do not drift away from what participants actually said. Reviewing themes means checking whether coded extracts support the theme, whether it works across the whole data set, and whether themes should be collapsed, split, or renamed. Defining a theme means writing what it covers, what it does not cover, and how it relates to other themes.
An audit trail ties these pieces together: original material, codebook revisions, memos, queries run, and notes on team decisions. A program helps by storing much of this trail in one project file and allowing exports of coded material, code definitions, and memos. The researcher still needs clear file names, dated versions, a short project log, and backups stored separately from the working copy, so the path to a theme can be reconstructed if a team member leaves or a reviewer asks how it was reached.
Program Categories in General Terms
Programs differ in how they are installed, how teams work in them, and how they are licensed, and those differences often matter more than any single feature. The categories below describe common patterns. They are not rankings, and no category is right for every project.
Desktop programs are installed on one computer and store the project locally or on a drive the researcher controls. They often handle large projects and media files well, and can suit sensitive material where local control matters. Their limit is teamwork: sharing a desktop project file by email or shared drive can create version conflicts unless the team agrees on a strict checkout and merge routine.
Web based programs run in a browser and store the project on the provider server, with collaboration as a central feature. They suit teams spread across locations and short timeline projects, since several researchers can work in the same project without passing files back and forth. Their limits concern data control, internet access, and institutional rules: check where data is stored, who can access it, how exports work, and whether the service meets the rules for the data in question.
Open source programs are distributed under a license that allows use, study, change, and sharing under stated conditions. University guides list open source examples that run on major operating systems and support text coding, highlighting, tagging, and export of projects, highlights, documents, and codes. They can suit small projects, teaching, and limited budgets. Their limits vary: some are designed for single users, some support fewer media types, and support may come mainly from documentation and community discussion rather than a commercial support desk. Judge them from the license and current documentation, not from a general label.
General purpose tools, including word processors, spreadsheets, and note taking programs, are sometimes adapted for qualitative work. They can work for very small projects or for teaching coding logic. Their limits appear quickly as material grows: retrieval becomes manual, code hierarchies become hard to maintain, and an audit trail must be built by hand. Mixed methods support is a further distinction: some programs also support survey variables and case attributes, so coding can be compared across age groups, sites, or survey responses. Those comparisons should be read as qualitative patterns, not statistical proof, unless quantitative analysis has been done separately with appropriate methods.
Examples Named in University Guides, Without Endorsement
University library guides name a recurring set of programs, and knowing why those names appear helps, without treating the list as a recommendation. Johns Hopkins University library material describes NVivo and ATLAS.ti as major commercial products with a wide range of qualitative techniques, notes MAXQDA and cloud based Dedoose as other applications, and describes organizing unstructured text, audio, video, and image data with coding, tagging, and annotations that can be queried, filtered, and interrelated. The University of California San Diego guide lists ATLAS.ti, NVivo, MAXQDA, and Dedoose as licensed programs with student pricing options, and lists Taguette and QualCoder as free and open source options. Johns Hopkins also notes that Taguette is a free open source tool for text data that can run on a local device or a server, and that QualCoder is a free open source tool for text and video analysis for single users, with fewer features than commercial products but possibly adequate for smaller projects.
Those descriptions are a starting map, not a verdict. Pricing, trial versions, institutional access, and feature sets change, and a guide written for one university may reflect licenses not available elsewhere. Check current vendor documentation and the current institutional offer, and test with real project material, rather than choosing from a list alone.
Working With Teams, Security, and Sensitive Material
Teamwork changes software demands more than any other factor. A solo researcher mainly needs reliable coding, retrieval, and export. A team also needs a shared codebook, consistent coding, a way to resolve disagreements, and a record of who changed what. Some programs support simultaneous work in a shared project, with roles and permissions controlling who can code, edit the codebook, or export data. Others support teamwork by merging separately coded copies, which requires a planned routine for comparing codes, discussing differences, and producing one agreed version.
Agreement work is often misunderstood. Agreement numbers can be calculated in some programs, but a high figure does not by itself prove codes are meaningful, and a low figure does not by itself prove analysis is weak. The value lies in discussion: why did two researchers code the same passage differently, was the definition vague, was the passage genuinely ambiguous, or did one researcher notice context the other missed? Agree in advance how disagreements will be resolved, by discussion to consensus, by a third reviewer, or by refining the codebook and recoding, and record that agreement in a memo.
Qualitative material often contains personal stories, health details, or workplace experiences, even when names have been removed, so software choice is also an ethics and data protection decision. Before importing material, check what consent participants gave, what ethics approval allows, and what institutional rules require for storage, sharing, and retention. Anonymize before import where possible, with identifying details removed or replaced consistently, and keep any linking key apart from coded material. A desktop project on an encrypted device under researcher control may suit highly sensitive material, provided backups are also encrypted. A web based project may suit collaboration, but check provider terms, data location, access controls, and approval for the data type. Johns Hopkins guidance illustrates this caution, noting a secure desktop environment as the recommended platform for sensitive data. Password protection alone does not guarantee that a program meets ethics or institutional requirements.
Import, Queries, and Visualization
Prepare material before import. Transcripts should use consistent speaker labels and formatting, and file names should identify a participant or document without revealing personal details. A scanned PDF that is only an image may need text recognition before its text can be coded reliably. Audio and video files should be checked for length, format, and transcript linking, and large media files should be tested before a full project is built. The University of California San Diego guide notes imports for one open source tool of PDFs, Word documents, text files, HTML, EPUB, MOBI, Open Documents, and Rich Text Files, with highlighting and tagging of words, sentences, or paragraphs. Other programs support different combinations, so a pilot import with a few real files will reveal lost formatting, broken paragraph breaks, or media that will not link. After import, create document groups, draft a codebook, and code a small subset first.
Once material is coded, queries turn the project into an analytical tool. A simple query lists all passages under one code. A combined query lists passages where two codes overlap, for example cost worry and travel difficulty, which may reveal a linked barrier. A comparison query lists coding by group. A text search finds passages containing a word or phrase, but results still need human review, since the same word can mean different things in different contexts. Matrices show codes against participant groups, helping a researcher notice absence as well as presence: a theme in every group except one raises a question worth investigating. Visualizations such as code maps, networks, and word clouds can help exploration, but they are not evidence on their own. A word cloud shows frequency, not meaning, and a network diagram shows links the researcher defined, not links the data proved.
Interoperability, Costs, and Comparing Options
Projects often outlive a single program version, team, or institution, so export deserves attention early. The REFI-QDA Standard was developed to allow exchange of processed qualitative data between programs that support it. MAXQDA documentation describes it as an open standard enabling users to exchange processed data between programs, and notes it makes exchange possible between packages supporting the XML exchange format. The same documentation warns that exchange is limited, because the standard does not support all elements from all programs, project logics differ, and complex projects can never be transferred one to one. It is therefore not suitable for teamwork where researchers work on the same project data with different programs at the same time. Test a round trip export and import with a small pilot project before relying on it, and keep readable exports alongside the native project file.
Cost models vary and should be compared on total project cost, not a single headline figure. Some programs are free and open source, with time costs for setup, learning, and support. Some commercial programs offer student licenses, trial versions, institutional licenses, and monthly or annual subscriptions, with different limits for individuals, teams, and cloud collaboration. Institutional access can change the picture entirely, since a university may provide a program on library computers, through a secure desktop, or under a site license. Features and pricing change, and must be checked with the vendor at the time of decision. A trial may limit project size, media support, or exports. A student license may end when enrollment ends. Before committing, confirm license terms, renewal terms, export options on exit, data storage location, and support route, and keep a dated note of what was confirmed.
This guide does not recommend a single program, so compare options with a structured pilot. Write down the research question, material types, volume, team size, data sensitivity, institutional rules, and budget and time for learning. Then test two or three plausible options with the same small pilot data set and coding task. Check import, coding and codebook support, retrieval, teamwork rules, memo and export options, accessibility, learning time, total cost, and exit: how the full project can be exported if the team stops using the program.
Common Mistakes
Coding too finely at the start is common: dozens of narrow, overlapping codes later prove hard to group into themes. A smaller set of well defined codes, refined through discussion, usually works better. Coding only for themes that confirm an early idea, while skipping passages that complicate the picture, is another risk. Search deliberately for counterexamples and code them with the same care. Treating a quotation as proof without context can mislead, so read the full passage and the question that prompted it. Letting a codebook drift without dated notes means the same code can mean different things at the start and end of a project. Relying on a single project file with no backup, or on a shared drive where two versions diverge, invites recovery work. Finally, importing identifiable material before anonymization and consent checks are complete is hard to undo, so use a pre import checklist covering consent, anonymization, file naming, and storage approval.
Frequently Asked Questions
What is computer assisted qualitative data analysis software?
It is software that helps researchers organize, code, retrieve, compare, and document qualitative material such as transcripts, field notes, documents, images, audio, and video. Common short forms are QDA software, QDAS, and CAQDAS. It assists analysis; it does not interpret material or choose a method on its own.
Do I need dedicated software for a small qualitative project?
Not always. A few short documents can be handled with careful manual coding in a word processor or spreadsheet. Dedicated software becomes more valuable as volume, formats, team size, or comparison needs grow.
What is coding in qualitative analysis?
Coding means attaching short labels to passages that share a meaning, so related material can be retrieved together. Codes sit in a codebook with definitions and examples. Themes are broader patterns built from codes and checked against the full data set before reporting.
What is the difference between inductive, deductive, and hybrid coding?
Inductive coding builds codes from the data itself. Deductive coding starts from an existing theory or framework. Hybrid coding starts with some preset codes and adds new ones as patterns appear. The best approach depends on the research question.
Can these programs analyze audio and video, or only text?
Many support audio and video as well as text, often by linking transcripts to time points or coding regions of an image. Support varies by program and version, so test actual files before choosing.
Can a team work in the same project at the same time?
It depends on the program. Some web based programs support simultaneous work with roles and permissions. Some desktop programs support teamwork by merging separately coded copies under a planned routine. Agree on version control and disagreement resolution before coding starts.
Is open source qualitative software good enough for serious research?
It can be, depending on the project. University guides list open source tools supporting text coding, highlighting, tagging, and export of projects and codes. Some have fewer features or are designed for single users, so judge fit by pilot testing, not by price alone.
What is REFI-QDA, and why does it matter?
REFI-QDA is an open standard for exchanging qualitative projects between programs that support it, using an XML based format. Transfers are not always complete, since programs differ in features and logic, so test an export and import with a pilot project and keep readable exports alongside the native file.
How much do these programs cost?
Costs vary widely. Some tools are free and open source. Some commercial programs offer student licenses, trial versions, institutional licenses, and monthly or annual subscriptions. Features and pricing change, so check current terms with the vendor and, where relevant, the institution providing access.
How do I keep sensitive interview material safe in these programs?
Check consent and ethics approval before import, anonymize where possible, limit access, confirm storage location and provider terms for web based programs, keep encrypted backups where required, and check quotations and exports for identifying context before sharing.
Will the software find themes for me?
No, not in the sense that matters for research quality. Programs can retrieve coded material, show overlaps, and visualize patterns, but themes are interpretive patterns developed by the researcher through reading, coding, reviewing, and writing. Automated suggestions still need human review and documentation.
What should I check before choosing a program?
Check import for formats actually used, coding and codebook support, retrieval and comparison, teamwork rules, memo and export options, data storage and security, learning time, total cost including team size, and how the full project can be exported on exit. A short pilot test with real material in two or three options usually reveals more than a feature list alone.
Sources & references
- University of California San Diego, Data Analysis: Qualitative Analysis, LibGuides. Notes that UC San Diego does not provide campus wide access or licenses to any qualitative data analysis software, lists licensed programs with student pricing, and lists free open source options including Taguette import formats and QualCoder cross platform support. Opened in full on 31 October 2026 at https://ucsd.libguides.com/data-analysis/QDA
- Johns Hopkins University, What is QDA Software? Sheridan Libraries, 6 December 2021, updated 9 December 2025. Describes NVivo and ATLAS.ti, MAXQDA, and cloud based Dedoose, and describes organizing unstructured text, audio, video, and image data with coding, tagging, and annotations. Opened in full on 31 October 2026 at https://www.library.jhu.edu/news/2021/12/what-is-qda-software/
- Johns Hopkins University, Qualitative Data Analysis Software, LibGuides. Describes Dedoose cloud collaboration and monthly per user pricing in general terms, MAXQDA, Taguette, and QualCoder for single users. Opened in full on 31 October 2026 at https://guides.library.jhu.edu/c.php?g=941489&p=6786013
- University of Delaware, Qualitative Data Analysis, LibGuides. Defines qualitative data as essentially any data that is not numbers, and describes collecting data through interviews, observations, documents, and fieldwork, and reviewing and coding data through inductive, deductive, and hybrid approaches. Opened in full on 31 October 2026 at https://guides.lib.udel.edu/qda
- University of British Columbia, Qualitative Research 101, Rural Health Services Research Network of BC. Summarizes thematic analysis in six steps, from familiarizing with data and generating initial codes through searching for themes, reviewing themes, defining and naming themes, and producing the report. Opened in full on 31 October 2026 at https://rhsrnbc.med.ubc.ca/rural-health-research/research-resources/qualitative-research-101/
- MAXQDA, Export and Import REFI-QDA Projects, help documentation. Describes the REFI-QDA Standard as enabling interoperability between qualitative data analysis software programs, lists components included and not included in an exchange, and warns that complex projects can never be transferred one to one. Opened in full on 31 October 2026 at https://www.maxqda.com/help/report-and-export/export-and-import-refi-qda-projects
