NGS Read Quality Control: FastQC and Trimming Explained

Quick answer: Raw sequencing reads always contain some low-quality bases, adapter fragments, and over-represented junk, and every downstream step inherits those problems. Quality control has two parts that beginners constantly merge into one: inspection, where FastQC or fastp measures the reads, and trimming, where you decide to cut bases or reads away. Inspection is always mandatory; trimming is a judgment call, and over-trimming silently destroys real signal. The deliverable of this step is a multiqc report you keep, plus a set of reads you can defend.

A companion to the FASTA and FASTQ format guide and the genome assembly guide: this is the step between receiving FASTQ files and trusting them.

Why QC sits first in every pipeline

Everything downstream assumes the reads are what you think they are. Assembly assumes overlap is real; alignment assumes the bases are correct; variant calling assumes mismatches are biological rather than sequencing error; differential expression assumes counts reflect transcripts rather than adapter dimers. A single contaminated or adapter-heavy run propagates into every one of those conclusions, and no later step can detect the problem for you.

The practical consequence is a rule worth adopting early: never run alignment, assembly, or counting on reads you have not looked at. It takes two minutes and it is the cheapest insurance in the pipeline.

What FastQC actually reports

FastQC is a set of independent modules. Each answers one narrow question, and each has a healthy shape:

The two modules beginners misread most are duplication and per-base content. High duplication is alarming for a WGS library and completely normal for a targeted amplicon panel, so the module warns rather than judges. Per-base composition is genuinely non-random in the first cycles of many Illumina runs; the fix is knowing that, not trimming it away.

Phred scores in one line

Every base carries a quality score, Q, where the error probability is 10^(-Q/10). Q20 means a 1-in-100 chance the base is wrong; Q30 means 1-in-1000; Q40 means 1-in-10,000. That is the whole scale, and it is why “Q30” is the number people quote when they ask whether a run is good: at Q30 you are wrong about one base in a thousand, which most variant callers and assemblers tolerate.

Quality is not uniform across a read. Modern Illumina instruments start poorly (chemistry settling, cluster calling during the first cycles), then plateau, then decay as the read extends and phasing accumulates. Long-read platforms invert this shape entirely: a Nanopore or PacBio read has no useful single “per-cycle” profile because each base is called independently.

What trimming fixes

• Adapter read-through. When the insert is shorter than the read length, the sequencer reads straight into the adapter. That adapter is not biology, and it wrecks assembly and alignment. Detection is the adapter module; removal is a standard, uncontroversial trim.
• Poly-G tails on two-colour Illumina instruments: when no signal arrives, the instrument writes G. These are not bases. They are trimmed routinely.
• Low-quality 3′ bases that would otherwise soften a base quality threshold downstream.
• Reads that are junk entirely: adapter dimers, very short fragments, PCR duplicates flagged by their positions.

What trimming breaks

• Over-trimming shortens reads, and shorter reads align uniquely less often and assemble into smaller contigs. Aggressive quality trimming on already-good reads can measurably reduce mapping rate for no gain.
• Cutting into the true insert. Quality trimming at the 3′ end is standard; quality trimming at the 5′ end removes primer sequence that some amplicon pipelines specifically require.
• Silently altering an amplicon region. For 16S work, trimming inside the amplified region changes the sequence itself, which is the one thing a marker-gene study must not do.
• Length filters that delete one amplicon entirely, which appears as a mysteriously missing taxon later.

The honest position is that trimming is a small, well-defined set of jobs, and the correct term is not “clean up the data” but “remove adapter, poly-G, and read-through, then stop”.

fastp vs Trimmomatic

For a first project, fastp in one pass with automatic adapter detection is the pragmatic choice. Trimmomatic is worth knowing because it is still the most cited, and because writing the steps out explicitly is exactly the discipline an over-trimming beginner needs.

The report that must survive the project

Run FastQC on the raw reads and again on the trimmed reads, then aggregate everything with multiqc:

# Raw QC
fastqc -t 8 -o qc/raw/ reads_R1.fastq.gz reads_R2.fastq.gz

# One-pass trim: adapters, poly-G, quality, with a report
fastp -i reads_R1.fastq.gz -I reads_R2.fastq.gz \
      -o trim/reads_R1.fastq.gz -O trim/reads_R2.fastq.gz \
      --detect_adapter_for_pe --cut_tail -q 20 -l 36 \
      -j qc/fastp.json -h qc/fastp.html

# Post-trim QC
fastqc -t 8 -o qc/trim/ trim/reads_R1.fastq.gz trim/reads_R2.fastq.gz
multiqc qc/ -o qc/multiqc

multiqc is not optional in spirit: the aggregate report is the single artifact that lets someone else see whether your run was acceptable, and it is the file reviewers and collaborators ask for.

A worked example

Two paired-end samples from the same run, before and after trimming:

Read the table carefully. Sample 1 needed almost no intervention: adapter removal cost three bases. Sample 2 lost nineteen bases of length because a real fraction of its fragments were shorter than the read, which is exactly the case where trimming earns its keep. Sample 2 is also the sample whose poly-G and adapter fractions would have poisoned the assembly if left alone.

Common failure modes

• Trimming by habit. Running Trimmomatic with a copied config on every dataset without looking at the QC first. If there is no adapter and the quality is uniformly high, the correct trim is often no trim.
• Judging duplication from the module alone. Duplication is library-type dependent; a high number is a prompt to check the library prep, not an automatic failure.
• Never running QC on the trimmed output. Most trimming mistakes are only visible by comparing the before and after reports, which is the whole reason both exist.
• Ignoring overrepresented sequences. An unexplained single sequence at 5% of the run is contamination or a collapsed repeat, not noise.
• Discarding the QC report. Without multiqc, nobody can audit the run later, and “we trimmed the reads” is not a methods section.

Key takeaways

• QC has two distinct halves: inspection is mandatory, trimming is a judgment call with a narrow, defensible job.
• FastQC’s modules each answer one question; the two most misread are duplication and first-cycle base composition.
• Phred Q30 equals one error in a thousand, and quality is not uniform along a read, so both ends need separate attention.
• Trim adapters, poly-G, and read-through; do not trim simply because trimming feels safer.
• Keep the raw and trimmed QC plus the aggregated multiqc report: it is the evidence that the run is an acceptable input.

Challenge

Take any public FASTQ pair from an SRA run, run FastQC and fastp with the commands above, and write one paragraph explaining what you decided to trim and why. Then re-check the multiQC report and answer: which module changed the most, and would that change have been predictable from the raw report alone? That paragraph is the methods note you will reuse for every dataset in the project.

Want to be taught this against your own data? Ampersand Academy offers one-to-one mentoring in bioinformatics and NGS analysis — part of Mahadhi, a development and digital marketing company.

FAQ