# StringTie: transcript assembly and quantification for bulk RNA-Seq > StringTie takes spliced alignments in coordinate-sorted SAM, BAM or CRAM and produces a GTF of assembled transcripts with FPKM, TPM and base coverage values. Version 3 adds a nascent-aware mode that separates mature from incomplete transcripts in rRNA-depleted libraries, and the whole tool is a C++ program with a bundled htslib and no other dependencies beyond zlib. **gpertea/stringtie** — Transcript assembly and quantification for RNA-Seq - Repository: https://github.com/gpertea/stringtie - Stars: 535 · Forks: 91 - Language: C++ - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/gpertea-stringtie ## What the tool does with your alignments, and what comes out StringTie employs efficient algorithms for transcript structure recovery and abundance estimation from bulk RNA-Seq reads aligned to a reference genome. That single sentence fixes the scope of the tool, and it is worth being explicit about the boundary it draws. The input is spliced alignments in coordinate-sorted SAM, BAM or CRAM format. The output is a GTF file consisting of assembled transcript structures and their estimated expression levels, given as FPKM, TPM and base coverage values. So the tool sits after alignment. It is not an aligner, and it is not a de novo assembler in the sense of discovering transcripts without a reference. The README is clear that the input must be sorted by genomic location, and it gives the accepted_hits.bam file produced by TopHat as an example, along with HISAT2 output sorted with samtools sort. The command line has a simple default shape: ``` stringtie [-o ] [other_options] ``` If the -o option is not used, the output GTF with the assembled transcripts is printed to standard output, and can be captured into a file with the shell output redirect. That default is a small convenience with a real consequence in a pipeline, since an unredirected run writes a GTF to your terminal and an accidentally missing -o in a shell script can end up writing to a log file. The output being a GTF is what makes StringTie composable with the rest of the ecosystem. A GTF of transcripts with expression attributes is something tools downstream expect, and the fact that abundance and structure arrive in the same file means you do not have to join two separate results to know which transcript belongs to which expression value. ## Long reads, the --mix flag, and a command line that tolerates any order StringTie can work with two alignment files at once, which is how it handles a library where you have both short and long reads. The form of the command is: ``` stringtie [-o ] --mix [other_options] ``` The ordering rule is explicit and matters. If the --mix option is used, StringTie expects two alignment files as positional parameters in a specific order, with the short read alignments given first and the long read alignments second. Both alignment files must be sorted by genomic location. Then there is the detail that trips people up, which is that the command line parser allows arbitrary order and mixing of the positional parameters with the other options. So the input alignment files can also precede the options or be given in between them, and this command is equivalent to the one above: ``` stringtie --mix [other_options] [-o ] ``` That flexibility is convenient when you are writing a wrapper, and it is also a source of confusion, because a long read file passed in the wrong slot is not an error but a different result. If you build this into a pipeline, pin the order rather than relying on the parser. The two-transcript capability matters for the nascent-aware work described below, because a Total RNA library produces both mature and incomplete molecules, and separating them is easier when you have reads that span the full length of a transcript alongside shorter ones. ## Nascent-aware assembly, and the two flags that control it StringTie 3 introduces a feature that is about the biology of the library rather than the algorithm, and it is the most interesting thing in the current version. Many rRNA-depleted, called Total RNA, libraries capture a mixture of mature and nascent, incomplete, RNA. The nascent-aware algorithm accounts for that signal and separates mature from nascent RNA in the assembly process. The reference for the method is a paper by Shinder, Pertea, Hu, Rudnick and Pertea in Nature Methods in 2026, titled as improving total RNA-seq assembly by resolving nascent and mature transcripts. The two flags differ in one specific respect, and that difference is what you need to know before choosing. | Flag | Behaviour | | :--- | :--- | | `-N` | Enables nascent-aware assembly (recommended for any rRNA-depleted or Total RNA library). The primary output GTF contains only mature transcript models. | | `--nasc` | Same algorithm as `-N`, but also retains nascent intermediates in the GTF output. Nascent records carry `nascentRNA` in the source column (field 2) and include a `nascent_parent ""` attribute that links each nascent transcript to its mature parent. | So the default for -N is a clean output with mature transcripts only, which is what most analyses want, and --nasc is the research option that keeps the intermediate models and links them back to their parents through the nascent_parent attribute and the source column. The flag table also has a practical edge. -N is recommended for any rRNA-depleted or Total RNA library, so if your data is that kind and you do not pass it, you are running the older assembly and not the one the paper describes. That is a quiet difference in output, and it is exactly the kind of thing to check before comparing results across projects. ## Building it, and the difference between make and make release Building StringTie from source takes a clone, a cd and a make, and the build is deliberately dependency-light. The main program has no other library dependencies besides zlib, and compiling from source requires a C++ compiler that supports the C++ 11 standard, GCC 4.8 or newer. The build sequence is: ``` git clone https://github.com/gpertea/stringtie cd stringtie make -j4 release ``` The compiler can be overridden with the CC and CXX environment variables, for example: ``` CC=clang CXX=clang++ make -j4 release CC=icx CXX=icpx make -j4 release ``` The -j4 is a job count, and the release target is the one that matters. Simply running make would produce a less optimized executable which is suitable for debugging and runtime checking, but that is significantly slower than the optimized version built by the make release command. That is a sensible arrangement, because the difference in a tool like this is the difference between a test run and a production run over hundreds of samples. The unoptimized build is for development, and the release build is for the analysis you actually care about. Two more details worth knowing. During the first run of the make command a few library dependencies are downloaded and compiled, but any subsequent stringtie updates using git pull should rebuild much faster. And the resulting stringtie binary can be copied to a programs directory of your choice, preferably one that is in the current shell's PATH. Building and installing this way should take less than a minute on a regular Linux or Apple MacOS desktop. For HPC environments without online access during the build, there is an offline package. You download the latest .offline.tar.gz package, unpack it, cd into the unpacked directory, and then: ``` make -j6 release make test ``` This builds the binary and runs the included tests without having to fetch dependencies and test data, which is the arrangement most cluster sites need. ## The bundled htslib, the prebuilt binaries and the super-reads caveat The repository structure explains the dependency story, and it is worth looking at because it is unusual for a bioinformatics tool to vendor this much. The top level includes a htslib/ directory and a gclib/ directory, along with stringtie.cpp as the main program, and the supporting files for the other parts of the tool: bundle.cpp and bundle.h for the bundled transcript merging, rlink.cpp and rlink.h for the read link, tmerge.cpp and tmerge.h, and tablemaker.cpp and tablemaker.h for the expression table. There is a SuperReads_RNA/ directory, and the prep scripts: prepDE.py, prepDE.py3, prep_source.sh, prep_offline_source.sh, prep_linux.sh and prep_mac.sh, plus run_tests.sh and run_tests_valgrind.sh, and a tag_git.sh for releases. The Makefile shows how the vendored htslib is used. The comment at the top is emphatic that the paths must point at the included samtools and gclib sub-directories, and the library paths for libdeflate, libbz2 and liblzma are all taken from inside that bundled htslib rather than from the system. The final link line is the htslib static library, then those three compression libraries, then zlib and the maths library. Pthreads are added on non-Windows systems unless a nothreads goal is set. The Makefile also handles Windows with MinGW, adding the regex and ws2_32 libraries and switching the executable extension, and it detects the compiler version to add -Wno-implicit-fallthrough for GCC 5 and up and -Wno-class-memaccess for GCC 8 and up, since the latter is the warning GCC 8 introduced for the class-memaccess pattern in its own headers. The prebuilt binary releases come with one caveat. The binary packages are compiled on older versions of Linux and Apple MacOS in order to provide compatibility with a wide range of OS versions and not just the most recent distributions. But the binary packages do not include the optional super-reads module, which currently can only be built on Linux machines from the source in the repository. So the choice is straightforward. If you are on a recent Linux workstation and want the super-reads module, build from source. If you need a Mac or an older distribution, take the binary and accept the missing module. ## Conclusion Adopt StringTie if you are working with bulk RNA-Seq and want transcript-level assembly and quantification in one step, especially if your libraries are rRNA-depleted and the nascent-aware mode matters for your data. Do not adopt it for single-cell data or for a de novo assembly with no reference, since it takes alignments against a reference genome as its input. Before running it on a Total RNA library, read the -N and --nasc flags, because the default output changes depending on which you use, and check the coverage values against the sample depth, since the quantification is only as good as the alignment you feed it. ## FAQ ### What does StringTie take as input and produce as output? It takes spliced RNA-Seq alignments in coordinate-sorted SAM, BAM or CRAM format and produces a GTF file of assembled transcript structures with their estimated expression levels as FPKM, TPM and base coverage values. Without the -o option the GTF is printed to standard output. ### What is the difference between the -N and --nasc flags in StringTie 3? Both enable the nascent-aware assembly algorithm, which separates mature from nascent RNA in rRNA-depleted libraries. With -N the output GTF contains only mature transcript models, while --nasc also retains nascent intermediates, marked with nascentRNA in the source column and linked to their mature parent through a nascent_parent attribute. ### How do I build StringTie from source? Clone the repository, cd into it and run make -j4 release. A C++ compiler supporting C++ 11, GCC 4.8 or newer, is required, and you can set CC and CXX to choose a compiler. Simply running make produces a less optimized executable suitable for debugging but significantly slower. ### What is the super-reads module and why is it missing from the binary releases? It is an optional module, and the prebuilt binary packages do not include it because it can currently only be built on Linux machines from the source in the repository. ### How do I build StringTie in an environment with no internet access? Download the latest .offline.tar.gz package from the releases page, unpack it, cd into the directory and run make -j6 release followed by make test, which builds the binary and runs the included tests without fetching dependencies and test data. ## Sources - [gpertea/stringtie on GitHub](https://github.com/gpertea/stringtie) - [Issues](https://github.com/gpertea/stringtie/issues) - [License: MIT](https://github.com/gpertea/stringtie/blob/master/LICENSE) - [README](https://github.com/gpertea/stringtie/blob/master/README.md) - [Releases](https://github.com/gpertea/stringtie/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gpertea-stringtie