DEV Community

devin2xing
devin2xing

Posted on Originally published at seqandchem.com

FASTA vs FASTQ — Format Differences, Examples and Conversion

FASTA and FASTQ are the two workhorse text formats of bioinformatics. FASTA is older and simpler;
FASTQ was introduced with next-generation sequencing to carry a per-base confidence score
alongside each base.

FASTA

A FASTA record is a header line beginning with > followed by one or more lines of
sequence:

>seq1 sample description
ATGGCCATTGTAATGGGCCGCTGAAAGGGTGCCCGATAG
>seq2
ATGGCCTTTGTAATGGGCCGCTGAAAGGGTGCCCGATAG
Enter fullscreen mode Exit fullscreen mode

Sequence lines are conventionally wrapped at 60 or 70 characters, but any width is legal. A file
can hold any number of records.

What FASTA is used for

  • Reference genomes and transcriptomes
  • Protein sequences
  • BLAST databases
  • Multiple sequence alignment input
  • Anywhere the sequence itself is the payload and per-base confidence is irrelevant

FASTQ

A FASTQ record has four lines:

@read1
ATGGCCATTGTAATGGGCCGCTGAAAGGGTGCCCGATAG
+
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
Enter fullscreen mode Exit fullscreen mode
  1. @ header — same content as a FASTA header, different marker
  2. Sequence
  3. + separator, optionally repeating the header
  4. Quality string — exactly one character per base

What the quality string means

Each character encodes a Phred quality score Q, which is a log-scale estimate of the probability
that the base is wrong:

Q = -10 × log10(P_error)
Enter fullscreen mode Exit fullscreen mode

The character is the score plus an offset. Modern Illumina data uses Phred+33 (Sanger encoding),
so:

Character ASCII Phred Q Error probability
! 33 0 1 in 1
+ 43 10 1 in 10
5 53 20 1 in 100
? 63 30 1 in 1,000
I 73 40 1 in 10,000

Older Illumina pipelines used Phred+64, which produces characters like h for a
decent score. Mixing the two encodings silently corrupts quality interpretation — one of the
reasons FASTQ files carry a "encoding" note in their metadata.

Converting FASTQ to FASTA

This throws away the quality string. It is a one-line transformation per record, and it is
completely safe — but it is also irreversible. Once the quality data is gone it
cannot be reconstructed.

Convert when:

  • Your downstream tool only accepts FASTA (BLAST, most aligners' reference input)
  • You are assembling or annotating and quality has already been used for filtering
  • You need a compact archive of the sequences

Do not convert when you still need to trim, filter or call variants — those steps depend
on the quality scores.

Converting FASTA to FASTQ

Going the other way is synthesising information that never existed. You cannot invent real
quality scores, so any converter has to write a placeholder. Ours writes the highest quality
character throughout, which means "assume every base is correct".

This is legitimate when an old tool insists on FASTQ input but you genuinely have no quality
data — for example a sequence reconstructed from a paper. It is not legitimate for
feeding an aligner that will use those scores to decide which mismatches to trust.

Quick reference

FASTA FASTQ
Header marker > @
Lines per record 2+ (wrapped) exactly 4
Quality scores no yes, one per base
Typical size 1× sequence ~2× sequence
Typical source reference, protein sequencer output

Try it

Convert in either direction with FASTA → FASTQ or
FASTQ → FASTA, or compute GC content and sequence statistics
with the GC content calculator. All of them run locally in Python
on this server — nothing is sent to a third party.


Convert in either direction with FASTA to FASTQ or FASTQ to FASTA, and get sequence statistics from the GC content calculator.

Top comments (0)