Choosing the Right File Format for RNA-Seq Data

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-10

The difference that matters most is whether an RNA-seq file format carries raw read evidence, alignment coordinates, or summarized expression, so the practical rule is to keep FASTQ for raw reads, BAM or CRAM for alignments, and a plain count matrix for statistics, adding specialized formats only when a tool demands them.

Bioinformatics file formats are contracts between tools. A format defines what information survives from one step to the next and what must be recomputed later. RNA-seq projects move through several contracts: raw reads, quality control, alignment, annotation, quantification, and downstream modeling. Each stage has formats that fit well and formats that create avoidable work.

No single format is best for every stage. The useful question is narrower. Which format preserves the information the next step needs, at a size and compatibility level that the project can manage? The answer changes when the next step is differential expression, genome annotation, variant calling, single-cell clustering, fusion detection, or long-read signal analysis. The sections below compare the main RNA-seq file format options on the criteria that decide real pipelines.

RNA-seq file formats sit at four layers

The first layer is raw sequence. FASTQ and FASTA live here. FASTQ stores reads plus per-base quality scores. FASTA stores sequence only. Raw reads are the primary evidence for a sequencing experiment, so this layer deserves careful archive choices.

The second layer is alignment. SAM, BAM, and CRAM store where reads mapped. BAM is the de facto standard for sequence alignment in many RNA-seq workflows [1]. SAM is the text representation of the same alignment model, and it has long been a standard input for tools that process mapped reads [2]. BAM is a regular input for pipelines that need spliced alignments, including genome annotation workflows such as BRAKER1 [3].

The third layer is annotation and interval data. GTF and GFF3 describe genes, transcripts, and exons. BED, bedGraph, and BigWig describe genomic intervals and signal tracks. These formats do not store reads. They tell tools where features are or how much signal lies over a region. APAtizer, for example, accepts BAM, htseq output, and DaPars bedGraph files for alternative polyadenylation analysis [4].

The fourth layer is summary and downstream data. Count matrices, normalized expression tables, H5AD files, VCF and GVCF files, and model exchange formats live here. A quantification matrix has one row per gene or transcript and one column per sample. VCF and GVCF files describe genetic variants. H5AD stores single-cell expression and annotations. These formats are efficient for their intended analyses, but they discard read-level information.

A review of differential expression analysis notes that RNA-seq pipelines involve many data types and file formats, with a wide variety of tools applied alone or together [5]. That variety is normal. The problem is not format diversity itself. The problem is choosing a format that loses information too early or forces a conversion that changes meaning.

The main RNA-seq file format options at a glance

The table summarizes the main RNA-seq file format pros and cons. It is organized by the information each format carries, not by popularity. The best RNA-seq file format for a given project is the row that matches the next analysis step while keeping the raw evidence recoverable.

Format	What it stores	Typical RNA-seq stage	Main strengths	Main limits	Best use
FASTQ	Read sequence plus per-base quality scores	Raw reads, quality control, trimming, alignment input	Keeps base quality and raw evidence. Widely accepted by aligners and QC tools [6]	Large. Text format needs compression. Poor as a final analysis table	Primary raw-read archive and reanalysis
FASTA	Sequence only, with no per-base quality	Reference genome, reference transcriptome, assembled transcripts, exon sequences	Simple, compact, universal for sequence comparison	No quality scores. Not suitable as the only raw-read record for Illumina RNA-seq	References, assemblies, predicted sequences
SAM	Text alignment records with flags, coordinates, CIGAR, sequence, and optional tags	Small alignment inspections, debugging, tool interchange	Human readable. Same alignment model as BAM [2]	Very large for real RNA-seq libraries	Small examples, debugging, format conversion
BAM	Binary compressed alignment records, usually indexed	Spliced alignment, counting, visualization, annotation, variant input	Compact compared with SAM. Broad tool support. Standard for alignment data [1]	Larger than CRAM. Requires sorting and indexing for many operations	Working alignment format for bulk RNA-seq
CRAM	Reference-based compressed alignment records	Long-term alignment archive and large cohort storage	Smaller than BAM when the reference is available	Depends on the reference. Tool support is narrower than BAM	Archival alignments after active analysis
GTF or GFF3	Gene, transcript, and exon coordinates with attributes	Read counting and quantification	Connects reads to known features	Easy to use the wrong annotation version or coordinate convention	Feature counting with a matched reference annotation
BED, bedGraph, BigWig	Intervals, per-region values, or indexed signal tracks	Coverage, peak-like summaries, splicing or polyadenylation signals	Compact summaries for genome browsers and region-level analysis	Not a replacement for read alignments or raw counts	Signal tracks and region summaries
Count matrix, TSV or CSV	Integer or normalized expression values by gene and sample	Differential expression and downstream statistics	Small, portable, easy to inspect	Loses read-level and isoform-level evidence	Downstream expression analysis
H5AD	Single-cell expression matrix plus cell and gene annotations	Single-cell RNA-seq analysis	Fits AnnData-based tools and large cell-by-gene matrices	Not a bulk RNA-seq interchange format	Single-cell RNA-seq working data
VCF or GVCF	Variant calls or genotype likelihood records	RNA-seq variant calling and joint genotyping	Standard for variant exchange and cohort genotyping	Not an expression format. RNA-specific artifacts need care	Variant calling projects
POD5 or SLOW5	Nanopore raw signal data	Long-read and direct RNA nanopore workflows	Preserves raw signal for basecalling and reanalysis	Large and instrument-specific. Needs nanopore-aware tools	Nanopore signal archive and processing

Raw read formats: FASTQ vs FASTA

FASTQ

FASTQ is the standard raw-read format for Illumina RNA-seq and many other short-read platforms. Each read has four lines: a header, the nucleotide sequence, a separator, and a string of ASCII characters that encode per-base quality scores. The quality string is usually Phred+33, where a higher character value means lower probability of a base-calling error.

The quality scores matter. Adapter trimming and quality filtering use them. Aligners use them. A low-quality base at the end of a read is not the same evidence as a high-quality base in the middle. FASTQ preserves that distinction. Grape, an RNA-seq analysis pipeline, accepts raw sequencing reads in FASTA or FASTQ format, and it also accepts prealigned SAM or BAM input [6]. That flexibility is useful, but FASTQ remains the richer raw-read record when quality scores exist.

FASTQ files are commonly compressed with gzip to save space. Paired-end libraries produce two synchronized FASTQ files, often named with R1 and R2. The read headers carry pairing information, and tools expect the two files to stay in the same order. A common pipeline step is to download raw data from NCBI GEO or SRA, run FastQC, trim adapters and low-quality bases with Trimmomatic, align with HISAT2 or BWA, and use Samtools for alignment handling and format conversion [7]. That workflow starts and ends with different formats by design.

FASTQ pros are clear. It is the closest practical record of the raw sequencing evidence. It supports reanalysis with new aligners, new trimming rules, or new quantification methods. It is accepted by quality-control tools and aligners. Its limits are equally clear. It is large, it is not indexed for random access, and it says nothing about genomic origin or expression level. FASTQ is a starting point, not an analysis result.

FASTA

FASTA stores sequence records without per-base quality scores. It is the standard format for reference genomes, reference transcriptomes, assembled transcripts, protein sequences, and many predicted feature sequences. ChopStitch, a tool for exon annotation and splice graph construction, outputs a FASTA file containing putative exons [8]. In that setting, FASTA is the right container because the result is a set of sequences, not a set of base-called reads with quality evidence.

FASTA is also common for references used during alignment and quantification. A genome FASTA is the coordinate system against which BAM files are interpreted. A transcriptome FASTA is the target for some quantification workflows. A protein FASTA is used in annotation and functional analysis. These uses are different from raw-read storage, even though the file extension looks simple.

The main limit of FASTA is information loss when it is used as a substitute for FASTQ. Converting FASTQ to FASTA discards quality scores. It also discards any quality-based information that a downstream tool might need. For raw Illumina RNA-seq, FASTA is not an adequate sole archive unless quality scores were never produced or are stored elsewhere. For a reference or an assembled transcript set, FASTA is often the correct and compact choice.

FASTQ vs FASTA: what changes when quality disappears

The FASTQ vs FASTA distinction is not cosmetic. FASTQ answers two questions: what was the sequence, and how confident was the base caller? FASTA answers only the first question. For raw RNA-seq reads, the confidence information has real uses in trimming, alignment, and quality control. For a reference genome or a set of predicted exons, quality scores are not part of the biological object being represented.

Use FASTQ for raw reads that will be quality checked, trimmed, aligned, or reanalyzed. Use FASTA for reference sequences, transcript assemblies, predicted coding sequences, and other sequence-only products. If a tool accepts either format, check whether it silently ignores quality scores before deciding that FASTA is an acceptable substitute.

Alignment formats: SAM, BAM, and CRAM

SAM

SAM, the Sequence Alignment/Map format, is a text format for aligned reads. A SAM record includes the read name, a bitwise flag, the reference name, the leftmost mapping position, mapping quality, a CIGAR string that describes insertions, deletions, and clipping, the read sequence, the read quality string, and optional tags. SAM is readable and useful for debugging a small region or checking how a aligner represented a splice junction.

SAM is also the conceptual parent of BAM. BM-Map, a tool for allocating multireads in RNA-seq data, takes SAM as its standard input and adds mapping probabilities to the original records [2]. That design shows the value of SAM as a transparent interchange format. The same design also shows its weakness. A real RNA-seq library can produce hundreds of millions of reads over many samples. A text alignment file at that scale is huge and slow to parse.

Use SAM for small test sets, for inspecting alignments, and for understanding tool behavior. For routine storage and processing of bulk RNA-seq alignments, BAM or CRAM is the practical choice.

BAM

BAM is the binary compressed version of SAM. It is the working alignment format for most bulk RNA-seq pipelines. BAM is described as the de facto standard file format for sequence alignment, and R tools such as rbamtools provide reading, writing, subsetting, and alignment-depth plotting from BAM files [1]. It preserves alignment coordinates, CIGAR operations, read sequence, base qualities, and optional tags, so it can support counting, visualization, variant calling, and splicing analysis.

BAM is not just a compressed SAM in everyday use. It is usually coordinate sorted and indexed. The index, commonly .bai, allows tools to fetch reads from a genomic region without reading the entire file. That matters for genome browsers, region-level counting, and variant calling. An unsorted BAM is fine for some streaming operations but poor for random access.

BAM is also the input that many specialized RNA-seq tools expect. BRAKER1 requires a genome assembly file and a BAM file with spliced alignments of RNA-seq reads to the genome [3]. APAtizer accepts BAM, htseq output, and DaPars bedGraph files [4]. These are different downstream questions, but both rely on the alignment record that BAM preserves.

BAM pros include broad compatibility, a rich alignment record, and mature indexing. BAM cons are size and complexity. It is larger than CRAM, and it can accumulate duplicate reads, secondary alignments, and other records that need filtering. A BAM file is not an expression table. Counting still requires an annotation and a counting rule.

CRAM

CRAM is a reference-based compressed alignment format. It stores reads relative to a reference sequence, so it can be much smaller than BAM when the same reference is available at both write and read time. CRAM is useful for long-term alignment archives and large cohorts where storage and transfer costs matter. The trade-off is dependency. A CRAM file without the right reference is not self-contained in the way a BAM file is.

CRAM is not a universal replacement for BAM in RNA-seq. Some tools accept BAM but not CRAM. Some pipelines produce BAM at the alignment step and only convert to CRAM for cold storage. The practical pattern is to keep BAM during active analysis and create CRAM archives when the project has settled on a reference and a retention policy. Check tool support before making CRAM the only aligned copy, especially for RNA-seq tools that expect spliced BAM input [3].

What aligned files do and do not tell you

An aligned file tells you where reads mapped. It does not tell you which gene was expressed. Gene assignment requires annotation coordinates, a transcript model, and a counting rule for reads that overlap multiple features. A BAM file can therefore support several different expression estimates, and those estimates can change when the annotation changes.

Aligned files also do not replace raw reads. A BAM may contain only reads that passed alignment filters. If the aligner or filtering step was wrong, going back to FASTQ is the cleanest correction. That is why many robust pipelines archive both FASTQ and BAM.

Annotation and signal formats

GTF and GFF3

GTF and GFF3 are text formats for genomic features. They describe genes, transcripts, exons, and other elements with coordinates and attributes. RNA-seq counting tools use these files to decide which reads belong to which feature. Grape requires the genome of the species and the corresponding gene and transcript annotation [6]. That requirement is typical. Without a matched annotation, an aligned BAM cannot be converted into gene-level counts.

GTF and GFF3 look similar but differ in attribute syntax and in how hierarchical relationships are represented. GTF is common in RNA-seq counting workflows. GFF3 is a more general feature format used across genome annotation projects. The most common practical error is using an annotation from a different genome assembly or a different gene identifier namespace than the one used for alignment.

BED, bedGraph, and BigWig

BED stores genomic intervals. It is a compact way to represent exons, introns, regions of interest, or regions with a measured value. BED coordinates are zero-based and half-open, while GTF and GFF3 coordinates are one-based. Mixing those conventions shifts every feature by one base. The shift is small enough to survive a quick inspection and large enough to break careful region analysis.

bedGraph stores a value for each interval, often coverage or signal. APAtizer handles DaPars bedGraph files for alternative polyadenylation analysis [4]. BigWig is an indexed binary signal format for genome browsers and region queries. It is efficient for sharing coverage tracks, but it is not a substitute for BAM when read-level evidence is needed.

Use BED and bedGraph for region-level summaries and signal tracks. Use BAM or CRAM when the question depends on individual reads, splice junctions, or base-level alignment details.

Specialized graph and exchange formats

Some RNA-seq analyses produce formats that are specific to a biological question. ChopStitch represents transcript isoforms as splice graphs in DOT output format [8]. Fusion detection tools produce candidate fusion calls, and MetaFusion standardizes individual caller results by converting them into a Common Fusion Format before annotation, merging, and ranking [9]. These formats are not general-purpose RNA-seq containers. They are outputs of specific analysis steps, and they should be treated as results rather than as primary data.

Custom outputs can be useful and still be hard to integrate. A framework for combining heterogeneous genomic data notes that analysis tools often produce custom outputs in non-standard file formats, which complicates integration [10]. The lesson is not to avoid specialized formats. The lesson is to keep the standard upstream data that generated them.

Quantification and downstream formats

Count matrices and normalized matrices

A count matrix is a table with genes or transcripts as rows and samples as columns. The values are counts of reads or fragments assigned to each feature. A TSV or CSV count matrix is small, portable, and easy to inspect. It is the natural input for differential expression tools. APAtizer accepts htseq output as one of its input formats [4], which reflects the common role of gene-level count tables in RNA-seq analysis.

Raw integer counts are the right starting point for count-based differential expression. Normalized values such as TPM and FPKM are useful for describing expression and for some visualizations, but they are not a substitute for raw counts in methods that model count variability. A normalized matrix has already divided out library size and feature length, so the original sampling variance is no longer represented in the same way.

Keep the raw count matrix, the sample metadata, and the annotation version together. A count table without sample metadata is hard to reuse. A count table without the annotation version is hard to audit. A count table without the upstream BAM or FASTQ is hard to correct when a quantification rule changes.

H5AD and HDF5 for single-cell RNA-seq

H5AD is the file format used by AnnData, a data structure common in single-cell RNA-seq analysis. It stores an expression matrix plus cell-level and gene-level annotations. QCatch exports processed single-cell results in H5AD so they can move into downstream analysis tools [11]. H5AD is a good fit for single-cell work because a single-cell dataset has many more cells than a bulk RNA-seq dataset has samples, and the matrix plus annotations need to travel together.

HDF5 is a general hierarchical data format used for large arrays and on-disk data access. The mbkmeans package for single-cell clustering supports on-disk data representations such as HDF5, which avoids loading all data into memory at once [12]. That is a practical advantage for datasets with very large cell counts. H5AD and HDF5 are not natural interchange formats for bulk RNA-seq differential expression. Use them for single-cell objects and large array-backed analyses.

VCF and GVCF for RNA-seq variants

VCF stores variant calls. GVCF stores genotype likelihoods and genome annotations for individual samples, which can then be joint genotyped across samples. Brouard and colleagues evaluated a GATK joint genotyping workflow for RNA-seq data and used one GVCF file per sample before joint genotyping [13]. In that design, the GVCF is an intermediate that preserves genotype likelihood information and supports cohort-level calling.

VCF and GVCF are not expression formats. They are relevant when an RNA-seq project asks a DNA-level question, such as variant discovery or allele-specific analysis. RNA-seq variant calling has extra complications from splicing, RNA editing, and expression-dependent coverage. The file format choice does not remove those biological complications. It only gives the variant caller a standard record to work with.

Fusion and model exchange formats

Fusion detection is a specialized RNA-seq application with a fragmented tool landscape. MetaFusion converts results from multiple fusion callers into a Common Fusion Format, then annotates, merges, filters, and ranks the calls [9]. A common format makes ensemble calling possible because it removes caller-specific output differences.

Model exchange formats appear at the far downstream end. Augusta, a package for gene regulatory network and Boolean model inference from expression data, provides models in SBML format for further editing [14]. SBML is not an RNA-seq read or expression format. It is a model exchange format that sits after network inference. That distinction matters when deciding what to archive. Keep the expression matrix and the model file, but do not confuse the model with the primary data.

Choosing the right file format for RNA-seq data: criteria that decide real work

The choice should follow the next operation, not a general preference for one extension. Six criteria cover most decisions.

Information content. Does the next step need base qualities, alignment coordinates, exon structure, raw signal, or only summarized counts? FASTQ preserves qualities. BAM preserves alignments. A count matrix preserves neither.
Tool compatibility. Check the actual input requirements of the tools in the pipeline. BRAKER1 expects BAM with spliced alignments [3]. APAtizer can take BAM, htseq output, or bedGraph [4]. QCatch exports H5AD [11]. A format that is elegant in theory but unsupported by the next tool creates work.
Size and compression. FASTQ compresses well with gzip. BAM is binary and compact relative to SAM. CRAM can shrink alignments further when a reference is available. For nanopore signal data, the choice between POD5 and SLOW5 has measurable performance consequences. Binary SLOW5 showed superior sequential and random-access reading on most systems, faster and cheaper basecalling and other analysis, and no case where POD5 reading was significantly faster than BLOW5 [15].
Random access. Many RNA-seq questions are regional. Indexed BAM, indexed BigWig, indexed VCF, and indexed H5AD or HDF5-backed data allow targeted reads without loading everything. An unindexed text file forces full scans.
Loss and provenance. Every conversion should be documented. FASTQ to FASTA loses quality. BAM to counts loses read-level evidence. Normalized matrices lose raw count variance. A pipeline that keeps only the most summarized output makes later correction harder.
Archive versus working format. A working format is optimized for the current analysis. An archive format is optimized for durability, size, and future reuse. It is reasonable to work in BAM and archive in CRAM. It is not reasonable to discard FASTQ before the project has a stable, validated quantification.

These criteria explain why "best" depends on stage. The best RNA-seq file format for raw reads is FASTQ when quality scores exist. The best working format for spliced alignments is usually BAM. The best downstream format for bulk differential expression is usually a raw count matrix. The best format for single-cell analysis may be H5AD. A single project may need all of these.

Worked scenarios

Bulk mRNA differential expression

A typical bulk mRNA workflow starts with paired-end FASTQ files. Run FastQC, trim adapters and low-quality bases, align to a reference genome with a splice-aware aligner, and write a coordinate-sorted BAM. Use Samtools for sorting and indexing. Count reads against a matched GTF annotation with a tool such as featureCounts or HTSeq, then export a raw count matrix as TSV. The streamlined protocol described by Mohit and colleagues follows this general path with SRA Toolkit, FastQC, Trimmomatic, BWA or HISAT2, Samtools, and Subread, then moves to normalization and differential expression [7].

The files to keep are FASTQ, BAM, the count matrix, the annotation version, and the sample sheet. The count matrix is the analysis input. The BAM supports inspection and recounting. The FASTQ supports realignment with a different method.

Genome annotation with RNA-seq evidence

Genome annotation uses RNA-seq alignments as evidence for exon and gene structure. BRAKER1 requires a genome assembly file and a BAM file with spliced alignments of RNA-seq reads to the genome [3]. In this scenario, BAM is not a temporary byproduct. It is the evidence file that connects reads to splice junctions. The annotation output may then be represented as GTF or GFF3.

The main format risk is using an alignment that is not splice-aware or a BAM that has been filtered so aggressively that junction evidence is lost. A sorted, indexed BAM with clear alignment parameters is more useful than a heavily filtered alignment with unknown provenance.

Variant calling from RNA-seq

A variant-calling project may start with the same BAM files used for expression analysis. Per-sample calling can produce GVCF files, and joint genotyping then uses those GVCFs to call variants across samples [13]. The output is VCF. In this scenario, BAM is the alignment input and GVCF or VCF is the variant record.

RNA-seq variant calls need separate handling from DNA variant calls because expressed regions have uneven coverage and because RNA processing affects alignment. The format choice is standard. The interpretation is not.

Single-cell RNA-seq

Single-cell workflows produce a cell-by-gene expression matrix plus cell annotations. After quantification, a common downstream format is H5AD, which QCatch exports for single-cell analysis [11]. For very large datasets, HDF5-backed on-disk storage allows tools such as mbkmeans to work without loading the whole matrix into memory [12].

The single-cell format decision is driven by the analysis ecosystem. H5AD is useful when the downstream tools are AnnData-aware. A plain matrix plus separate metadata is more portable but less self-describing. Keep the raw count matrix and the cell metadata even when H5AD is the working object.

Nanopore long-read and direct RNA sequencing

Nanopore RNA-seq adds a raw signal layer. Oxford Nanopore instruments can store signal data in POD5, while SLOW5 is an open-source alternative to the older FAST5 format. A comparative evaluation found that binary SLOW5 (BLOW5) was superior during sequential and random-access reading on most systems, led to faster and cheaper basecalling and other analysis, and had no case where POD5 reading was significantly faster than BLOW5 [15]. BLOW5 writing was also highly parallelizable, which matters for data acquisition.

The practical pattern is to preserve raw signal in the chosen nanopore format, keep base-called reads in FASTQ, and keep alignments in BAM. Convert only after confirming that the downstream basecaller and analysis tools support the chosen signal format.

Fusion detection

Fusion detection may combine multiple callers. MetaFusion converts individual caller results into a Common Fusion Format, then annotates, merges, filters, and ranks candidates [9]. The upstream data are usually BAM files or transcript-level quantifications. The Common Fusion Format is a result format, not a replacement for the alignment files.

Common Mistakes and Limitations

Using FASTA as the only raw-read archive for Illumina RNA-seq. FASTA drops per-base quality scores. Use FASTQ when quality scores exist, and reserve FASTA for references, assemblies, and sequence-only products.

Confusing BAM with an expression table. BAM stores alignments. It does not assign reads to genes without an annotation and a counting rule. Count first, then analyze counts.

Mixing annotation versions. A GTF from one genome release can disagree with a BAM aligned to another release. Record the genome assembly, annotation release, and gene identifier namespace with every count matrix.

Mixing zero-based and one-based coordinates. BED is zero-based and half-open. GTF and GFF3 are one-based. A one-base shift can change overlap results without causing an obvious error.

Compressing BAM again with gzip. BAM is already compressed. A file named .bam.gz is usually a sign that a pipeline expects the wrong input. Use BAM or CRAM as appropriate.

Discarding FASTQ too early. A count matrix is convenient, but it cannot be realigned. Keep raw FASTQ until the project has a stable, documented quantification and a retention plan.

Treating normalized values as raw counts. TPM and FPKM are useful descriptors. They are not interchangeable with integer counts in count-based differential expression.

Assuming a specialized format is portable. Custom outputs can complicate integration with other tools [10]. Keep the standard upstream data that generated the specialized output.

Forgetting indexes. A BAM without an index is slow for region queries. A VCF without an index is slow for region queries. A BigWig without an index is not a BigWig in the practical sense. Build the index as part of the pipeline.

Choosing a format by file size alone. A smaller file that loses quality scores or read-level evidence is not automatically better. Match the format to the question and keep an archive copy of the richer data.

Assuming CRAM is always safe to substitute for BAM. Some RNA-seq tools require BAM input [3]. Check support before converting the only alignment copy to CRAM.

Using a single-cell format for bulk data. H5AD and HDF5 are well suited to single-cell matrices [11][12]. A bulk count matrix in TSV is simpler and more portable for bulk differential expression.

Leaving out sample metadata. A count matrix without sample groups, batch labels, and library details is hard to reuse. The metadata file is part of the data format decision.

The limitations are practical. File formats do not fix poor library preparation, reference mismatch, or ambiguous gene assignment. They do make those problems easier or harder to detect. A well-chosen format keeps the evidence needed to audit the step that follows.

Frequently Asked Questions

Is there a best RNA-seq file format?

No single format is best for all stages. FASTQ is best for raw reads with quality scores, BAM is the usual working format for alignments, and a raw count matrix is best for bulk differential expression.

What is the difference between FASTQ and FASTA?

FASTQ stores sequence plus per-base quality scores. FASTA stores sequence only. Use FASTQ for raw reads that need quality control or alignment, and use FASTA for references, assemblies, and sequence-only products.

Should I keep BAM files after counting reads?

Yes, keep BAM files when storage allows. BAM preserves alignment evidence that a count matrix discards, so it supports inspection, recounting, and alternative quantification.

Is CRAM better than BAM for RNA-seq?

CRAM is smaller when the reference is available, but BAM has broader tool support. Use BAM during active analysis and consider CRAM for archival storage after checking that downstream tools accept it.

What format should I use for single-cell RNA-seq?

H5AD is a common working format for single-cell RNA-seq because it stores the expression matrix with cell and gene annotations. Keep a raw count matrix and metadata as well.

Do I need a GTF or GFF3 file for RNA-seq analysis?

Yes, for gene-level counting and annotation-aware quantification. The annotation must match the genome assembly and gene identifier namespace used for alignment.