HISAT2: graph-based alignment of sequencing reads against a population of genomes

What the hierarchical graph index actually is

HISAT2 is a fast and sensitive alignment program for mapping next-generation sequencing reads, whole-genome, transcriptome and exome sequencing data, to a population of human genomes as well as to a single reference genome.

The technical contribution is stated plainly in the readme. Based on an extension of BWT for a graph, the authors designed and implemented a graph FM index, which they describe as an original approach and its first implementation to the best of their knowledge.

On top of that, HISAT2 uses a large set of small GFM indexes that collectively cover the whole genome, each index representing a genomic region of 56 Kbp, with 55,000 indexes needed to cover a human population. These small indexes are called local indexes, and combined with several alignment strategies they enable effective alignment of sequencing reads. The scheme is called Hierarchical Graph FM index, or HGFM.

The reason for the hierarchy is worth understanding, because it explains both the accuracy claim and the resource cost. A single global index over a population graph would have to be searched for every read, and the search space is the whole population. Splitting the genome into 56 Kbp regions and indexing each separately means the same read can be placed quickly by identifying the region it belongs to and then searching a small index, and the population variation is carried by the graph structure inside each local index rather than by one giant structure.

HISAT2 was developed on the back of HISAT and Bowtie 2, and the readme cites the HISAT paper in Nature Methods and the Bowtie 2 paper. The distinction from HISAT is the graph. HISAT indexes a linear reference sequence with a suffix array and handles splicing; HISAT2 indexes a population graph, so a read that matches a reference genome imperfectly because it carries a common variant still has an exact path through the graph. That is the accuracy story, and the readme states it as one of its five notes: HISAT2 provides greater accuracy for alignment of reads containing SNPs.

The resource numbers, and the speed you give up

The getting started section lists the hardware requirement and then five notes, and the numbers in them are the practical constraint.

HISAT2 requires a 64-bit computer running either Linux or Mac OS X and at least 8 GB of RAM.

The first note is about index size. HISAT2's index, the HGFM, for the human reference genome and 12.3 million common SNPs is 6.2 GB. The SNPs consist of 11 million single nucleotide polymorphisms, 728,000 deletions and 555,000 insertions, and the insertions and deletions used in the index are small, usually under 20 bp. The authors plan to incorporate structural variations into the index.

That 6.2 GB number is the one to plan against, and it is worth being precise about what it contains. It is not a genome-sized graph of every human being. It is a reference genome augmented with the common variant sites, at the scale where a large fraction of the population shares a variant. Reads carrying rare variants or structural variation are exactly where the model does not help you, and the SV gap is acknowledged rather than solved.

The second note gives the memory footprint as relatively low at 6.7 GB, which is a pleasant surprise next to a 6.2 GB index. The third note is the cost: the runtime of HISAT2 is estimated to be slightly slower than HISAT, 30 to 100 percent slower for some data sets.

That is the trade in one line. You give up a substantial fraction of the speed of the fastest reference aligner and get back accuracy on SNP-containing reads. If your reads come from a population with limited variation, or you are aligning a very large cohort where runtime dominates, the trade may not pay. If your samples are diverse human cohorts, which is the common case in population-scale studies, the opposite is true.

The fourth note is the accuracy claim again, and the fifth points at HISAT-3N for aligning nucleotide converted sequencing reads, which covers BS-seq, SLAM-seq, scBS-seq, scSLAM-seq, TAB-seq, oxBS-seq, TAPS and EM-seq. That alignment process requires about 10 GB of RAM, so it is a separate tool with its own footprint rather than a mode of HISAT2.

Building the index and running an alignment

The install is a clone and a make, with no package manager involved.

    git clone https://github.com/DaehwanKimLab/hisat2.git
    cd hisat2
    make

The Makefile at the root shows what is being built: hisat2-align, hisat2-build and hisat2-inspect. The build is C++ with the -std=c++11 flag, and the compiler is derived from wherever gcc lives on the system.

Index construction is a single command.

    hisat2-build genome.fa genome

What comes out is a set of files with the suffixes.1.ht2 through.8.ht2, and in the case of a large index these suffixes have an ht2l termination. These files together constitute the index, and they are all that is needed to align reads to that reference. The original sequence FASTA files are no longer used by HISAT2 once the index is built.

That last sentence has an operational consequence that matters in a pipeline. The index is self-contained, so you can archive the.ht2 files and drop the reference FASTA, and you can distribute an index without the source sequences. It also means the index format is a compatibility boundary: an index built by one version is a thing you have to keep and rebuild when the tool changes.

Alignment is the usual two shapes.

    # for single-end FASTA reads DNA alignment
    hisat2 -f -x genome -U reads.fa -S output.sam --no-spliced-alignment

    # for paired-end FASTQ reads alignment
    hisat2 -x genome -1 reads_1.fq -2 read2_2.fq -S output.sam

The -f flag means the reads are in FASTA rather than FASTQ, -U gives a single-end file, -1 and -2 give the paired files, -x names the index and -S writes SAM. The --no-spliced-alignment flag on the first example is worth noting, because splicing is HISAT's original reason for existing and this example turns it off for a plain DNA alignment. There is also an inspect tool, hisat2-inspect, for looking at what is inside an index.

The repository carries the MANUAL, a MANUAL.markdown source for it, a TUTORIAL, a NEWS file and a VERSION file, and there is an example directory with index/, reads/ and reference/ subdirectories, so there is a worked example to run rather than only documentation to read.

The build system and the platform gates in the Makefile

The Makefile is longer than a build file usually is, and the reason is that HISAT2 has to behave differently on different platforms, so the platform detection is written out in full.

There are two independent switches for Windows. The file detects Cygwin and MinGW separately, setting WINDOWS to 1 and CYGWIN or MINGW to 1 accordingly. In both cases the comment is the same: POSIX memory-mapped files not currently supported on Windows, so BOWTIE_MM and BOWTIE_SHARED_MEM are set to 0. That is the actual technical limitation, and the build encodes it rather than hiding it.

MacOS is detected separately by looking for Darwin in uname, and sets MACOS to 1.

The CPU architecture detection is the most recent-looking part of the file, with a comment saying to detect target CPU architecture for SIMD and flag gating. ARCH is taken from uname -m, and if it matches aarch64, arm64, armv7l or armv8l then ARM is 1, otherwise ARM is 0. Those two flags then gate which SIMD paths and which compiler flags are used.

That is worth pausing on. A file naming a specific list of ARM architectures and gating SIMD on them is a project set up to compile on ARM, not one that mentions the platform only in passing. The list covers 64-bit ARM and 32-bit ARM variants, which maps onto the range of hardware that actually shows up in genomics, from a laptop to an ARM server to a Raspberry Pi.

Two other Makefile settings matter for a from-source build. BOWTIE_MM is 1 by default and BOWTIE_SHARED_MEM is 0, so memory mapping is used where the platform allows it and shared memory is off. And the comment on the include flag is a small piece of engineering folklore: -iquote. is used rather than -I. so that the VERSION file does not shadow libc++'s <version> header on case-insensitive filesystems.

There is also a CMakeLists.txt at the top level alongside the Makefile, and the GitHub workflows directory, so both build systems are supported.

Where HISAT2 sits against a plain reference aligner

The honest comparison is against HISAT, the tool HISAT2 descends from, and the difference is the graph.

A reference aligner like HISAT or Bowtie 2 builds a suffix array over one reference sequence. When a read differs from that sequence because the sample carries a variant, the aligner has to accommodate the mismatch, and the cost is that a mismatch in a seed region can mean the seed does not match at all, so the read is either missed or aligned with less confidence. That is the failure mode that matters in population studies, where a large fraction of reads carry at least one common variant.

HISAT2's graph index changes what the seed has to match. A read that matches a common variant exactly has an exact path through the population graph, so it seeds and aligns as cleanly as a read from a reference individual. The cost of that is the graph structure, which is why the index is 6.2 GB and why the authors describe the tool as slower than HISAT.

So the choice is not accuracy against speed in the abstract, it is a question about your data. Aligning reads from a single reference individual, a reference bacterial genome, or any non-human organism, the graph buys you nothing and costs you runtime. Aligning human cohort data where common variation is everywhere, the graph is the difference between a good alignment and a compromised one.

There is a third option worth knowing about, and the repository name points at it: HISAT-genotype lives in a separate repository, with its own homepage, and the HISAT2 and HISAT-genotype paper in Nature Biotechnology describes graph-based genome alignment and genotyping together. If your analysis needs per-sample genotypes as well as alignment, the genotyping half is a separate tool with its own build, and the readme explicitly flags that the HISAT2 repository is separated from the HISAT-genotype repository.

The licence is GPL-3.0, the default branch is master, and the last push was on 2026-07-31, the same day as the v2.2.3 release. The release before that is v2.2.2 from 2026-01-27, and before that v2.2.1 from 2020-07-24, so the tool has had a long stable stretch with a recent release on top of it.

Editorial conclusion

HISAT2 fits a genomics pipeline where reads carry common human variation and reference-based aligners lose accuracy, and it does not fit a pipeline where runtime is the binding constraint, since the readme estimates it is 30 to 100 percent slower than HISAT on some data sets. Before running it, budget the resources: the human index with 12.3 million common SNPs is 6.2 GB, the memory footprint is 6.7 GB, and the tool requires a 64-bit machine with at least 8 GB of RAM.

Frequently asked questions

Official sources

1. DaehwanKimLab/hisat2 on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases