FASTA vs FASTQ: What Actually Differs
9 min read · Updated September 12, 2026
Both formats are plain text, both start with a header line, both hold sequence, and people use the words almost interchangeably in conversation. Then a tool refuses one of them and it suddenly matters which you have.
The difference is one thing, and everything else follows from it: a FASTQ record carries a quality score for every single base, and a FASTA record carries none. This guide walks through what that costs, why the extra data forces a four-line record, which format your data should actually be in at each step, and how to tell what you are holding.
The whole difference, on one read
Take the same 21-base read and write it both ways. As FASTA it is two lines: a header line reading >read1 some description, then the sequence GATTACAGATTACAGATTACA. As FASTQ it is four:
- @read1 some description — the same header, marked with @ instead of >.
- GATTACAGATTACAGATTACA — the same sequence, unchanged.
- + — a separator line, usually just this one character.
- IIIIIIIIIIIIIIII!!#5F — one quality character per base, exactly as long as line 2.
The fourth line is the whole format
That line is the entire point of FASTQ. Each character encodes a Phred quality score: the sequencer's estimate of how likely it is that it called that base wrong. In the example above the run of I characters is Q40 (a 1-in-10,000 chance of an error), the two ! characters are Q0 (no confidence at all), # is Q2, 5 is Q20, and F is Q37. A FASTA file of the same read tells you the bases and nothing about whether to believe any of them.
Why FASTQ needs exactly four lines
FASTA is line-oriented in a forgiving way. A record starts at a > and runs until the next >, so the sequence can be wrapped across as many lines as you like — 60 or 70 characters per line is the convention, and a parser just concatenates them. You can reformat a FASTA file by hand without breaking it.
FASTQ cannot work that way, and the reason is a trap worth internalising. The quality line is ASCII, and in the standard Phred+33 encoding the character @ is a perfectly legal quality value — it is Q31, a good base. The + character is Q10. So a quality line can begin with @ or with +, which means you cannot find record boundaries by looking for lines that start with @, and you cannot find the separator by looking for lines that start with +.
The only safe way to read a FASTQ file is four lines at a time, counting. This is why almost every FASTQ file in the wild is written unwrapped, with the sequence and quality each on exactly one line however long the read is, and why a FASTQ file that someone has helpfully line-wrapped is a genuine problem rather than a cosmetic one.
It also means that a corrupted or truncated FASTQ — a download that stopped mid-file, a concatenation that lost a newline — does not fail loudly at the break. It goes out of phase, and every record after the break is read with the wrong four lines, silently.
Phred+33 and Phred+64
One historical wrinkle survives into current files. The quality character is the Phred score plus an ASCII offset, and there have been two offsets in use. Phred+33, sometimes called Sanger encoding, is what everything modern writes. Phred+64 was used by Illumina pipelines before CASAVA 1.8, which is to say before 2011.
The two are not distinguishable by inspection in the general case, only by range. In Phred+33 a Q0 base is !, and in Phred+64 a Q0 base is @ — so a file containing ! or characters below it in the quality line is certainly Phred+33, and a file whose quality characters are all in the upper part of the table is probably Phred+64. Tools that read FASTQ therefore take the offset as an option rather than guessing.
Getting it wrong shifts every score by 31 points, which does not crash anything. It just makes an excellent read look unusable, or an unusable read look excellent, with no error message. If you have inherited an old dataset and the quality numbers look absurd in either direction, the offset is the first thing to check.
The Phred score table has the full mapping from Q value to error probability to ASCII character in both encodings, if you need to decode a quality string by hand.
What the quality line costs
The arithmetic is exact and worth knowing before you decide what to archive. For a read of length L with a header of H characters, a FASTA record is H + L + 3 bytes and a FASTQ record is H + 2L + 6 bytes. The difference is L + 3 — you pay roughly one extra byte per base, plus three for the separator line.
For 150-base reads with a typical Illumina header of about 45 characters, that is 198 bytes per FASTA record against 351 for FASTQ, a factor of 1.77. As reads get longer relative to the header the ratio approaches a clean 2x.
Compressed, the gap widens rather than closing, which surprises people who assume gzip evens things out. A sequence line is drawn from a four-letter alphabet and compresses very well; a quality line is drawn from roughly forty characters with much less structure and compresses poorly. In a simulated 20,000-read file the gzipped FASTQ came out close to three times the size of the gzipped FASTA, against 1.8x uncompressed. Real quality strings are smoother than simulated ones so the real figure is smaller, but the direction is reliable: quality is the expensive part of a compressed FASTQ, not the bases. That is the reason modern instruments bin quality scores into a handful of levels rather than reporting all forty-odd.
Which one your data should be in
The rule of thumb is that FASTQ belongs upstream and FASTA belongs downstream, and the boundary is the point where you stop making decisions about individual base calls.
Raw instrument output is FASTQ, and should stay FASTQ. Read trimming, adapter removal, quality filtering, duplicate detection and variant calling all read the quality line; throwing it away before those steps means throwing away the evidence they run on. This is also why a sequencing core that sends you FASTA has, in effect, already made your trimming decisions for you without telling you which ones.
Anything that is a consensus or a reference is FASTA. A finished assembly, a reference genome, a gene sequence pulled from a database, a protein sequence, a primer, a plasmid map exported as sequence — none of these have a per-base error probability, because they are not the output of a single read. Writing them as FASTQ would mean inventing quality scores.
Sanger is the interesting middle case. A chromatogram does carry per-base quality, so an .ab1 can legitimately be converted to FASTQ, and it is worth doing when you care about where a read stops being trustworthy. Most browser trace viewers export only FASTA, which quietly discards it.
Converting: one direction is free, the other is not
FASTQ to FASTA is a deletion. Drop lines three and four of each record, change @ to >, and you are done — no information is created and the result is always valid.
FASTA to FASTQ is not a conversion at all. There is no quality information to recover, so any tool that offers it is padding the quality line with a constant, usually the maximum. That produces a file that parses, passes validation, and tells every downstream tool that every base is perfect. If you need a FASTQ for a pipeline that demands one, do it deliberately and remember that every quality-aware step in that pipeline is now a no-op.
SeqBench's Format Converter deliberately refuses FASTQ input rather than doing something reasonable-looking with it — earlier it read a FASTQ as FASTA, which turned the @id headers and Phred lines into bases without complaint. For FASTQ the tool to reach for is FASTA/FASTQ Stats, which reads both formats and reports length distribution, N50, GC and, for FASTQ, mean quality.
Telling what you actually have
The extension is the least reliable signal. .fa, .fasta, .fna, .faa, .ffn, .seq and .txt are all routinely FASTA; .fq and .fastq are usually FASTQ but a file named .txt or .seq can be either.
Look at the first character instead. A > on line one means FASTA. An @ on line one, a sequence on line two, a line that is exactly + on line three, and a fourth line the same length as line two means FASTQ. If line three is not a bare + or a + followed by a repeat of the header, you do not have a FASTQ file, whatever it is called.
The length check matters more than it looks. A file where the sequence and quality lines differ in length for even one record is malformed, and the usual causes are a truncated download or a concatenation that lost a newline. Running a stats pass over the file before it enters a pipeline catches this in seconds, which is considerably cheaper than finding it after an alignment run.
Frequently asked questions
What is the difference between FASTA and FASTQ?
A FASTQ record carries a quality score for every base and a FASTA record carries none. That is the whole difference. FASTA is a header line beginning with > followed by sequence; FASTQ is a header beginning with @, the sequence, a separator line that is just +, and a fourth line of quality characters exactly as long as the sequence.
Can I convert FASTQ to FASTA?
Yes, and it is lossless in the sense that nothing is invented: you drop the separator and quality lines and change @ to >. It is lossy in the sense that the per-base quality is gone for good. The reverse is not a real conversion — there is no quality data to recover, so any tool offering FASTA to FASTQ fills the quality line with a constant, which tells every downstream tool that every base is perfect.
Why does FASTQ have four lines instead of two?
Because the quality line needs to be found unambiguously and cannot be. In Phred+33 the @ character is a legal quality value (Q31) and + is another (Q10), so you cannot locate record boundaries by looking for lines starting with @. The fixed four-line structure is what makes the format parseable at all, which is also why FASTQ files are written unwrapped and why a truncated file goes silently out of phase rather than failing.
What does the + line in a FASTQ file mean?
It is a separator marking the end of the sequence and the start of the quality string. It may be a bare + or a + followed by a repeat of the header text. The repeat is redundant and wastes space in large files, so modern writers emit the bare form.
Is FASTQ bigger than FASTA?
Yes, by roughly one byte per base. Exactly, a FASTA record is H + L + 3 bytes and a FASTQ record is H + 2L + 6 for a read of length L with an H-character header — about 1.8x for 150-base Illumina reads, approaching 2x for longer reads. Gzipped the gap is wider, not narrower, because quality strings compress far worse than four-letter sequence.
What are Phred+33 and Phred+64?
The two ASCII offsets used to encode quality scores. Phred+33 (Sanger encoding) is what everything modern writes; Phred+64 was used by Illumina pipelines before CASAVA 1.8 in 2011. Reading a file with the wrong offset shifts every score by 31 points silently, with no error, so tools take the offset as an explicit option rather than guessing.
Should my reference genome be FASTA or FASTQ?
FASTA. A reference, an assembly, a gene pulled from a database, a primer or a protein sequence has no per-base error probability because it is not the output of a single read, so there is nothing for a quality line to hold. FASTQ belongs upstream, wherever you are still making decisions about individual base calls.
How do I check whether a file is FASTA or FASTQ?
Read the first three lines rather than trusting the extension. A > on line one is FASTA. FASTQ is an @ header, a sequence, a line that is exactly + (or + plus the header), and a quality line the same length as the sequence. If the sequence and quality lengths disagree anywhere in the file it is malformed, usually from a truncated download — worth catching with a stats pass before the file enters a pipeline.
Related references
Related tools
Summarise and validate FASTA or FASTQ: counts, N50, GC, quality.
Convert between FASTA, GenBank and tab-separated formats, and extract CDS or protein sequences.
Per-base quality, GC and length distributions, duplication levels, overrepresented sequences and adapter content, each with a warn/fail verdict.
Generate composition, ORF, restriction-site and primer summaries from one sequence.