Quality Control of NGS Reads with FastQC and MultiQC

FastQC tutorial · Chapter 1 of 5: Why QC matters, FASTQ and Phred scores

This FastQC tutorial starts where every NGS analysis starts, with one question: can I trust these reads? A sequencing run gives you millions of reads, and some of them carry low-quality bases, leftover adapter sequence or contamination. If you skip quality control (QC), those problems quietly flow into alignment, variant calling and expression analysis, and you only notice when the results look wrong.

In this tutorial you will learn FastQC step by step: you will check paired-end Illumina reads with FastQC, clean them with fastp, and compare before-and-after results in one report with MultiQC. Along the way you will learn how the FASTQ format and Phred scores work, what each FastQC module measures and when it really matters, and how the trimming algorithms decide what to cut.

What you will learn in this FastQC tutorial

• Read a FASTQ record and decode its quality characters
• Explain Phred scores and the Phred+33 encoding
• Run FastQC and interpret every important module, including FastQC’s own pass, warn and fail thresholds
• Know which warnings are normal for RNA-seq, amplicon and other data types
• Understand why adapters appear and how fastp finds and removes them
• Understand sliding-window quality trimming
• Combine all reports with MultiQC and decide whether data is ready for alignment
• Run the whole workflow for many samples with one loop
• Understand the sequencing chemistry behind quality scores and poly-G tails (Go deeper)
• Judge when trimming helps, using published evidence (Researcher notes)
• Screen reads for contamination with FastQ Screen and Kraken2
• Report QC properly in a thesis or paper

Why read quality control matters

Illumina sequencers read DNA by building a complementary strand one base per cycle and recording a fluorescent signal. With every cycle, a few molecules in each cluster fall out of step (phasing), so the signal gets noisier towards the end of the read. That is why base quality usually drops at the 3′ end.

Poor-quality reads cause real problems downstream:

• Lower mapping rate: adapter bases and errors stop reads from aligning to the reference.
• False variants: low-quality bases look like SNPs or indels in variant calling.
• Biased expression counts: in RNA-seq, untrimmed adapters and rRNA contamination distort gene counts.
• Wasted time: alignment of bad data takes hours, and you may have to redo everything.

Understanding the FASTQ format

Raw reads come in FASTQ files (usually compressed as .fastq.gz). Every read takes exactly four lines:

• Line 1 starts with @ and holds the read ID (instrument, run, flow cell position).
• Line 2 is the base sequence (A, C, G, T, and N for an unknown base).
• Line 3 starts with + and may repeat the ID.
• Line 4 holds one quality character per base.

In paired-end sequencing, each DNA fragment is read from both ends. Read 1 goes in sample_R1.fastq.gz and its mate in sample_R2.fastq.gz, in the same order. Tools must always receive both files together so the pairs stay matched.

Look at the first two reads and count the reads in a file:

zcat sample_R1.fastq.gz | head -8

# number of reads = number of lines / 4
echo $(( $(zcat sample_R1.fastq.gz | wc -l) / 4 ))

@A00123:45:HXXXXDSXX:1:1101:2718:1000 1:N:0:ATCACG
  │      │  │         │ │    │    │    │ │ │ └ index (barcode) sequence
  │      │  │         │ │    │    │    │ │ └ control number (0 = none)
  │      │  │         │ │    │    │    │ └ Y = failed the instrument filter, N = passed
  │      │  │         │ │    │    │    └ read number (1 or 2)
  │      │  │         │ │    │    └ y-coordinate of the cluster
  │      │  │         │ │    └ x-coordinate of the cluster
  │      │  │         │ └ tile number
  │      │  │         └ lane
  │      │  └ flow cell ID
  │      └ run number
  └ instrument ID

paste <(zcat sample_R1.fastq.gz | awk 'NR%4==1') <(zcat sample_R2.fastq.gz | awk 'NR%4==1') | head -3

# quick statistics for both files: reads, length, Q20/Q30 %
seqkit stats -a sample_R1.fastq.gz sample_R2.fastq.gz

Phred quality scores and how they are encoded

Each quality character stands for a Phred score (Q), which tells you the probability (P) that the base call is wrong:

Q = -10 × log10(P)        and        P = 10^(-Q/10)

Example: Q = 30  →  P = 10^(-3) = 0.001  →  1 wrong base in 1,000

To store a number as one character, the score is added to 33 and written as the ASCII character with that code. This is Phred+33 (Sanger / Illumina 1.8+) encoding. For example I is ASCII 73, so its score is 73 − 33 = 40. Very old Illumina data (version 1.3–1.7) used Phred+64; FastQC detects the encoding for you and shows it in the Basic Statistics module.

You can decode a quality string yourself with one line of Python:

python3 -c "q='II?5+#'; print([ord(c)-33 for c in q])"

python3 - <<'EOF'
q1 = [30] * 100
q2 = [30] * 90 + [10] * 10
ee = lambda q: sum(10 ** (-x / 10) for x in q)
for name, q in (('read 1', q1), ('read 2', q2)):
    print(name, 'mean Q =', sum(q) / len(q), ' expected errors =', round(ee(q), 2))
EOF