Is STAR or HISAT2 more accurate for RNA-seq alignment?

On intact RNA, STAR showed a higher median concordant alignment rate (93%) than HISAT2 in a clinical benchmark. On degraded or FFPE RNA the gap widens further: HISAT2 misassigns more reads to pseudogenes, which inflated one study's differential expression calls to over 15,000 genes versus 350, 2,496 with STAR on the same samples.

How much RAM do I need for STAR vs HISAT2?

STAR needs at least 16 GB for a mammalian genome and runs best with 32 GB. HISAT2's human index needs only about 6.7 GB of RAM at runtime and 6.2 GB of disk, which is why it's the documented recommendation for machines under 16 GB.

Can I use HISAT2 for clinical or FFPE samples?

You can, but be cautious. A clinical breast cancer benchmark found HISAT2 aligned significantly more reads to pseudogenes in FFPE samples than STAR, and that misalignment cascaded into a differential expression result inflated by an order of magnitude. For FFPE work, STAR plus edgeR was the combination the study recommended.

Does STAR or HISAT2 give gene counts directly?

STAR can, using --quantMode GeneCounts at alignment time (the GTF has to be supplied when you build the index, not at alignment). HISAT2 has no built-in counting mode; you still need a separate step with featureCounts or HTSeq after alignment.

Which aligner is recommended by ENCODE?

STAR is the ENCODE standard for RNA-seq alignment. If your project needs to match ENCODE-style processing for cross-study comparability, use STAR regardless of your hardware constraints and budget the RAM.

Comparison · aligner

STAR vs HISAT2: Which One Should You Use?

The real choice isn't speed vs accuracy, it's whether you have 32 GB of RAM and clean RNA, or 8 GB and degraded FFPE samples.

By Ming "Tommy" Tang, Director of Bioinformatics in Big Pharma · Reviewed September 2026 · 3 min read

The verdict

Default to HISAT2 if you're the typical reader of this site: a wet-lab biologist or early-career analyst running alignments on a laptop or a shared server that isn't provisioned with 32 GB of dedicated RAM. It needs as little as 8 GB, its SNP-aware index gives you variant-adjacent mapping for free, and per the book's own rule on tool selection, a marginal accuracy difference rarely changes your biological conclusion when the alternative is not being able to run the tool at all.

Switch to STAR the moment either of two things is true: you have access to a machine with 32 GB+ RAM, or your samples are FFPE, degraded, or otherwise low RNA-quality. The FFPE case isn't a marginal difference: one clinical benchmark found HISAT2's pseudogene misassignment on degraded samples inflated downstream differential expression to over 15,000 genes, versus 350 to 2,496 genes from the same samples aligned with STAR. That's not 5% noise, that's a corrupted result. Also reach for STAR if your pipeline needs to match the ENCODE standard, or if you want gene counts emitted directly from the aligner instead of running a separate counting step.

STAR and HISAT2 both call themselves splice-aware aligners, but they build the reference index in fundamentally different ways, and that choice cascades into RAM, speed, and accuracy trade-offs you live with for the rest of the project.

STAR indexes the genome as an uncompressed suffix array and loads the whole structure into memory before it maps a single read. That's why it needs 16 GB minimum, ideally 32 GB, for a mammalian genome: the index is large, but the payoff is a maximal-mappable-prefix search that runs extremely fast once loaded, and STAR trims poly(A) tails before alignment, a detail that matters more than it sounds.

HISAT2 uses a Hierarchical Graph FM (HGFM) index, the same compressed BWT-based family that Bowtie2 uses, extended into a graph that embeds roughly 12.3 million common SNPs from dbSNP. Compression is the whole point: the human HGFM index takes 6.2 GB on disk and about 6.7 GB of RAM at runtime, which is why it's the aligner that actually works on an 8 GB laptop. The SNP-aware graph also lets HISAT2 report variant information directly in the SAM output, something STAR doesn't do out of the box.

Head to head

Criterion	STAR	HISAT2	Edge
Memory required for a human genome index	16 GB minimum, 32 GB recommended for comfortable performance	As little as 8 GB; the SNP-aware index runs in about 6.7 GB	HISAT2
Disk footprint of the index	Large uncompressed suffix array; substantially bigger than HISAT2's index for the same genome	6.2 GB for the human HGFM index with 12.3 million embedded SNPs	HISAT2
Concordant alignment accuracy on intact RNA	93% median concordant alignment rate in one clinical benchmark	Lower concordant rate than STAR in the same benchmark	STAR
Unmapped read rate	Not separately quantified in the same benchmark	1.6% unmapped reads, a strong result on its own	Tie Low unmapped rate doesn't mean the read landed in the right place; see the pseudogene row.
Pseudogene misalignment on degraded or FFPE samples	Poly(A) trimming before alignment reduces pseudogene misassignment	Significantly higher pseudogene misalignment on FFPE samples than STAR	STAR
Downstream differential expression robustness (FFPE)	350, 2,496 differentially expressed genes reported from FFPE samples	Over 15,000 differentially expressed genes from the same samples, indicating corrupted quantification	STAR
SNP or variant-aware alignment	No built-in SNP-graph index	HGFM index embeds ~12.3 million SNPs and reports SNP info in SAM output for genotyping	HISAT2
Direct gene-level quantification	Can emit gene counts directly with --quantMode GeneCounts	No built-in counting mode; requires a separate featureCounts or HTSeq step	STAR
Raw aligner speed	Reported to outperform older aligners by more than 50x in mapping speed, at the cost of memory	Reported ~3x faster than the next-fastest aligner in a separate clinical benchmark that included STAR	Tie These figures come from different benchmark setups; run both on your own data before trusting either number for your hardware.
Field standard / pipeline adoption	The ENCODE standard for RNA-seq alignment	Common in resource-constrained pipelines and pairs with StringTie for transcript assembly	STAR

Use STAR when

You have access to a machine with 32 GB+ RAM, whether a workstation, HPC node, or cloud instance sized for it.
You're aligning FFPE, degraded, or otherwise low-quality RNA and need reliable poly(A) trimming to avoid pseudogene-driven false differential expression.
You need gene-level counts directly from the aligner via --quantMode GeneCounts without adding a separate featureCounts or HTSeq step.
Your project needs to match ENCODE-style standardized processing for cross-study comparability or a publication's methods requirements.
You're processing large cohorts on shared HPC or cloud infrastructure where a large speed advantage compounds across hundreds of samples.

Use HISAT2 when

You're working on a laptop or a server with 8-16 GB of RAM and can't spare 32 GB for a genome index.
You want SNP-aware alignment against a population reference for improved mapping near known variant sites.
Your samples are fresh-frozen or otherwise high-quality, where HISAT2's pseudogene misassignment issue is far less consequential.
You're feeding alignments into StringTie for transcript assembly or novel isoform discovery, the pipeline HISAT2 was designed alongside.
Disk space is constrained and you need the smaller SNP-aware index footprint rather than STAR's much larger uncompressed index.

Switching between them

Switching between these tools changes more than the alignment command. Index-building differs entirely: STAR's genomeGenerate step needs the full genome plus a GTF supplied up front if you want --quantMode GeneCounts later, while HISAT2 relies on hisat2-build or a prebuilt HGFM index that already has SNPs embedded. Output handling changes too: STAR can hand you a ReadsPerGene.out.tab count table directly from the aligner, while HISAT2 only gives you a SAM/BAM file, so any pipeline built around STAR's built-in counts needs an added featureCounts or HTSeq step after switching to HISAT2. Alignment statistics are not directly comparable across the two: STAR reports its summary in Log.final.out and HISAT2 reports a different set of fields to stderr, so don't compare "percent uniquely mapped" between them without normalizing both BAMs through samtools flagstat first. If you're moving a FFPE or clinical cohort from HISAT2 to STAR (or vice versa), expect your differential expression gene list to change substantially, re-run both alignments on the same samples before trusting a cross-tool comparison of results.

Pitfalls with either

Building a STAR index on a laptop without checking available RAM first, then watching the process get killed partway through: check RAM with `free -h` before starting, and use HISAT2 if you're under 16 GB.
Using HISAT2's graph-based HGFM index by default without needing SNP-awareness, then wondering why it's slow: the graph index runs 30-80% slower than the plain HFM index, so pick the index type based on whether you actually need variant-aware mapping.
Trusting a HISAT2-based differential expression result from FFPE or otherwise degraded samples without a sanity check: pseudogene misassignment inflated one study's DE gene list to over 15,000 genes, so re-run degraded samples through STAR before reporting the result.
Comparing STAR's Log.final.out percentage against HISAT2's alignment summary as if they measure the same thing: run samtools flagstat on both BAMs to get a metric computed the same way before comparing tools.
Setting up STAR with --quantMode GeneCounts but forgetting the GTF has to be supplied at genome-index-build time, not at the alignment step: rebuild the index with --sjdbGTFfile if counts come out empty or wrong.

Questions people ask

Is STAR or HISAT2 more accurate for RNA-seq alignment?: On intact RNA, STAR showed a higher median concordant alignment rate (93%) than HISAT2 in a clinical benchmark. On degraded or FFPE RNA the gap widens further: HISAT2 misassigns more reads to pseudogenes, which inflated one study's differential expression calls to over 15,000 genes versus 350, 2,496 with STAR on the same samples.
How much RAM do I need for STAR vs HISAT2?: STAR needs at least 16 GB for a mammalian genome and runs best with 32 GB. HISAT2's human index needs only about 6.7 GB of RAM at runtime and 6.2 GB of disk, which is why it's the documented recommendation for machines under 16 GB.
Can I use HISAT2 for clinical or FFPE samples?: You can, but be cautious. A clinical breast cancer benchmark found HISAT2 aligned significantly more reads to pseudogenes in FFPE samples than STAR, and that misalignment cascaded into a differential expression result inflated by an order of magnitude. For FFPE work, STAR plus edgeR was the combination the study recommended.
Does STAR or HISAT2 give gene counts directly?: STAR can, using --quantMode GeneCounts at alignment time (the GTF has to be supplied when you build the index, not at alignment). HISAT2 has no built-in counting mode; you still need a separate step with featureCounts or HTSeq after alignment.
Which aligner is recommended by ENCODE?: STAR is the ENCODE standard for RNA-seq alignment. If your project needs to match ENCODE-style processing for cross-study comparability, use STAR regardless of your hardware constraints and budget the RAM.

Glossary · Effect size

Sources

Aligning the Aligners: Comparison of RNA Sequencing Data Alignment and Gene Expression Quantification Tools for Clinical Breast Cancer Research — Source for concordant alignment rates, pseudogene misalignment on FFPE samples, and the inflated differential expression gene counts
STAR RNA-seq aligner (GitHub repository) — Source for STAR's RAM requirements, ENCODE-standard status, and gene-count output mode
HISAT2 documentation and reference — Source for HISAT2's RAM/disk requirements and the HGFM SNP-aware index design
Comparison of Short-Read Sequence Aligners Indicates Strengths and Weaknesses for Biologists to Consider — Source for the transcript-length-dependent performance comparison between STAR and HISAT2