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
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
-
@header — same content as a FASTA header, different marker - Sequence
-
+separator, optionally repeating the header - 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)
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)