FASTQ Format Explained: Structure, Quality Encoding, and Header Fields

A FASTQ file is the standard text format for raw and lightly-processed sequencing reads: every read is stored as exactly four lines — an identifier, the called bases, a separator, and a per-base quality string. It is the format that comes off the sequencer (or out of a demultiplexing step) and feeds into alignment, quality control, and every downstream pipeline. This guide covers the record structure, how the quality line is encoded, what a typical header line contains, and the paired-end naming convention you will run into on almost any Illumina project.

The four-line record structure

Every record in a FASTQ file is exactly four lines, in this fixed order:

1. Line 1 — the sequence identifier / header, beginning with @, followed by an ID and optional free-text description.
2. Line 2 — the raw called bases (A, C, G, T, and N for no-call), one character per base.
3. Line 3 — a separator line beginning with +, optionally repeating the identifier from line 1 (most tools leave it bare).
4. Line 4 — the quality string: one ASCII character per base in line 2, in the same order, encoding that base’s Phred quality score.

A minimal record looks like this:

@SEQ_ID
GATTTGGGGTTCAAAGCAGTATCGATCAAATAGTAAATCCATTTGTTCAACTCACAGTTT
+
!''*((((*** +))%%%++)(%%%%).1***-+*''))**55CCF>>>>>>CCCCCCC65

Two structural details matter more than they look. First, line 2 and line 4 must be the same length, base-for-base — a length mismatch means the file is corrupt or was mis-split. Second, the @ character that opens line 1 is also a legal Phred+33 quality character (ASCII 64), so a naive parser that scans for a line starting with @ to find the next record can misfire on a quality line that happens to start with one. Correct parsers read strictly in fixed groups of four lines rather than searching for @; this is one of the documented gotchas in the original FASTQ specification paper.

How Phred quality scores are encoded as ASCII characters

Line 4 packs a numeric quality score into a single printable ASCII character per base, using an offset so the whole range stays in the printable range (33–126). Two offset conventions have been used in practice:

• Phred+33 (Sanger) — the current, near-universal standard. ASCII 33 (!) is Q0, and the range extends up to ASCII 126 (~), covering Q0–Q93. Q30 is the character ? (ASCII 63); Q40 is I (ASCII 73). This is what the SAM specification requires and what essentially every current sequencer and downstream tool assumes by default.
• Phred+64 (Illumina 1.3–1.7) — a historical variant used by Illumina’s own pipeline software for several years before it was retired in favor of Phred+33. It uses ASCII 64–126 for a Q range of 0–62.

Both offsets produce a file that looks superficially identical — a string of printable ASCII characters — and nothing in the file itself declares which convention was used. That is the trap: a tool that assumes Phred+33 when the data is actually Phred+64 will read every quality value about 31 points too high; the reverse mistake produces nonsensical negative scores. If a legacy or unfamiliar FASTQ file produces implausible quality values, check the encoding before you trust the run. Because encoding is a solved but easy-to-get-wrong problem, and because the arithmetic of interpreting Q values correctly (including why you can’t just average them) has more nuance than fits here, see our full guide to Phred quality scores for the complete Q-to-error-probability mapping, encoding-detection guidance, and modern quality-score binning behavior on current Illumina instruments.

What a typical header line encodes

The exact fields in line 1 vary by sequencing platform and pipeline version — there is no single universal header spec, only per-vendor conventions. The most common one in current use is the Illumina Casava 1.8+ format, which packs run and cluster-location metadata directly into the identifier. A representative example:

@EAS139:136:FC706VJ:2:2104:15343:197393 1:Y:18:ATCACG

Read left to right, the colon-delimited fields before the space are:

1. Instrument name/ID (EAS139)
2. Run number (136)
3. Flow cell ID (FC706VJ)
4. Lane number (2)
5. Tile number (2104)
6. X-coordinate of the cluster on the tile (15343)
7. Y-coordinate of the cluster on the tile (197393)

After the space, a second group covers read-level flags:

8. Which member of a pair this read is — 1 or 2 for paired-end data
9. A filter flag — Y if the read failed the instrument’s own quality filter, N if it passed
10. A control number (0 when the read is not a control)
11. The sample index sequence used for demultiplexing (ATCACG)

Older Illumina pipelines, other platforms (Oxford Nanopore, PacBio), and public archives all use different header conventions — some far shorter, some carrying platform-specific run metadata instead. Never assume a specific field count or order for a file whose origin you don’t know; check the sequencing core or platform’s own documentation for the file in front of you rather than parsing positionally against the Illumina layout by default.

Paired-end file naming and pairing conventions (R1/R2)

Paired-end sequencing reads both ends of the same DNA fragment and, on Illumina platforms, conventionally stores the two ends in two separate FASTQ files rather than interleaved in one. The near-universal naming convention marks these with _R1 and _R2 in the filename — for example, a sample’s forward and reverse reads might be named along the lines of SampleName_R1.fastq.gz and SampleName_R2.fastq.gz, often with additional lane/set-number fields depending on the demultiplexing software that produced them. R1 is the forward (first) read of each pair; R2 is the reverse (second) read from the other end of the same fragment.

What actually keeps a pair linked is not the filename but record order: the Nth record in the R1 file and the Nth record in the R2 file are mates from the same DNA fragment, and correct tooling relies on both files being sorted identically and containing the same number of records. Practical consequences:

• Never filter, sort, or subsample an R1 file without applying the exact same operation, in the exact same order, to its R2 file — doing otherwise desynchronizes the pairing and silently corrupts every downstream alignment.
• A mismatched record count between R1 and R2 is a hard error condition for most aligners, and a sign that one file was altered without the other.
• Single-end data has no R2 file at all — one FASTQ file, one read per fragment.
• Some tools additionally recognize an interleaved single-file format (R1 and R2 records alternating in one file) instead of two separate files; check what your specific aligner or pipeline expects before assuming a two-file layout.

Exact filename conventions (lane numbers, set numbers, sample-index numbering) vary by which demultiplexing tool produced the files and by sequencing core — treat the general _R1/_R2 pattern as reliable and everything else in the filename as pipeline-specific, and confirm against your core facility’s documentation when it matters (e.g. scripting a batch pairing step).

Related formats and where FASTQ fits

FASTQ is a superset of the older FASTA format in the sense that it carries the same sequence data plus per-base quality — FASTA has no quality line at all, which is why FASTQ, not FASTA, is the interchange format for raw reads, while FASTA remains the format for assembled/reference sequence (the origin of the read-calling process itself is covered in our Sanger sequencing guide, including how it relates to modern short-read platforms). Downstream of read generation, quality scores travel forward into the SAM/BAM alignment formats using the same Phred+33 convention, so an encoding assumption you get wrong at the FASTQ stage propagates into every alignment-based analysis after it. FASTQ files are also what you submit to sequence archives: see our guide to submitting sequence data to NCBI SRA and the Sequence Read Archive (SRA) entry for what a repository expects on deposit, including encoding. If you’re evaluating a sequencing vendor or core facility, our NGS service buying guide covers what to ask about FASTQ delivery and demultiplexing. And for what happens to paired FASTQ reads once they’re aligned and quantified, see our guide to RNA-seq experimental design and analysis.

Frequently asked questions

What’s the difference between FASTQ and FASTA?

FASTA stores a sequence identifier and the sequence itself, with no quality information — it’s used for assembled sequences, reference genomes, and other contexts where every base is treated as certain. FASTQ adds a per-base Phred-encoded quality line and is the standard format for raw sequencing reads, where every base call carries a real, non-zero error probability that downstream tools need to see.

How do I tell whether a FASTQ file is Phred+33 or Phred+64?

The file format itself doesn’t declare it. In practice: know the provenance (recent Illumina data is essentially always Phred+33; only legacy runs from roughly the Illumina 1.3–1.7 pipeline era use Phred+64), or run a quality-control tool such as FastQC, which infers the likely encoding from the character range actually observed in the quality lines. Implausibly high or negative quality values after conversion are the classic symptom of an encoding mismatch.

Can the sequence and quality lines wrap across multiple lines, like FASTA does?

In principle a strict FASTQ parser can handle multi-line sequence/quality blocks, but in practice essentially every tool in the current ecosystem assumes exactly four lines per record with no wrapping, and most files are written that way. Treat four-lines-per-record as the working assumption unless you have a specific reason not to.

Are FASTQ files usually compressed?

Yes — raw FASTQ is highly repetitive text and compresses well, so files are almost always distributed and stored gzip-compressed (.fastq.gz / .fq.gz) rather than as plain text. Most bioinformatics tools read gzip-compressed FASTQ directly without requiring a separate decompression step.

What does an N in the sequence line mean?

An N is a no-call — the base caller could not confidently assign A, C, G, or T at that position. The corresponding quality character at that position is typically the lowest possible value, since a no-call is definitionally the least confident kind of base call a sequencer can report.

Does R1 always mean “forward strand”?

R1 means the first read generated for each fragment during sequencing, not a fixed strand identity. Depending on the library preparation and protocol, R1 may or may not correspond to the genomic forward strand for a given fragment — check your library prep’s documented orientation (e.g. stranded RNA-seq protocols define this explicitly) rather than assuming R1 is always “forward” in the genomic sense.