Reading BLAST Results: E-values, Bit Scores, and Query Coverage

Every BLAST search ends with the same wall of numbers: a percent identity, an E-value, and a bit score for each hit. Read those numbers wrong and you will either chase random noise as if it were a real homolog, or throw away a genuine match because the E-value "looked big." This guide walks through what each column in a BLAST hit table actually measures and, more importantly, how to read them together instead of picking just one and trusting it blindly.

What a BLAST Hit Table Actually Contains

If you run BLAST from the command line with -outfmt 6, you get a tab-separated table with no header row and twelve columns by default. If you have not installed BLAST yet, our guide to installing BLAST locally covers the conda setup.

blastn -query query.fasta -db nt -outfmt 6 -out results.tsv

The default columns, in order, are:

That is the whole table, but three of those columns, evalue, bitscore, and pident, get misread constantly. Coverage is not even in the default output; you have to ask for it explicitly, which is worth doing:

blastn -query query.fasta -db nt -outfmt "6 qseqid sseqid pident length evalue bitscore qcovs" -out results.tsv

E-value: The Expected Number of Hits by Chance

The E-value (Expect value) answers a very specific question: given a database of this size and a query of this length, how many hits with a score at least this good would you expect to see purely by chance, if the database were random sequence? It is not a probability and it is not a p-value, even though people often treat it that way in casual conversation.

The underlying relationship, from Karlin-Altschul statistics, looks like this:

E = K * m * n * e^(-lambda * S)

Here m is the effective query length, n is the effective size of the database (total residues), S is the raw alignment score, and K and lambda are statistical parameters that depend on the scoring matrix and gap penalties. The two things worth internalizing from that formula:

• Lower E-value means a stronger, less-likely-by-chance match. An E-value of 1e-50 is far more convincing than 0.01.
• E-value scales directly with database size (n) and query length (m). Run the exact same alignment against a database ten times larger, and the E-value gets roughly ten times worse, even though nothing about the biological similarity changed. This is why an E-value from a search against a small custom database is not directly comparable to one from a search against the full nr database.

A commonly used rule of thumb is that an E-value < 1e-5 is reasonable evidence of homology for a typical protein or nucleotide query, but treat this as a starting point, not a law. A 20-nucleotide primer will rarely produce an E-value anywhere near that threshold even for a perfect match, simply because the query is short and m is small in the formula above. Very small E-values can also underflow and print as 0.0 in the output; that just means the value fell below floating-point precision, not that it is literally zero.

Bit Score: Why It Doesn't Care About Database Size

The bit score is what you get after normalizing the raw alignment score S to remove the database-size and scoring-scheme dependence:

S' = (lambda * S - ln(K)) / ln(2)

Because K and lambda are baked into this normalization, bit scores computed with different substitution matrices, gap penalties, or even different BLAST programs land on the same scale and can be compared directly. Crucially, the bit score formula has no n (database size) term in it. Run the same alignment against Swiss-Prot (a few hundred thousand sequences) and against the full nr database (hundreds of millions of sequences), and the bit score for that hit stays essentially the same, while the E-value gets dramatically worse in the larger database because there are more sequences competing for a chance match.

That distinction is the practical takeaway:

• Use bit score to judge how good an individual alignment is, independent of what database you happened to search.
• Use E-value to judge how statistically significant that alignment is within the specific search you ran.

If you are comparing hits across BLAST runs against differently sized databases, ranking by bit score is more consistent than ranking by E-value.

Percent Identity Needs Query Coverage as a Partner

pident on its own is one of the most misleading numbers in a BLAST table if you read it in isolation. A 100 percent identical 20 base pair stretch inside a 3,000 base pair query will report pident = 100.00, but that alignment covers less than 1 percent of your query. It tells you almost nothing about whether the two sequences are related across their full length; it might just be a shared short motif, a low-complexity repeat, or a small conserved domain.

This is where query coverage (qcovs or qcovhsp) earns its keep: it reports what fraction of your original query participated in the alignment. Read pident and coverage together, not separately.

This same logic underpins tools built on top of BLAST, including the identity and coverage cutoffs used for taxonomic assignment in metagenomics and microbiome analysis, where a high-identity, low-coverage hit against a reference genome is a classic false-positive trap.

Reading a Real Hit Line

Here is a sample outfmt 6 row you might see for a 200-residue protein query searched against a protein reference collection, expanded to include coverage:

query_1  sp|Q8EXAM1|EXMPL_HUMAN  98.50  200  3  0  1  200  1  200  2e-104  365  100

Walking through it: pident is 98.50, the alignment spans all 200 residues (length) with only 3 mismatches and no gap openings, and it covers the query from position 1 to 200 and the subject from position 1 to 200, which is a full-length alignment on both sides. The E-value of 2e-104 is astronomically significant, the bit score of 365 is high, and coverage of 100 confirms the entire query participated. That combination, high identity, high coverage, tiny E-value, high bit score, is what a confident homolog looks like.

Contrast that with a row like query_2 sp|Q9XYZ1|SOME_PROT 95.00 18 1 0 40 57 10 27 0.003 38 9. Identity looks great at 95 percent, but the alignment length is only 18 residues out of a much longer query, coverage is 9 percent, the E-value of 0.003 is far weaker, and the bit score of 38 is modest. That is a short, low-confidence coincidental match, not evidence of homology.

Practical Takeaways

• Never judge a hit from a single column. Read pident, coverage, E-value, and bit score together.
• Use bit score, not E-value, when comparing hit quality across searches run against differently sized databases.
• Always add qcovs to your -outfmt string. Percent identity without coverage hides short, misleading matches.
• Treat E-value < 1e-5 as a rough starting filter, and adjust it for query length; short queries need looser thresholds, long queries can afford stricter ones.
• Remember that an E-value of 0.0 in the output means underflow, not a true zero probability.

Once you are comfortable reading a hit table this way, the next useful step is scripting BLAST across many queries and filtering programmatically on these same four columns, rather than eyeballing results one at a time.